AI Workflow Orchestration: State, Retries, and Handoffs

AI workflow orchestration is the practice of coordinating multiple agent steps — each with its own tools, context, and outputs — into a coherent sequence that produces a result a person can use or review. The orchestration layer handles state between steps, decides what happens when a step fails, and routes outputs to the right next action. Tools like fenbs store the approved work record and handoff notes that live outside any single run, so a resumed or replacement agent starts from the same agreed state.

The common failure modes in orchestrated workflows are not model errors — they are state management errors: a step that did not receive the output it expected, a retry that ran with stale input, or a handoff that lost the partial result from an interrupted run. Designing the orchestration layer means designing for those failures explicitly.

What the orchestration layer does

An orchestration layer sequences agent calls, passes the right state to each one, and handles the output. It can be a workflow framework, a purpose-built agent graph library, a simple state machine, or even a loop in application code. The implementation detail matters less than whether it addresses the three core jobs: managing what each step receives, deciding what happens when a step fails, and routing results to the next step or to a human reviewer.

Keep the orchestration layer separate from the individual agent implementations. An agent that does research should not also decide when to retry itself or when to escalate to a human. Those decisions belong in the orchestration layer, where they can be changed without modifying the agent.

Structuring workflow state

Each step in a workflow should receive only the state it needs to do its job. That means defining typed inputs and outputs for each step before building the workflow. A step that receives a large, undifferentiated context object will use parts of it in ways that are hard to predict or change.

Model partial completion explicitly. A step that finishes half its work and stops is in a different state from one that failed immediately. If the next step or a retry needs to know where the partial result is, include a status field and a reference to the partial output in the state model, not just a boolean success flag.

Separate durable state from ephemeral state. Durable state — approved decisions, completed subtasks, confirmed results — should persist outside the execution engine. Ephemeral state — the in-progress context of a single run — can live in memory or a short-lived cache. If the process stops unexpectedly, the durable state should still be recoverable.

Retries and idempotency

Design each step to be idempotent where possible: running it twice with the same input should produce the same result without unintended side effects. That makes retries safe. If a step is not idempotent — it sends a message, charges a card, or modifies a record — add a check before the retry that verifies whether the action already completed.

Retries with the same parameters that caused a failure will usually fail again for the same reason. Build in a mechanism to vary the input on retry: a different prompt framing, a narrower scope, a lower temperature, or a fallback to a different model. If three retries with different parameters still fail, stop and route the step to human review rather than retrying indefinitely.

Human review checkpoints

Not every step should be automated. Identify the points in the workflow where a person should confirm a result before the next step runs. Common checkpoints: before an action with external effects (an email send, a database write, a payment), before a decision that affects many downstream steps, and before a high-confidence result is used as ground truth by a later agent.

Model the checkpoint as a step that produces a pending state and waits for a human signal. The workflow pauses at the checkpoint, a person reviews the output, and the workflow continues when the person confirms or rejects it. A rejection should carry a reason that the next run can use to produce a better output.

Tracking handoffs between agents

When one agent hands off work to another — a research agent passes findings to a writing agent, or a planning agent passes a spec to a coding agent — the handoff record should say what was completed, what the receiving agent needs to do, and what constraints apply. That record is what allows a human reviewer to audit the workflow without replaying every step.

For long-running workflows or workflows that span multiple sessions, keep the handoff record in a persistent store that all agents can read. A session-local variable is not enough. When a workflow resumes after an outage or a model change, the first step should be to read the durable record and describe the current state before proceeding.

How to do this with fenbs

Start with one workflow and identify its two or three riskiest state transitions. Write the approved decisions about how those transitions should work as Decisions and rules in fenbs, then connect your orchestration agent to read them before each run.

1. Create a free account. Add the workflow as a project with a description of its goal, the steps it involves, and the external systems it touches.
2. Add tasks for each significant workflow step. Record what each step receives, what it produces, and what the success condition is.
3. Write orchestration rules in Decisions and rules: retry limits, escalation conditions, checkpoints that require human review, and actions the workflow must not take automatically.
4. Connect your orchestration or coding agent at Integrations. Ask it to read the project context before each run, and to update the task record with what each run completed and what is still pending.
5. After each workflow run, record any new failure mode or state transition problem as a lesson. Review lessons before modifying the orchestration logic.