Multi-Agent Orchestration Tools: What Each One Actually Owns

The expensive mistake in multi-agent design is choosing an orchestrator before deciding what must survive a failure. A handoff is not a checkpoint. A child session is not a graph node. A trace is not a retry record. Products can place all four words on the same feature page while assigning responsibility to completely different parts of the system.

That makes a league table of multi-agent orchestration tools less useful than it appears. OpenAI Agents SDK, LangGraph, Google Agent Development Kit, and OpenClaw can all coordinate specialized agents, but they operate at different boundaries. One decides who owns the next response. Another persists graph state. Another makes code and agents explicit nodes in a workflow. Another detaches work into sessions and records longer-lived flows above them.

This decision memo compares their current documented behavior as of July 22, 2026: OpenAI Agents SDK 0.18.3, LangGraph 1.2.9, Google ADK 2.5.0, and OpenClaw 2026.7.1. It does not rank model quality or quote a synthetic speed benchmark. A local decision-policy sanity check encoded eight workload shapes and checked 32 internal assertions about control ownership, recovery state, and maturity. That narrower exercise makes the policy inspectable; it does not validate the frameworks themselves.

The missing column in most comparisons is ownership after failure

Suppose a research specialist finishes, the reviewer rejects its evidence, and the process stops before the user sees an answer. What is authoritative now? It might be the manager agent's in-memory run, a graph checkpoint keyed to a thread, a detached child session, or a durable flow record linked to several tasks. Each can be correct. Trouble starts when the design cannot name one.

The practical test is not “how many agents can it spawn?” It is “which component is allowed to advance the work after a timeout?” If two components can both answer that question, a retry can become duplicate work. If none can, a completed specialist can disappear behind a failed coordinator. The orchestration boundary is where that ambiguity must end.

OpenAI Agents SDK: decide who gets the conversation

The OpenAI Agents SDK orchestration guide draws a useful distinction between agents as tools and handoffs. With agents as tools, a manager keeps control. Specialists return bounded results, and the manager combines them into the user-facing answer. With a handoff, a triage agent transfers control and the selected specialist becomes active for the rest of the turn.

Those patterns can use the same specialist prompts and tools, yet they assign accountability differently. Manager ownership is a good fit when one component must apply common policy, reconcile several findings, or produce a single response. Handoffs fit a support or intake flow where the selected specialist should talk directly, keep its own focused instructions, and retain the conversational state that follows.

The SDK also documents code-defined orchestration: structured routing, chains, evaluator loops, and parallel calls. That matters whenever cost limits, maximum iterations, or the order of side effects should not depend on another model decision. An LLM can still classify or evaluate inside the flow; application code retains the right to accept, retry, or stop.

Built-in tracing records model generations, tool calls, guardrails, handoffs, and custom spans. It is valuable evidence, but it does not automatically become an application recovery protocol. The tracing guide notes that generation and function spans may contain sensitive inputs or outputs, capture can be disabled, and long-running workers may need an explicit flush when immediate export is required. A trace can explain a failed run while the application still needs its own idempotency key and durable action receipt.

Choose this SDK boundary when the work fits inside an application run and the central question is conversational ownership. Do not infer restart durability from a rich trace. If an approval must survive a process restart, or an external action must be reconciled after ambiguous delivery, add an application record that can answer those questions without replaying the model transcript.

LangGraph: pay for checkpoints when replay is the requirement

LangChain's current multi-agent guide starts with a welcome warning: a single agent with the right dynamic tools and prompt can often handle a complex task. Its documented patterns—subagents, handoffs, skills, routers, and custom LangGraph workflows—are mostly choices about context. Which component sees the full conversation? Which receives a narrow task? Which one speaks to the user? Which team can maintain it independently?

LangGraph becomes the material choice when the state transition itself needs to be explicit and recoverable. Its persistence contract separates checkpointers from stores. A checkpointer saves snapshots of one thread's graph state for continuity, human interruption, time travel, and fault tolerance. A store keeps application-defined information across threads. These are not synonyms for “memory.” One reconstitutes where a workflow was; the other supplies data that may outlive or span workflows.

This distinction prevents two common recovery bugs. The first is expecting an in-memory saver to survive a restart; the documentation explicitly says it will not. The second is treating shared store data as proof that a side effect completed in a particular graph step. A user's preference may belong in a store. A payment request ID, approval digest, or external message receipt belongs in a transaction record that the replaying node can verify.

A production pilot should kill the worker between a model result and the next side effect. Restart it with the same thread ID. Confirm that the graph resumes from the intended checkpoint, that completed external actions are not repeated, and that a human interrupt remains attached to the correct version of state. Then inspect retention. Checkpoints that make debugging delightful can also grow without bound if nobody owns pruning.

LangGraph is therefore not “the enterprise choice” by default. It is the justified choice when a graph checkpoint is the record the operator actually needs. If every request is short, read-only, and safe to restart from the beginning, adding a durable graph may simply create a second state system beside the database that already owns the business transaction.

Google ADK: explicit graphs, with maturity labels left intact

Google ADK 2.x now presents several orchestration structures rather than one multi-agent recipe. The workflow overview lists graph-based, dynamic, collaborative, and template workflows. Graphs combine AI agents, functions, tools, human input, and routing as explicit nodes and edges. Dynamic workflows keep control in ordinary program logic. Collaborative workflows let a coordinator work with specified sub-agents. Template agents cover fixed sequential, parallel, and loop patterns.

This is attractive when typed data should move through a mixed code-and-agent process. A classifier can produce a constrained value, a deterministic function can validate it, and explicit routes can select one or several next nodes. The graph communicates the execution contract more honestly than a long prompt containing “always run validation after research.”

The current documentation also preserves caveats that a procurement summary should not erase. ADK's graph page says live streaming is not supported and some third-party integrations may be incompatible. TypeScript RoutedAgent is marked experimental. Its fallback is precise: the router can select another agent if the first fails before yielding any event. Once partial output has been emitted, the error propagates rather than silently re-routing.

That before-or-after-first-event boundary is a strong design clue. Before output, another agent may safely become the sole producer. After output, the system has a reconciliation problem: what did the caller already receive, and can a second producer continue without contradiction or duplication? Calling both situations “automatic failover” would conceal the part the operator must handle.

Partial output is a commitment.

Choose ADK when its graph or dynamic workflow maps cleanly to the application and the documented language and feature surface matches the pilot. Record experimental status beside the decision. A library can be stable enough for a bounded use case while one routing API remains unsuitable as the only recovery mechanism.

OpenClaw: detached work makes the session a first-class boundary

OpenClaw coordinates work at a different altitude. For ordinary non-thread native runs, its sub-agent contract defaults to isolated context unless the caller explicitly forks the transcript; thread-bound sessions are the documented exception and default to a forked context. External harnesses such as Claude Code or Gemini CLI can run through the ACP path when configured. The parent remains responsible for external delivery even when a child completes successfully.

That last rule is easy to underestimate. A child can research or change code without inheriting the entire chat and without being allowed to send its own half-finished result to the source channel. The parent decides whether the result satisfies the request, how it combines with other work, and what is safe to deliver. Isolation reduces accidental context leakage, but it also requires a complete delegated task and an explicit artifact contract.

Task Flow sits above detached tasks when the work needs a durable multi-step record. A managed flow keeps status, JSON state, linked tasks, a controller identity, and a revision. Mutations carry an expected revision, so a stale writer gets a conflict instead of overwriting newer progress. Cancellation is sticky and prevents new child tasks while active work settles. Mirrored flows give detached one-task runs a stable handle without pretending they are a multi-step pipeline.

Use native sub-agents for bounded, independent work whose completion should return to a parent session. Use a managed Task Flow when several detached tasks, waits, or restarts need one durable controller record. Use ACP when an external coding harness is the intended runtime, not as a generic synonym for another OpenClaw agent. The tools compose, but each additional layer must own a distinct record.

OpenClaw is not a replacement for an in-process application graph simply because it can spawn children. A web request that needs millisecond-scale typed transitions may belong in an SDK or graph library. Conversely, a long code migration that must continue outside the chat turn is awkward to force into a conversational handoff. The unit of work decides the boundary.

Testing the routing policy, not the frameworks

The local sanity check encoded eight deliberately different scenarios. It did not install four frameworks or call a model; doing so would have produced a fragile benchmark of sample prompts and network conditions. Instead, it checked whether a source-derived decision policy could name exactly one control owner and one recovery boundary for each scenario.

All 32 internal consistency assertions passed: eight unique routes, eight expected decisions, eight ownership matches, and eight recovery-and-maturity matches. The result says nothing about framework quality, latency, or production reliability. It sanity-checks the disclosed routing policy: the policy reaches one non-contradictory answer without a universal maturity ladder, and “use one agent” remains a valid outcome.

Failure modes a feature matrix cannot show

A credible pilot needs an interruption point, not just a happy-path demo. For manager orchestration, terminate the specialist after it returns a partial result and verify that the manager does not present it as complete. For a handoff, change the specialist's availability after triage and confirm whether the application can recover without losing conversation ownership.

For a checkpointed graph, kill the worker after the model result but before an external write. Recovery should either prove the write never happened or reconcile a receipt before retrying. For ADK routing, force one failure before any event and another after partial output; the correct behaviors should differ. For detached sessions, let the child complete while delivery fails, then verify that rerunning delivery does not rerun the child. For a durable flow, race two state updates and require one stale revision to fail.

These drills expose the real operating cost:

• State duplication. A checkpoint, trace, session transcript, business database, and task ledger may all describe the same work. Only one should authorize the next external action.
• Context duplication. Copying the full transcript into every specialist raises cost and widens the disclosure surface. Sending too little creates plausible but ungrounded work.
• Approval drift. An approval attached to a prompt or task title can survive after the proposed action changes. Bind it to the exact payload or digest that will execute.
• Partial-output ambiguity. Once a user, webhook, or external system has received something, failover becomes reconciliation. Another agent cannot safely pretend the first attempt never existed.
• Cancellation latency. A coordinator may mark work cancelled while a child or side effect is already running. The system needs a durable cancel intent and a terminal receipt, not a red badge in a dashboard.

None of these problems is solved by adding a supervisor agent. They are data-ownership questions. Agents can help interpret evidence, but code and durable records must make the dangerous transitions unambiguous.

The upgrade path is a set of pressure tests, not a ladder

Begin with the smallest design that can fail safely. If one agent can load the right skill or tool on demand, keep one agent. Add a manager when specialists need bounded context but one component must own the answer. Use a handoff when the specialist genuinely should take the conversation. Introduce a graph when transitions, interrupts, or replay are part of the product contract. Detach work into sessions when it outlives the request or needs a separate runtime. Put a durable flow above tasks when several detached steps require revisioned coordination.

There is no automatic progression from SDK to graph to session runtime. A large customer-service system may remain a clean handoff application. A two-step financial workflow may justify durable checkpoints immediately. A single coding task may need an isolated child session but no multi-agent conversation. The architecture should grow along the pressure that is actually present.

Before adopting an orchestration tool, write one sentence that names the authoritative owner after a timeout and one sentence that names the record used to resume. If either sentence names two systems, the design is not ready.

The four tools compared here are all useful. They are useful for different reasons. OpenAI Agents SDK makes conversational delegation explicit. LangGraph gives thread state a durable graph boundary. Google ADK mixes agents and deterministic nodes through several workflow forms, with current limitations visible. OpenClaw turns detached sessions and multi-step task coordination into operational records. The right choice is the one whose boundary matches the failure you need to recover—not the one with the longest agent list.

Primary-source record. Documentation and official release metadata were checked on July 22, 2026. The saved boundary probe used no production model, user data, external action, or live framework benchmark; it reported 32 of 32 internal consistency checks and is evidence for the disclosed decision policy only.