01 / THE REQUIREMENT
What the system must handle
Work crosses several systems and decision points. A single prompt or point-to-point automation cannot preserve context or handle exceptions
02 / THE ARCHITECTURE
How the pieces connect
Use a stateful workflow with specialized agent steps, shared context, tool validation, retry rules, and explicit approval and escalation paths
03 / OPERATING MODEL
How the system behaves
The system can carry routine work across multiple steps while routing uncertain or high-impact decisions to the right person
WHY THIS PATTERN EXISTS
The problem it solves
Most operational failures are not model failures. They are integration failures wearing a model as a disguise: a payload that changed shape, a record that was locked by a human, a timeout that left the system unsure whether the write succeeded. This pattern treats the process as a state machine with explicit transitions, where agents handle the judgment inside each step and deterministic code handles everything else. The value is not speed. It is that the process survives contact with reality.
COMPONENTS
What you are actually deploying
Durable state runtime
Each step is checkpointed with its input, output, and the decision that produced it. A process that dies mid-run resumes from the last completed step rather than restarting, which is the difference between an automation that is trusted and one that gets switched off.
Specialised agent steps
Each judgement in the process is a discrete step with one responsibility: classify this document, decide whether this exception is genuine, draft this reply. Narrow steps are evaluable. A single agent asked to do the whole process is neither testable nor improvable.
Typed tool validation
Every call into a business system is validated before execution, against the schema the system actually enforces. Invalid calls fail at the boundary with a recoverable error instead of writing a broken record into the CRM.
Idempotency and compensation
Writes carry idempotency keys so a retried call cannot duplicate a record. Where a step cannot be rolled back, a compensating step is defined at design time rather than improvised during an incident.
Approval and escalation gates
Uncertainty and high-impact decisions route to a named human with the full context attached: what was read, what was decided, what will happen on approval. The pause is a state in the workflow, so nothing is lost while waiting.
Exception queue
Anything the system cannot resolve becomes a structured task with the context, the attempts already made, and the suggested next action. Exceptions are a queue with owners, not a silent failure that disappears into a log.
FAILURE MODES
How these systems break
Every one of these has been found in production during an incident review. They are listed here because the design is only credible if it names what it defends against.
Lost context across steps
When each step reconstructs its own understanding, decisions drift and the same input gets treated differently twice. Context is carried explicitly in state and is part of the checkpoint.
Retry storms and duplicate writes
Naive retries after a timeout duplicate invoices, duplicate bookings, and duplicate CRM records. Every write needs an idempotency key and a defined retry policy before it ships.
Blind waiting
A workflow that pauses for a human outside the runtime loses the context that made the pause necessary, and the approval arrives with nothing attached. Approvals live in the state machine.
Unowned exceptions
Failures routed to a shared mailbox get triaged by whoever is nearest, which means the hard ones never get fixed. Exceptions need an owner, a queue, and a visible ageing measure.
FIT
When to use this, and when not to
Use it when
- The process crosses three or more systems, so context loss between steps is already costing you rework.
- Some fraction of cases is genuinely ambiguous and must reach a person, and you need that handoff to be informed.
- Failures are expensive and you need to know exactly what happened, in which order, with which inputs.
- The work happens often enough that the runtime, not the model, is the bottleneck.
Do not use it when
- The task is a single deterministic call. A workflow runtime adds latency and failure surface for no gain.
- No one owns the exception queue. Automating the happy path without an owner for failures makes the process less reliable, not more.
- The systems involved have no stable API. Orchestrating across screen-scraped interfaces produces a workflow that cannot be guaranteed.
QUESTIONS
What teams ask before building this
When do I need a workflow runtime instead of a single agent call?
When the process has multiple steps, more than one system, or a decision that sometimes needs a human. A single agent call is right for one task with one tool. The runtime earns its cost the moment context, state, or failure recovery has to survive across steps.
What happens when a step fails halfway through?
The process resumes from the last completed checkpoint with the state that produced it. Writes are idempotent, so a retried step cannot duplicate a record, and any step that cannot be rolled back has a compensating action defined at design time.
How do approvals work without stalling the process?
The pause is a state inside the runtime. The approver receives the exact context the decision needs: what was read, what was decided, and what will happen if they approve. Nothing is re-derived after the approval, so nothing is lost while waiting.
How do you prove the automation is correct?
Every run stores its inputs, decisions, and outputs, so any execution can be replayed. Historic runs become the regression suite: when a rule changes, the affected executions are re-scored before the change ships.
DEPLOYED THROUGH
Capabilities that build it
APPLIED IN