Automation Orchestration
Automation orchestration is the control layer that turns recurring agent work from cron prompts into durable, observable, idempotent workflows with state, retries, gates, and proof.
Core idea
A cron schedule is not an automation system. It is only a trigger.
Automation orchestration includes:
- trigger definition;
- input collection;
- state checkpointing;
- idempotency;
- retries and backoff;
- human approval gates;
- output routing;
- monitoring;
- proof artifacts;
- memory updates;
- cleanup.
Temporal's platform docs frame durable workflow systems around the ability to resume where they left off after crashes, network failures, or infrastructure outages. That is the IRL baseline for serious orchestration: the workflow's state cannot live only in a chat transcript or a lucky terminal session. Source: Temporal docs, https://docs.temporal.io/, 2026-06-19
The failure mode
The naive version:
cron -> agent prompt -> hope
This fails in predictable ways:
- two runs overlap and corrupt state;
- a retry repeats a destructive action;
- a partial run looks complete;
- output lands in the wrong place;
- a required human approval blocks forever;
- failures are invisible until Kevin asks;
- the next agent cannot tell what happened.
This is how automations become scheduled work with no operational guarantees.
Orchestration layers
| Layer | Question |
|---|---|
| Trigger | What starts the run: schedule, event, webhook, manual command, monitor? |
| Eligibility | Should the run happen now, or is it stale/duplicate/rate-limited? |
| State | Where is progress stored between steps and crashes? |
| Idempotency | Can the same step run twice without duplicate side effects? |
| Policy | Which actions need approval or budget checks? |
| Execution | Which agent/tool/machine handles each step? |
| Observation | What events, logs, traces, and metrics are emitted? |
| Output | Where do artifacts, wiki updates, PRs, or notifications go? |
| Recovery | How are failures retried, skipped, escalated, or rolled back? |
| Learning | What should be added to memory, skills, or doctors after the run? |
Kevin wiki automations
Kevin's automation layer already has many orchestration pieces:
automations/*.mddefines recurring task contracts;- Cursor automation files adapt those contracts for cloud agents;
state.jsonrecords freshness and last-run signals;outputs/stores run artifacts;wiki/log.mdrecords durable operations;- Source Compile Workflow and QMD Embed Workflow define multi-step maintenance;
- Self-Maintaining Systems and Doctor Pattern close feedback loops.
The missing concept was the cross-cutting control layer: which pieces make an automation safe and durable rather than a prompt that happens to run on a schedule.
Orchestration pattern
The critical invariant is that every edge can be retried or resumed without losing the truth of the run.
Agent-specific additions
Agent automations need more than ordinary job queues:
- model/tool budget caps;
- trace capture;
- source citation requirements;
- sandbox cleanup;
- prompt/version provenance;
- human approval channels;
- artifact review;
- memory write policy;
- skill/doctor promotion when failures repeat.
When to use heavyweight orchestration
| Workload | Minimum viable orchestration |
|---|---|
| local wiki maintenance | script + log + doctor + qmd |
| daily research radar | schedule + source list + dedupe + output artifact + wiki update |
| code-fixing bot | isolated worktree + tests + PR + reviewer gate |
| paid production workflow | durable engine + idempotency + observability + approval/budget gates |
| long-running multi-agent work | checkpoints + state machine + trace/proof bundle + resume UI |
Do not overbuild every script. But once money, external side effects, overlapping runs, or multi-hour work enter the picture, orchestration is the product.
Failure modes
- trigger exists but state does not;
- retry logic repeats writes;
- no owner for "stale but not failed";
- output artifact is not linked from memory;
- automation edits wiki without running graph/search maintenance;
- approval gates are not resumable;
- cost/time budgets are not enforced;
- monitors alert without a repair path.
Concept Position
| Field | Value |
|---|---|
| Concept family | Agent harness and runtime primitives |
| Concept owned | Automation orchestration is the control layer that turns recurring agent work from cron prompts into durable, observable, idempotent workfl... |
| Category map | Concept System Map |
Timeline
- 2026-07-01 | Concepts category refresh added this page to the Agent harness and runtime primitives family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: Automation orchestration is the control layer that turns recurring agent work from cron prompts into durable, observable, idempotent workfl... Source: User request, 2026-07-01
- 2026-06-19 | Created to connect Kevin's automation definitions, source compile, self-heal, durable execution architecture, HITL gates, and proof-carrying work into one orchestration concept. Source: User request; Temporal docs; local automation/workflow pages, 2026-06-19