What is Deterministic orchestration?
Coordination in which the same state of work always leads to the same next step, decided by rules rather than by a model improvising.
When agents run unattended, a predictable next step bounds the cost of anything going wrong.
On this page
Deterministic orchestration is coordination in which the same state of work always leads to the same next step — decided by explicit rules: a state machine, a dispatch queue, an authorisation check — rather than by a model deciding, mid-flight, what should happen next. Anthropic's engineering guidance draws the underlying line between workflows, where "LLMs and tools are orchestrated through predefined code paths", and agents, where models "dynamically direct their own processes". Deterministic orchestration is the discipline of keeping the orchestration in the first category even when the work inside each step is done by the second.
The distinction is easy to miss because both look autonomous from the outside. The difference shows on the bad day: a system whose next step is a function of its state fails in ways that are reproducible, bounded and auditable; a system whose next step is a model's improvisation fails in ways that are creative.
What the deterministic layer decides
The model does the work; the rules decide the around-the-work. The division of labour:
| Decision | Belongs to | Example |
|---|---|---|
| What happens next to this piece of work | The state machine | Audit passed → QA; QA failed → back to the queue |
| Who may take which action | Authorisation rules | The author of a change cannot approve it |
| Which work runs when | The dispatch queue | Priority, dependencies, re-dispatch on failure |
| What happens when a step fails | Retry and escalation policy | N attempts, then park for a person — see escalation |
| What the work is, inside its step | The model | Read the brief, write the change, run the tests |
The right side of the second column is the point: every rule that can be stated as "if state X, then Y" should live in code, not in a prompt. A prompt that says "never approve your own work" is a suggestion; a server that rejects the transition is a rule.
Why unattended work needs it
Supervision is the usual substitute for predictability: when a person watches each step, an improvised next step is caught as it happens. Unattended work removes the watcher, and with it the substitute — so predictability has to come from the machinery instead.
Three properties follow, and each one is a safety property:
- Reproducibility. The same state always yields the same step, so any failure can be traced to a state and a rule — not to a mood of the model that day.
- Boundedness. The set of next steps is enumerable. What the system can do next is a list, not a possibility space — which is what makes the blast radius of any failure discussable at all.
- Auditability. Every transition is an event against a rule. The question "why did this happen?" has an answer that is not "the model decided".
There is an efficiency argument too: improvised coordination is expensive. A model reasoning about "what should happen to this ticket now?" spends tokens to produce a worse version of what a state machine produces for free — and produces it differently each time.
Deterministic vs agentic — the working split
| Deterministic layer | Agentic layer | |
|---|---|---|
| Nature | Code paths, state machines, queues | The model, in a loop with tools |
| Strengths | Predictable, auditable, cheap | Flexible, handles the unanticipated |
| Failure mode | Rigid where the world needs judgement | Creative where the world needed a rule |
| Right for | Transitions, permissions, retries, dispatch | The work inside a step: reading, writing, deciding |
The split is not a fence — each layer calls the other. A well-run agent platform is deterministic on the outside and agentic on the inside: every unit of work is an agent doing something genuinely flexible, wrapped in a shell that never lets the flexibility leak into the coordination.
Best practices
1. Promote rules out of prompts as they stabilise
The first time a workflow rule is written as instruction text, it is a candidate; the second time it is obeyed, write it as code. Rules that have stabilised into prompts are rules waiting to be bypassed.
2. Make the state machine the only door
Every transition — approved, failed, returned, done — goes through one server-side path that checks authorisation. Side doors (scripts, direct writes, "just this once") are how deterministic systems become deterministic in name only.
3. Log transitions as first-class events
The transition log — what moved, from which state to which, by whom, under which rule — is the audit trail. If a step's outcome is not in the log, the step happened off the books.
4. Keep the model's degrees of freedom where they pay
The test for what stays agentic: does this decision benefit from judgement? Reading a requirement and writing a change — yes. Deciding whether the change may be marked approved — that is a rule, and giving it to a model adds cost and subtracts safety.
Deterministic orchestration in YATFA
YATFA's coordination is a state machine on the outside: tickets move through defined states, transitions are validated server-side against authorisation rules, a dispatch queue decides what runs next and re-dispatches on failure, and every transition is logged. The agents doing the work inside each state are autonomous; the path the work travels is not negotiable by them. See how YATFA coordinates and the guardrails design.
Frequently asked questions
Doesn't determinism limit what agents can do?
It limits what the coordination can do, not the work. The model keeps full freedom inside its step — how to read the brief, what to try, which files to touch. What it loses is the right to invent process: skip review, reassign itself, declare done. That loss is the feature.
Is this just workflow automation with an LLM inside?
Closer to the inverse framing: agentic work with automation around it. Classic workflow automation could not do the work; pure agent loops could not be trusted with the process. The workable system is both, and the interesting design work is the boundary between them.
Where should the boundary sit in practice?
A good heuristic: if you would fire a person for deciding it unilaterally, it is a rule; if you would pay extra for good judgement, it is model territory. Approvals and state transitions sit firmly in the first bucket — which is why they are the first things to move server-side.