Handoffs vs Subagents: OpenAI Agents SDK vs Google ADK vs LangGraph

“Multi-agent” is often used as if it describes one architecture. It does not.

For a coding workflow, there is a big difference between transferring ownership of the conversation to a specialist, calling a specialist and getting a result back, and running a fixed pipeline where the application controls the next step.

Those choices affect context visibility, testing, retries, approval boundaries, and how easy it is to explain a bad run.

This is a documentation-based comparison of three approaches: OpenAI Agents SDK, with handoffs and agents-as-tools; Google ADK, with parent/sub-agent transfer and workflow agents; and LangGraph, with subgraphs and explicit state.

I evaluated them on five criteria: who owns the next response, how state is passed, whether routing is model- or application-controlled, suitability for parallel or repeatable work, and what a developer can inspect after a failure. I did not run a common benchmark, so this is not a claim that one framework is faster or more reliable.

The key distinction: transfer or return?

Start with a coding task: “Inspect this pull request, run the tests, and suggest a patch.”

A handoff is appropriate when a specialist should take over. The original agent is no longer the owner of the next response. In the OpenAI Agents SDK, handoffs are exposed to the model as transfer tools, and the receiving agent continues the run. The SDK also supports typed handoff inputs and history filters.

A subagent call is appropriate when a manager should remain in control. The specialist does a bounded job, returns a result, and the manager decides what to do next. This is the safer default when a planner needs to combine several independent reviews before producing one answer.

A workflow graph is appropriate when the application should make control flow legible. A graph can say “run security review and test review in parallel, then require a synthesizer,” without asking a model to invent that structure at runtime.

The practical mistake is treating these as interchangeable function calls. They are different ownership models.

Comparison at a glance

Dimension	OpenAI Agents SDK	Google ADK	LangGraph
Primary control primitive	Model-selected handoffs or agents-as-tools	Parent/sub-agent transfer plus Sequential, Parallel, and Loop agents	Explicit graph nodes, edges, subgraphs, and state
Specialist ownership	Handoff transfers the next response; agent-as-tool returns to manager	Transfer can move the conversation; workflow agents keep orchestration explicit	Depends on graph design; nodes return state to the graph
Routing style	Usually model-selected, with application-configured destinations	Hierarchy or workflow configuration; custom agents can implement routing	Application-defined edges or router nodes
Context strategy	Full history by default, with handoff filters available	Session/state mechanisms and agent hierarchy	Shared or private schemas; subgraph persistence can be per-invocation or per-thread
Parallel work	Compose it yourself or use multiple calls	First-class ParallelAgent	Model parallel branches explicitly in the graph
Best fit	OpenAI-first apps needing lightweight delegation and tracing	Python workflows with clear parent/child or sequential/parallel stages	Stateful, inspectable workflows where control flow is part of the product
Main caution	A handoff can make ownership less obvious than a returned result	Transfer and workflow-agent semantics are easy to conflate	More explicit machinery means more design and state-management work

OpenAI Agents SDK: choose the ownership model deliberately

OpenAI’s orchestration guidance separates agents as tools from handoffs.

Use agents as tools when a manager should retain control. For example, a code-review manager can call a security specialist, a test specialist, and a documentation specialist, then reconcile their outputs. The manager owns the final answer and can enforce a common output contract.

Use a handoff when the specialist should own the next response. A triage agent can transfer a repository task to a migration specialist, which then asks the user for missing version details or continues with its own tools.

That distinction is useful for coding agents because “review this diff” and “continue this migration” are not the same job. The first often benefits from a bounded result. The second may require a specialist to take over a multi-turn interaction.

A production guardrail follows from the docs: do not assume an input or output guardrail automatically surrounds every agent in a handoff chain. Put checks at the tool or workflow boundary when every side effect must be reviewed.

Google ADK: hierarchy for delegation, workflow agents for pipelines

Google ADK exposes two related but different ideas.

A parent agent can transfer to a sub-agent when the sub-agent should handle the next interaction. That resembles a handoff: control moves down the hierarchy.

For automated multi-step work, ADK provides workflow agents:

• SequentialAgent runs children in a defined order.
• ParallelAgent runs independent children concurrently.
• LoopAgent repeats children until a termination condition or limit is reached.

This makes ADK a natural fit for a coding pipeline: collect repository context, run static analysis and tests in parallel, synthesize findings, then loop on repair-and-verify with a hard iteration limit.

The important choice is whether a user-facing specialist should take over, or whether the application should complete a predictable pipeline. For the latter, a workflow agent is easier to reason about than an unconstrained chain of model-selected transfers.

LangGraph: make state and control flow explicit

LangGraph treats the workflow as a graph. A node can call an agent, a tool, or ordinary application code. Conditional edges decide what runs next, and subgraphs encapsulate a specialist’s internal workflow.

Its most useful distinction for multi-agent coding systems is state scope. A subgraph can share the parent’s message state, or use a different schema and keep a private history. The docs describe per-invocation persistence as the usual choice for independent subagent tasks, with per-thread persistence when a specialist needs memory across turns.

That is more configuration than a basic handoff, but it answers questions that matter in production:

• Does the security reviewer remember the previous request?
• Which state is allowed to cross the boundary?
• Can a failed branch be inspected and resumed?
• Is a second invocation a fresh review or a continuation?

For a coding agent with approvals, durable state, or multiple branches, those are part of the workflow contract.

A decision rule for developers

Choose the smallest control model that makes failure modes visible:

• Use a handoff when one specialist should own the next user-facing turn.
• Use an agent-as-tool or bounded subagent when a manager needs a typed result and must keep control.
• Use a sequential workflow when order is fixed and each step depends on the previous output.
• Use parallel branches when reviews are independent and can be reconciled later.
• Use a loop only with an explicit exit condition, iteration cap, and verification step.
• Use a graph or durable workflow when approvals, restarts, auditability, or state scope are core requirements.

Ask: “If this specialist produces a dangerous suggestion, who is still responsible for deciding whether it becomes an action?” If the answer is unclear, the boundary is probably too implicit.

What to do now

1. Draw the ownership boundary for every specialist: takes over or returns a result.
2. Give each specialist a narrow output contract with findings, evidence, confidence, and recommended action.
3. Keep side-effecting tools behind an approval or policy boundary. Do not let a reviewer silently become an executor.
4. Add one failure test for each branch: timeout, malformed output, stale repository state, and rejected approval.
5. Record the state crossing each boundary. A short trace is more useful than a vague “multi-agent” label.

If you are measuring the system, track branch-selection accuracy, useful-result rate, review-to-action rate, tool failures, approval interventions, and cost per completed repository task. Framework choice alone will not tell you whether the workflow works.

Candid limitations

The comparison reflects official documentation available on July 21, 2026. APIs and recommended patterns can change quickly. The frameworks do not expose identical abstractions, so row-by-row equivalence is approximate. I did not run the same repository task across all three, measure latency, or compare model quality. Real outcomes depend on model, prompts, tools, state store, concurrency limits, and evaluation quality.

This is not an argument for using multiple agents by default. A single well-scoped coding agent with explicit tools and verification is often easier to test than a team of agents.

Sources

• OpenAI Agents SDK: orchestration and handoffs
• OpenAI Agents SDK: handoffs
• Google ADK: workflow agents
• Google Codelab: build multi-agent systems with ADK
• LangGraph: subgraphs and persistence

For the next layer of production detail, see Zira’s context compaction comparison, tool-error handling comparison, and coding-agent score guide.

Discussion: In your coding-agent workflows, do you prefer specialists to take over the conversation, or return bounded results to a manager, and what failure made you choose that design?