From a Workflow to a Drainable Queue: Designing Orchestration That Can Stop Cleanly

This article shows how to design an agent workflow as a sequence of resumable queue items, with explicit states, narrow handoffs, and review gates around external effects.

The queue is the workflow’s memory boundary

The central mistake in orchestration is treating the running process as the source of truth. While an agent is active, context appears abundant: the prompt, tool results, temporary decisions, and the next intended action are all close at hand. The moment execution pauses, crashes, or changes owners, that context becomes an unreliable place to store a commitment.

A queue provides a better boundary. It records the work that must survive the current process, not every thought that occurred during it. That distinction keeps the system useful. A queue item should answer enough of these questions for another run to continue:

• What outcome is required?
• What state has already been verified?
• What is the next bounded action?
• What evidence or approval is still missing?
• Which side effects are forbidden until review?

The result is not a transcript. It is a resumable contract.

Model states, not just tasks

“Research the feature” is a task description, but it is a poor orchestration state. It does not say whether the agent is collecting sources, reconciling conflicting requirements, preparing a draft, or waiting for approval.

A more useful workflow gives each item a small state machine. For example:

1. 1. Committed — the work is accepted and has a clear owner or queue position.
2. 2. Ready — prerequisites are satisfied and the next action can run.
3. 3. In progress — an agent is actively performing the bounded action.
4. 4. Blocked — execution needs a missing input, unavailable dependency, or human decision.
5. 5. Review — the proposed result exists, but an external effect or claim requires inspection.
6. 6. Done — the artifact or action has been verified.

These labels are valuable only if transitions have evidence. A task should not become Done because an agent produced a confident sentence. It should become Done because the expected file exists, the test result is recorded, or the approved transport returned a successful result.

This is where orchestration differs from a pile of prompts. Prompts request activity. States preserve truth between activities.

Drain commitments before generating more work

An autonomous system can create work faster than it can finish it. Every failed attempt, speculative suggestion, and newly discovered edge case can become another item. Without an ordering rule, the queue grows while attention moves to whatever is newest or most interesting.

A calmer default is commitment-first drainage. Resume ready items before creating optional work. If an item is blocked, record the blocker and move to the next committed item only when doing so cannot violate dependencies. Suggestions remain suggestions until explicitly committed.

This ordering has two practical benefits. First, it reduces duplicate work: an agent sees that a related item is already underway instead of opening a second thread. Second, it gives pauses a stable meaning. Stopping the run does not mean abandoning the workflow; it means leaving the next committed action in a durable state.

A simple queue policy can be enough:

• take the oldest ready committed item;
• perform one bounded action;
• persist the result and next state;
• stop when the action budget, time budget, or review boundary is reached.

The point is not maximum throughput at every moment. It is predictable progress without hidden backlog.

Make handoffs narrow and evidence-bearing

A handoff should transfer a result, not merely a request. “Please continue the workflow” forces the next agent to reconstruct intent. “The source inventory is complete; three URLs remain unresolved; compare them and update research/source-map.md without publishing” gives the next agent a route.

Useful handoffs usually contain four parts:

1. 1. Completed work: what was actually done.
2. 2. Evidence: paths, test output, source links, or response identifiers.
3. 3. Open condition: the exact uncertainty or remaining action.
4. 4. Boundary: what the next agent may not do yet.

The boundary matters most when the workflow can affect the outside world. Drafting an email is different from sending it. Preparing a site change is different from deploying it. Producing a booking itinerary is different from purchasing a ticket. Keep preparation and external effect as separate states so review is a real transition rather than an implied assumption.

This also makes retries safer. If an action fails after writing an artifact, the next run can inspect the persisted result and resume from the appropriate state instead of repeating the entire workflow.

Stop conditions are part of orchestration

A workflow that has no clean stopping rule will either run forever or stop opaquely. Both outcomes are difficult to operate.

Define stopping conditions alongside the happy path. Stop when the next action crosses a review gate. Stop when required information is missing. Stop when the budget is exhausted. Stop when the item reaches Done. In each case, persist a compact checkpoint before returning control.

A checkpoint does not need to be elaborate. It can say: “Draft written at this path; source review pending; no publication performed.” That sentence prevents a later run from confusing preparation with completion.

The checkpoint should also distinguish a blocker from a successful pause. A blocker asks for an input or decision. A successful pause simply preserves ready work for the next scheduled run. Treating both as failure creates unnecessary noise; treating both as success hides missing dependencies.

Conclusion: orchestrate for resumability

The companion lesson to “Queue up Work in COO” is that a queue becomes powerful only when orchestration respects it. Store commitments at the process boundary, represent meaningful states, drain ready work before inventing more, and make every handoff carry evidence plus a boundary.

For a practical implementation, start small:

1. 1. Give each workflow item an explicit state and next action.
2. 2. Persist the checkpoint after every bounded step.
3. 3. Separate drafts and proposed effects from reviewed external actions.
4. 4. Resume committed work before accepting optional suggestions.
5. 5. Require an artifact or recorded result before marking an item Done.

That design does not promise that every run will finish. It promises something more useful: when a run stops, the work remains understandable, reviewable, and ready to continue without noise.