AI Agent Orchestration: Patterns, Approvals and Cost Controls

AI agent orchestration works best when you choose who owns the next step before adding another agent. For intake, research, drafting and approval, 4 patterns cover the main decisions: a lead with workers, handoffs between specialists, a graph with checkpoints, and a durable workflow around the agents. Keep permission to send, spend or change records outside the model's discretion.

Documentation and the infrastructure prices below were verified on 13 October 2026. The business examples are proposed designs, not reported deployments or performance benchmarks.

What Is AI Agent Orchestration?

Orchestration decides which agent works next, what information it receives, and what must happen before its result can become an action. An agent combines a model with instructions and tools. The orchestrator supplies the coordination around those agents: ownership, shared state, permitted transitions and stopping conditions.

Your intake agent may already turn a messy request into a useful brief. Adding a researcher and a writer creates new questions. Who resolves conflicting evidence? Which draft did the approver see? If the email service times out, did the message go out? Those questions belong to the process design.

Choose the pattern by the boundary you need:

These patterns can be nested. A durable case workflow can call a graph; a node, meaning a step in that graph, can ask a lead agent to delegate research. Each layer should have a distinct job. Adding layers without a distinct responsibility adds more places to debug.

What changes from the single-agent setup is accountability. The operations lead needs a queue of cases with owners and next actions. The engineering lead needs saved state and recoverable execution. A buyer needs to know which of those responsibilities the chosen service operates and which remain yours.

Lead Agent With Workers: Keep One Owner

Use a lead with workers when the job benefits from specialist work but needs a single coherent answer. Think of a proposal owner asking colleagues for evidence, then assembling the proposal. The colleagues contribute; they do not independently promise anything to the customer.

For a sales-operations request, the lead can commission account research and an internal product-fit check, then combine their findings into a drafting brief.

1. 1

   Give the lead an outcome and a boundary

   The outcome is an evidence-backed proposal draft. The permitted work is research and drafting. Sending the proposal, promising a discount and updating a customer record remain separate actions.

2. 2

   Dispatch bounded research tasks

   Give each worker the relevant source material, allowed tools, expected output and stopping rule. Run independent research concurrently; wait when one task genuinely depends on another's result.

3. 3

   Return evidence, then synthesize

   Require source references, findings and unresolved questions. The lead reconciles contradictions and produces the draft. A missing source stays missing; it does not become a confident sentence through summarization.

4. 4

   Submit the artifact for approval

   The account owner reviews the proposed message, recipient and commitments. An application-controlled send step executes only the approved artifact.

Claude Agent SDK, Anthropic's programmable agent runtime, implements this pattern through subagents: separate agent instances with their own instructions, context and tool access. Define them with the agents option; the main agent invokes them through the Agent tool. A normal, non-fork subagent does not receive the parent's conversation history, so its task prompt must carry the context it needs. The parent receives its final report. Claude subagent documentation.

The useful boundary is an evidence contract. A researcher can return a recommendation plus the source passages that support it. The wall: an isolated context can also omit an essential customer constraint. Pass the constraint explicitly, and keep the supporting artifact available for review.

CrewAI, a framework for role-based agents and tasks, offers a hierarchical process with a manager_llm or manager_agent. Its manager plans, delegates and reviews task outputs. A sequential process instead follows the task list, using earlier results as context. CrewAI process documentation.

Choose the hierarchy when allocating work requires judgment. If research must always precede drafting, an explicit sequence is easier to inspect. The wall: a manager's review is still an automated judgment. CrewAI's human_input task option requests human review of the final answer; give the research and drafting tasks read-only capabilities so that review cannot arrive after a consequential write. CrewAI task documentation.

Handoffs: Give a Specialist the Next Decision

Use a handoff when a different specialist should own the next response or branch of work. It resembles transferring a support case to billing, with the case record attached. It differs from asking billing a question and remaining the case owner yourself.

OpenAI Agents SDK, a library for agent applications, makes that ownership distinction explicit: handoffs transfer control to a specialist, while agents exposed as tools leave the manager responsible for the reply. Its JavaScript agent.asTool() supports the latter. Handoffs can include structured metadata or filtered history. OpenAI orchestration documentation.

For a customer-operations inbox, use this sequence:

1. The intake agent identifies a billing dispute and collects the relevant account and invoice references.
2. It transfers the case to the billing specialist with the customer's request, verified facts, unresolved questions and permitted next actions.
3. The billing specialist investigates and drafts a resolution. It owns the next response instead of returning a research memo to intake.
4. A person approves any proposed refund or account change before the corresponding tool executes.

The wall: a handoff transfers control, not business authorization. An agent receiving a case should not inherit permission to refund simply because the intake agent routed it there. Enforce the action policy where the refund tool runs.

Also decide whether a specialist can hand the case back. Allow an explicit escalation with a reason; cap repeated transfers. Otherwise an ambiguous request can bounce between specialists while consuming model calls and making no progress.

The SDK's approval lifecycle returns interruptions and resumable state for application review. Persist that state for delayed decisions and resume the same run. Input guardrails apply at the first agent, and output guardrails at the final-output agent; put checks around sensitive tools rather than assuming those outer checks inspect every internal action. OpenAI human-review documentation.

Graph With Checkpoints: Make the Next Step Explicit

Use a graph when the allowed routes matter more than which agent improvises the plan. A graph is a set of steps connected by rules. A checkpoint is a saved record of progress so the process can pause and later continue.

LangGraph, a framework for stateful agent workflows, supports explicit workflow routes, including branching and parallel work. Its checkpointers save graph state for a thread, while its interrupt() mechanism pauses for external input. Resume the interrupted thread using Command(resume=...). LangGraph workflow patterns, interrupt documentation.

For a procurement team preparing a supplier recommendation:

1. 1

   Store the case as structured state

   Keep the request, evidence references, missing information, draft location and review status in named fields. A transcript can accompany the case, but it should not be the only place the current status exists.

2. 2

   Draw the permitted routes

   Intake moves to research when required fields exist. Missing information returns to the requester. Research feeds drafting; an evidence check can send the case back for targeted research.

3. 3

   Checkpoint and pause for review

   Save the proposed recommendation and interrupt before approval-dependent work. The procurement owner reviews the exact artifact, supporting evidence and requested action.

4. 4

   Resume into a permitted branch

   Approval enables submission. Requested edits return to drafting and invalidate the old approval. Rejection closes the case with a recorded reason.

The wall: resuming a LangGraph interrupt restarts the containing node from its beginning. Code before the interrupt runs again. Put a consequential write in a separately controlled step, and make repeatable operations idempotent: repeating the same logical request must not create an additional effect. LangGraph's interrupt rules.

For example, a node that submits a supplier record and then asks for approval has already crossed the boundary. It can also submit again when resumed. Prepare the proposed change first, obtain approval, then execute the approved change with a stable action identifier.

Choose persistent checkpoint storage for production. LangGraph's in-memory savers lose checkpoints on process restart. A persistent thread identifier and database-backed state are part of the recovery design. LangGraph persistence documentation.

Durable Workflow: Keep the Case Alive Around the Agents

Use a durable workflow when the business process must survive the agent call ending, a worker restarting or a delayed external response. It owns the case lifecycle: start, wait, retry, resume, finish or escalate. An agent is a participant inside that lifecycle.

Cloudflare Workflows, a service for durable multi-step execution, provides persisted steps and configurable retries. Use step.do for work, step.waitForEvent for an external decision, and instance.sendEvent to deliver that decision to the waiting instance. Cloudflare Workflows, events documentation.

For an operations team handling a custom service request:

1. Create a case record and stable workflow identifier when the request arrives.
2. Call the research agent, persist its evidence artifact, then call the drafting agent with that artifact.
3. Save the proposed response and wait for the operations lead's approval event. The approval interface identifies both the case and the artifact version.
4. Validate the decision and execute the approved send or record update in a separate step.
5. Record the external receipt and complete the case. If completion is uncertain, reconcile with the external system before issuing another write.

The wall: durable execution does not make an external service's action automatically safe to repeat. Cloudflare explicitly recommends idempotent API calls, granular steps and deterministic step names, and warns against side effects outside step.do. If a service accepted a send but its response was lost, retrying without deduplication can send again. Rules of Workflows.

Configure retries for transient failures, meaning failures that may clear without changing the request. Authentication failure, rejected approval or an invalid business instruction usually needs intervention. Cloudflare exposes retry configuration and NonRetryableError for failures that should stop retrying. Retry documentation.

A LangGraph application with persistent checkpoints already has recovery capabilities. An additional workflow engine earns its place when it owns a broader lifecycle across services, callbacks and agent runtimes. Avoid making both layers independently retry the same paid or side-effecting operation. The boundary is developed further in managed-agent outcomes, webhooks and the Cloudflare workflow.

Put Human Approval at the Action Boundary

A person should approve the exact consequential action before it executes. Reviewing a fluent draft is insufficient if another agent can later change the recipient, amount or attachment.

For a proposal, the review surface should show the recipient, final message, attached document, commercial commitments and evidence behind uncertain claims. The approval record should bind the reviewer's identity to that artifact version and those action arguments.

Design the executor to check that record immediately before acting. If the draft or destination changed after approval, return the case to review. Use an explicit approval decision from the authorized person; keep comments and suggested revisions separate from that decision.

CrewAI Flows can persist state with @persist and pause for feedback with @human_feedback. One detail matters for consequential actions: when configured with emit outcomes, the feedback mechanism uses a language model to interpret free-form feedback into an outcome. Use a separately validated approval field for authorization, rather than treating an interpreted comment as the sole permission to act. CrewAI Flows documentation.

Place another permission boundary wherever the process can make a new purchase. Retrying a failed connection and buying a new output because the agent disliked the completed result are different decisions. The latter needs a defined spending allowance or fresh approval. See human approval for AI agent retries for that narrower failure mode.

What to Log and Cap

Log enough to reconstruct the case, and enforce caps before starting more work. A polished final response cannot explain why a process sent the wrong artifact or exceeded its budget.

Use these field groups in the case record and execution events:

• Identity and lineage: case ID, workflow/run ID, parent and child run IDs, agent role, current step and attempt. These connect a worker's failure to the business request.
• Inputs and configuration: input artifact references and versions, model identifier, prompt/configuration version and allowed tool set. These identify what changed between runs.
• Decisions and evidence: routing decision, selected destination, source references, validation findings and missing information. Record observable decisions and concise reasons; do not depend on private model reasoning.
• Approval: reviewer, decision, timestamp, artifact digest, action arguments and expiry. A digest is a fingerprint of the reviewed content.
• Actions and recovery: tool name, redacted arguments, action/idempotency key, external request ID, receipt, failure category and scheduled retry. Preserve an explicit uncertain status when the outcome is unknown.
• Usage and outcome: model token categories, estimated and reconciled spend, paid tool usage, elapsed time, review wait, final status and whether a person accepted the result.

Restrict who can read these logs. Keep secrets out, minimize customer data, and use references to access-controlled artifacts where copying the full content would create unnecessary exposure.

OpenAI Agents SDK tracing records model calls, tool calls, handoffs and guardrails. Link those technical traces to your case record; the trace alone should not be the business authority for whether a customer action was approved. OpenAI tracing documentation.

AI Agent Orchestration Tools Need Enforceable Caps

Set limits on whole-case spend, agent turns, tool calls, concurrent workers, delegation depth, handoff count, retries and wall-clock duration. Separate the active execution deadline from the human-review deadline. Choose the values from the business's acceptable cost and delay; there is no universal safe default.

Reserve budget before dispatching concurrent work, then reconcile it when each call finishes. Otherwise every worker can observe the same remaining balance and spend it independently. Account for resumed runs against the same case budget.

Claude Agent SDK exposes query spending controls, including maxBudgetUsd in TypeScript and max_budget_usd in Python, plus subagent depth and concurrency controls. Check the installed-version requirements in the subagent documentation.

The accounting boundary is important: its usage field excludes subagent activity, while modelUsage or model_usage includes it. total_cost_usd includes subagents but is a client-side estimate. A query's spend cap covers that call's own spending, not earlier spending restored from a resumed session. Keep a case-level ledger and reconcile estimates against authoritative usage. Claude cost-tracking documentation.

An SDK budget setting is also not a promise of an exact final invoice ceiling: the documented capped result can finish at or above the threshold. Leave room for in-flight work and stop dispatching before the business allowance is exhausted.

The Cost of Orchestration Comes From the Whole Case

Budget the completed business outcome, including unsuccessful work and review. More agents can shorten independent research, but they can also repeat context, add synthesis calls and create revision loops. The business case is whether the accepted result improves enough to cover that added cost.

Use this monthly model:

Process cost = model usage + paid tools + workflow infrastructure + state and log storage + human review + operations.

Then divide by approved outcomes, not by agent runs. Failed cases and discarded drafts still belong in the numerator. Compare that cost with your current process using the same acceptance standard and staff-cost assumptions; no credible savings percentage can be derived without those inputs.

For a concrete infrastructure anchor, Cloudflare lists these charges:

Sources: Workers pricing and Workflows pricing. The account minimum is infrastructure, not an all-in agent price. Requests, CPU time (processor work), model calls and other services still need accounting. The billing announcement dates step and storage billing to no earlier than August 10, 2026; the public wording does not confirm activation for an individual account.

Our arithmetic: dividing the published $0.80 by 100,000 gives an effective $0.000008 per additional step, before the other charges. That is a unit conversion of the listed rate, not a workload estimate or measured bill. Published step rate.

Waiting does not have to consume an active model loop. Cloudflare states that API waits, sleep and idle time do not incur CPU time. State storage and step accounting remain separate. Persist the case and await an event instead of repeatedly asking an agent whether the approver has responded. Workflows pricing.

AI Agent Orchestration Frameworks Fit Inside the Process

Choose the coordination boundary before the framework. Keep one owner when you need synthesis, transfer ownership when the next specialist should act independently, use a graph when allowed transitions matter, and add durable lifecycle control when work must outlive a call.

The AI agent frameworks comparison covers the framework-by-framework selection. If the choice has narrowed to explicit graph state versus role-based crews, use LangGraph vs CrewAI.

An engineering lead should make persistence, execution permissions and recovery ownership explicit. An operations lead should specify acceptance criteria, approvers, escalation and allowable spend. A buyer should ask who operates those controls, where records live, and how a paused case is recovered after a failure.

A platform can operate infrastructure for you. It cannot decide what your business considers an approved refund, a supported proposal claim or an acceptable extra purchase.

What Is Overhyped

More agents do not establish better results. Give separate agents distinct sources, tools or responsibilities. Asking interchangeable agents to repeatedly critique each other can consume budget without adding evidence.

A graph drawing also does not prove durability. The saved state, the persistence backend and the replay behavior determine what survives a failure. Likewise, a prompt saying "ask before sending" does not enforce a send policy; the executor must check permission.

Finally, keep model-directed planning inside a bounded task. Let a researcher choose which relevant source to inspect next. Keep the decision to expose private data, approve an expense or send a customer message under the application's access and approval rules.

The Monday Move

Start with one process and the smallest extra boundary it needs. Keep the agent that already works. Write down its input, output artifact, tools, owner, success condition and stop condition, then add the missing research or drafting responsibility.

Before enabling customer-facing writes, exercise failure cases with representative, non-sensitive inputs: interrupt execution after saving a draft, deliver an approval twice, reject a proposal, change an approved artifact, exhaust the budget, and simulate an external write whose response is lost. Confirm that the case reaches a recorded state with a clear next action.

Act now if work crosses specialist ownership, waits for approval or needs reliable recovery. Wait on adding agents if the current failure is poor source data or an unclear acceptance standard. A reliable single-agent process with no such boundary can stay as it is.

Questions From the Process Owner

Do I need an AI agent orchestration platform if one agent already works?

Only when you need coordination or operational capabilities your existing application lacks. Start by naming the missing responsibility: specialist ownership, saved progress, delayed approval or recovery. That requirement decides whether to add a library, a workflow service or a small amount of application code.

Can I combine these patterns in the same process?

Yes. A durable workflow can own the case while a graph controls review routes and a lead agent delegates research. Give each layer a clear responsibility and avoid overlapping retry policies for the same operation.

Does approving a draft also approve another paid attempt?

Only if the approval explicitly includes that spending scope. Approval to use an artifact and permission to purchase another attempt should be recorded separately. A changed draft also needs review before its consequential action proceeds.

What should happen if the approver never responds?

Expire the pending decision under a defined policy, notify the responsible owner, and hold or close the case. Store enough context for later review. Silence must not turn into automatic approval.

Join the newsletter for practical guides to building and operating business workflows with AI.