2026 Comparative Analysis: Agent Delegation and Handoff Infrastructure — Applied Technology Index

Executive Summary

Agent delegation assigns work to another agent while the caller retains overall responsibility. An agent handoff transfers active control or task ownership to another agent. A remote-agent task crosses a service or organizational boundary and requires a network contract for identity, task state, artifacts, errors, and asynchronous updates. These patterns are related, but they are not interchangeable.

The reviewed infrastructure divides into five operational profiles:

Local subagents isolate context and specialize prompts or tools inside one host and session.
Manager-as-tool delegation gives a coordinator bounded specialist results while the manager retains the user-facing turn.
In-process handoffs switch the active agent and usually forward some or all conversation history.
Durable workflow handoffs add explicit routing graphs, checkpoints, turn limits, resumability, and approval events.
A2A remote-agent tasks connect independent, opaque services through Agent Cards, Messages, Tasks, Artifacts, polling, streaming, and push notifications.

The central finding is that delegation architecture should follow the ownership boundary, not the number of agents. Local subagents are the lowest-friction option when one application controls prompts, tools, memory, and deployment. Manager-as-tool patterns are preferable when one agent must synthesize or validate specialist output. Handoffs fit conversational routing where a specialist should become active. Durable workflow handoffs fit recoverable business processes. A2A fits independently deployed agents, especially across frameworks, languages, teams, or organizations.

No reviewed system makes delegation equivalent to authorization. A parent that can select a specialist does not automatically have authority to grant that specialist every credential, tool, filesystem path, or production action available to the parent. Likewise, an A2A Agent Card advertises capabilities and authentication requirements; it is not proof that the remote agent is trustworthy, that a claimed skill works, or that a task result satisfies the caller’s policy.

Context transfer is the most underestimated design choice. OpenAI handoffs forward the previous conversation by default but expose input filters and optional nested-history summarization. Claude Code subagents use separate context windows and return results to the parent. Microsoft handoffs describe full conversational transfer, while agent-as-tool delegation lets the primary agent provide only relevant material. A2A deliberately keeps remote internals opaque and exchanges explicit Messages, Parts, Tasks, and Artifacts instead of sharing memory.

For production systems, use a delegation envelope containing the goal, bounded input, expected output schema, deadline, budget, authority, provenance, correlation identifiers, cancellation policy, and acceptance criteria. Record who delegated to whom, what context and credentials crossed the boundary, which policy authorized the transfer, what result returned, and who accepted it. Preserve user approvals across a handoff only when they are bound to the same action and canonical arguments; never reinterpret a general delegation as approval for a new side effect.

Key Findings

Delegation and handoff have different accountability models. In manager-as-tool delegation, the manager owns the final response. In a handoff, the receiving agent becomes active or owns the remaining task.
A subagent is not automatically a remote agent. Claude Code and common SDK subagents run inside a controlled host or session. A2A targets independent network services whose internals, memory, and tools remain opaque.
The narrowest sufficient boundary is usually best. A helper function is simpler than a subagent; a local subagent is simpler than an in-process handoff; an in-process workflow is simpler than a distributed protocol.
Context isolation and context continuity trade against each other. Separate windows reduce prompt growth and contamination, but delegated work can fail when key constraints are omitted. Full-history handoffs preserve continuity but can expose secrets, irrelevant tool output, or hostile content.
Routing is a policy decision even when an LLM proposes it. Tool descriptions, agent descriptions, and Agent Card skills are model-facing discovery surfaces, not authorization rules.
Durability requires stable identity and state. Microsoft documents stable agent IDs for checkpoint compatibility. A2A gives tasks immutable terminal states and uses contextId to group related work.
Remote interoperability requires explicit asynchronous semantics. A2A supports immediate Messages, stateful Tasks, polling, Server-Sent Events, and push notifications. Local handoff APIs commonly remain within one SDK run.
Guardrails do not necessarily follow control transfer. OpenAI documents that input guardrails apply to the first agent and output guardrails to the final agent in a handoff chain; operators need tool-level and workflow-level checks for intermediate actions.
Approval must bind to the action, not the agent name. Microsoft Agent Framework can pause a handoff workflow for approval-required tools, but a production record still needs the tool, arguments, actor, decision, and resulting side effect.
A2A standardizes communication, not result quality. Agent Cards, Tasks, Artifacts, auth declarations, and task states improve interoperability and traceability; they do not certify competence, safety, uptime, or truthful outputs.

Methodology

This analysis checked the live Applied Technology Index research index and the local public research collection before topic selection. Existing articles covered MCP interoperability, authorization, durable execution, human approval, context compaction, skills, and agent-to-user interfaces, but not the architectural distinction between delegation, control handoff, durable handoff workflows, and remote-agent task protocols.

Current public discussion about multi-agent teams, subagents, handoffs, and A2A was used only to identify the research question. Product and protocol claims are grounded in primary technical materials available on 12 August 2026: the A2A specification and guides; Google Agent Development Kit A2A documentation; OpenAI Agents SDK orchestration and handoff documentation; Claude Code subagent documentation; and Microsoft Agent Framework’s handoff orchestration documentation and approval/checkpoint sample.

The comparison applies ten criteria:

Ownership: which component remains accountable for the task and final response.
Deployment boundary: same process, same host, managed workflow, or independent network service.
Routing: code-selected, model-selected, graph-constrained, or dynamically discovered.
Context transfer: full history, filtered history, summary, bounded input, or protocol Messages and Parts.
Identity: local configuration name, stable workflow ID, or network-advertised Agent Card.
Authority: inherited permissions, restricted tools, workflow policy, or authenticated remote request.
State and durability: one run, resumable session, checkpointed workflow, or task lifecycle.
Result contract: free-form return, structured tool result, conversation response, or Artifact.
Asynchrony: synchronous return, parallel local execution, streamed workflow events, polling, SSE, or webhook push.
Auditability: routing decision, transferred context, approvals, tool activity, task status, artifacts, and acceptance evidence.

This is a documented-capability and architecture comparison, not a task-success benchmark. No identical multi-agent workload was run across every implementation. The analysis does not score model quality, routing accuracy, latency, token use, concurrency limits, pricing, availability, or security vulnerability rates.

Comparative Analysis Table

Pattern or implementation	Control and ownership	Context boundary	State and asynchronous model	Governance strength	Best fit	Main limitation
Claude Code local subagents	Parent delegates a bounded task; subagent works independently and returns a result	Separate context window; custom prompt, model, tools, permission mode, hooks, and skills	Same session; foreground or background execution; host-managed transcript and resumption behavior	Tool restrictions and independent permissions can reduce ambient authority	Research, code review, exploration, and specialist work that would pollute the main context	Host-specific local abstraction; not a cross-service task protocol or durable ownership transfer
OpenAI Agents SDK: agents as tools	Manager retains control, combines specialist outputs, and owns the final answer	Manager supplies nested-agent input and receives a tool-like result	One application/runtime; code can run independent calls in parallel	Central manager can apply shared synthesis and SDK controls	Bounded subtasks, parallel specialists, evaluator patterns, and one authoritative final response	Manager becomes a bottleneck and must validate potentially lossy specialist outputs
OpenAI Agents SDK: handoffs	Current agent invokes a handoff tool; receiving specialist becomes active for the remainder of the turn	Full prior conversation by default; `input_filter`, typed metadata, and optional nested history can alter transfer	Handoffs remain inside a single run; routing is model-facing through tool descriptions	Dynamic enablement, typed handoff metadata, callbacks, history filtering	Triage, language or domain routing, and specialist-owned conversation turns	SDK-local; intermediate guardrail coverage and full-history exposure require deliberate controls
Microsoft Agent Framework handoff workflow	Agents transfer full task ownership through configured mesh edges; agent-as-tool remains a separate manager pattern	Receiving agent gets conversation context; application can manage workflow messages	Streaming workflow events, autonomous turns, termination conditions, checkpoints, resume, and approval pauses	Explicit topology, stable IDs for rehydration, turn limits, approval-required tool events	Recoverable customer-service or expert workflows with explicit routing and sensitive actions	Local-tool requirement and framework-specific workflow state; mesh handoffs can cycle without limits
A2A remote-agent tasks	Client delegates to an independent opaque A2A server; server owns execution while client retains acceptance and business accountability	Explicit Messages and typed Parts; remote internal memory, plans, and tools are not shared	Immediate Message or immutable stateful Task; polling, SSE, push notifications, `contextId`, cancellation, and Artifacts	Agent Cards, auth schemes, authorization scoping, task IDs, terminal states, and structured artifacts	Cross-team, cross-language, cross-framework, or third-party agent services	Network, trust, discovery, identity, compatibility, webhook, and distributed-state complexity

Observed Profiles

Local subagents: context isolation inside one trust domain

Claude Code defines subagents as specialized assistants that run in their own context windows with custom system prompts, specific tool access, and independent permissions. The parent delegates matching work; the subagent operates independently and returns results. This makes the abstraction valuable when search results, logs, or implementation detail would otherwise consume the main context.

The parent and subagent still belong to one host-level system. Claude documents subagents as operating within a single session, distinct from separate background sessions, cross-session messaging, and agent teams. That distinction limits what “multi-agent” proves: separate model context does not imply a network identity, independent deployment, durable task API, or organizational boundary.

Local subagents provide a practical least-privilege surface. A read-only explorer can omit write tools; a reviewer can use a focused model and prompt; a specialist can have a dedicated permission mode. The parent should pass a bounded task with explicit constraints and request a structured result. A separate context is useful only if the return carries enough evidence—such as paths, references, tests, or uncertainty—for the parent to verify it.

The main failure modes are hidden context loss and authority leakage. The parent may omit a requirement that existed only in the main transcript. Conversely, inheriting broad credentials or tools can give a specialist more authority than its task requires. A subagent definition should therefore state allowed tools, write paths, network destinations, maximum work, and expected evidence, rather than relying only on a role name such as “researcher” or “reviewer.”

Manager-as-tool delegation: one accountable synthesizer

OpenAI’s Agents SDK distinguishes agents as tools from handoffs. With agents as tools, a manager remains in control, calls specialists for bounded subtasks, combines their outputs, and owns the final user-facing response. This is the clearest delegation model when multiple findings must be reconciled under one policy or answer contract.

The manager pattern also supports deterministic application orchestration. Code can classify a request, chain structured outputs, run evaluator loops, or execute independent specialists concurrently. Compared with model-selected routing, code-selected edges can make cost, latency, retry, and compliance behavior easier to predict.

Central control does not guarantee correctness. The manager can become a context and latency bottleneck, mis-summarize specialist evidence, accept incompatible outputs, or hide dissent among agents. Production implementations should keep specialist outputs structured and attributable, retain raw evidence where appropriate, and define acceptance tests rather than asking the manager merely to “combine the answers.”

A specialist called as a tool should receive no more authority than the subtask needs. The manager’s ability to invoke it is not permission for the specialist to call every downstream tool. If specialist actions can mutate external state, route those actions through tool-level policy and approval rather than trusting the manager’s natural-language delegation.

In-process handoffs: active-agent transfer inside one run

OpenAI represents handoffs as tools visible to the model. A handoff to a refund specialist can appear as transfer_to_refund_agent; descriptions help the model choose a route. The API supports a typed handoff input, a callback, a custom tool name and description, dynamic enablement, and an input filter.

A handoff changes who owns the active turn. This differs from a manager calling a specialist and then synthesizing the result. The receiving agent normally sees the previous conversation, which preserves user continuity but may transfer excessive material. OpenAI exposes input_filter to rewrite what the next agent sees and documents an optional nested-history mode that summarizes portions while preserving exact message occurrences in session state.

Typed handoff input is useful for small routing metadata such as reason, language, priority, or summary. It is not a replacement for application state, and it does not dynamically choose the destination. This separation is healthy: the destination edge, model-generated metadata, application dependencies, and forwarded history should be reviewable as different objects.

OpenAI also documents a guardrail boundary that operators should not miss: handoffs stay in a single run, input guardrails apply only to the first agent, and output guardrails apply only to the final agent. Tool guardrails are needed around intermediate custom tool calls. A routed specialist must therefore not be assumed to inherit every validation merely because it participates in the same run.

Durable workflow handoffs: routing plus recoverable execution

Microsoft Agent Framework describes handoff orchestration as a mesh in which agents transfer control directly according to configured edges. It explicitly distinguishes this from agent-as-tool delegation: the recipient of a handoff takes ownership and gets conversational context, whereas a primary agent using specialists as tools keeps responsibility and can send only relevant input.

The workflow layer adds controls absent from a simple handoff list. Documented features include streaming events, autonomous mode, per-agent turn limits, termination conditions, checkpointing, and tool approval. Stable agent IDs and names are required when rebuilding checkpointed handoff workflows because routing and rehydration depend on participant identity.

Durability changes the correctness problem. A resumed workflow must know which agent owned control, which messages were committed, which tool requests were pending, and which approvals were already decided. Replaying a handoff or an approved side effect can produce duplicate refunds, purchases, or notifications unless tool execution is idempotent and the checkpoint commits action state atomically.

Microsoft’s approval-required tool flow pauses execution and emits a request event containing the proposed tool call. This is stronger than asking an agent to narrate that approval is needed. Operators should still persist the canonical tool arguments, approver, decision, policy version, and execution receipt so a later handoff or resume cannot broaden the approved action.

Autonomous continuation requires explicit limits. Microsoft documents a default per-agent turn limit for autonomous mode and supports custom termination conditions. Any cyclic graph needs comparable controls: total steps, per-agent turns, elapsed time, token or monetary budget, repeated-state detection, cancellation, and an escalation path.

A2A: delegation across independent agent services

The Agent2Agent Protocol is designed for communication between independent, potentially opaque agent systems. The client can discover declared capabilities through an Agent Card, send Messages containing text, file references, raw bytes, or structured data, and receive either an immediate Message or a stateful Task. A Task can emit status updates and Artifacts and can be observed through polling, Server-Sent Events, or push notifications.

A2A’s boundary is materially stronger than an SDK handoff. The remote agent can use a different language, framework, runtime, model, memory, and tool inventory. The protocol intentionally does not require access to those internals. Google ADK’s guidance recommends A2A for independently deployed services, different teams or organizations, cross-language systems, and formal network contracts; it recommends local subagents for tightly coupled, performance-sensitive work that needs shared memory.

Task semantics improve traceability. A2A assigns tasks unique IDs, groups related interactions with a server-generated contextId, exposes interrupted states such as input-required or auth-required, and defines terminal states including completed, canceled, rejected, and failed. Terminal tasks are immutable. Refinements start new tasks in the same context and may reference prior task IDs. Parallel follow-ups can become distinct tasks, preserving individual units of work.

Artifacts are concrete outputs attached to tasks. They can carry text, files, or structured data and stream incrementally. The protocol leaves artifact-version acceptance to the client: the caller is best placed to decide which refinement is acceptable. This makes an important accountability split explicit. The remote agent owns execution of its task, but the client remains responsible for validating and accepting the result before using it in a consequential downstream action.

A2A also creates distributed-systems risks that local handoffs avoid. Agent Card discovery and caching can become stale. Credentials travel through standard transport mechanisms rather than conversational content. Authorization must scope task visibility. Push-notification endpoints require server-side request forgery defenses and webhook authentication. Retries need message IDs or application idempotency. Cancellation can race with completion. Extensions and skills require capability negotiation. None of these should be hidden behind a user interface that makes a remote agent look like a local function.

Delegation Envelope for Production Systems

A production delegation should be a structured record, even when a framework exposes it as a natural-language tool call. The minimum useful envelope is:

Delegator and delegate: stable workload, agent, tenant, and organization identities.
Goal and scope: one bounded unit of work, including explicit non-goals.
Input provenance: source references, classification, and integrity metadata.
Context policy: exact messages, summaries, files, secrets, and memory made available.
Expected result: schema, artifact type, evidence requirements, and acceptance tests.
Authority: allowed tools, operations, resources, destinations, and credential scopes.
Budgets: time, steps, tokens, money, network, storage, and concurrency.
Lifecycle: correlation ID, task ID, deadline, retries, cancellation, resume, and terminal states.
Approval policy: actions requiring human or policy-engine confirmation, bound to canonical arguments.
Audit evidence: routing decision, model and policy versions, tool calls, handoffs, outputs, errors, and acceptance decision.

The envelope should shrink or transform context intentionally at every boundary. Full transcript forwarding is not a neutral default: it may disclose personal data, credentials in logs, irrelevant instructions, or prompt-injection content. Summary-only transfer is also not neutral: it may omit negations, numerical constraints, approvals, or source provenance. Preserve critical constraints and immutable references verbatim, summarize narrative history separately, and label generated summaries as derived data.

Selection and Deployment Framework

Use a helper function instead of an agent when behavior is deterministic and no independent reasoning loop is needed.

Use a local subagent when one host controls the system and the primary requirement is context isolation, specialized prompts, a different model, or reduced tool access.

Use manager-as-tool delegation when one component must own the final answer, reconcile several specialists, run parallel analysis, or enforce a central output contract.

Use an in-process handoff when conversational ownership should switch to one specialist and the entire workflow can remain inside one runtime and run lifecycle.

Use a durable workflow handoff when work must survive process restarts, pause for approvals or user input, follow explicit routing edges, and resume without repeating side effects.

Use A2A when the delegate is independently deployed, maintained by another team or organization, implemented in another stack, or required to expose a formal long-running task contract. Do not adopt A2A merely to decompose one codebase; the network, identity, discovery, compatibility, and distributed-state costs are real.

Hybrid systems are common. A local manager may call local subagents for analysis, use a durable workflow for internal approvals, and delegate one bounded task to a remote A2A service. Keep identifiers across layers: parent run ID, workflow checkpoint ID, A2A contextId, task ID, artifact ID, tool call ID, approval ID, and final business transaction ID. Without this chain, a trace may show that each component succeeded while failing to prove which remote result caused the final side effect.

Security and Reliability Controls

Constrain routing

Maintain an allow-list of reachable agents and handoff edges. Treat descriptions and Agent Card skills as discovery metadata. Evaluate the requested task, authenticated actor, tenant, data classification, region, and risk before allowing the route. Disable destinations dynamically when policy, health, or version checks fail.

Minimize delegated authority

Issue short-lived, audience-bound credentials after the destination and task are known. Prefer capability-specific tokens to forwarding a parent API key. A delegate should not be able to reuse credentials for unrelated resources, another tenant, or a later task.

Validate returned artifacts

Parse against an expected schema, scan files, verify content type and size, retain source attribution, and apply business acceptance tests. Never execute code or follow instructions from a returned artifact merely because it came from a registered agent.

Make retries and side effects idempotent

Use stable message, task, tool-call, and business-operation identifiers. Persist “intent recorded,” “approval granted,” “execution started,” and “result committed” separately where risk warrants it. A timeout does not prove failure; query task or transaction status before repeating a mutation.

Preserve cancellation semantics

Define whether cancellation is best effort, acknowledged, or guaranteed before side effects. Record late results after cancellation and prevent them from silently re-entering the workflow. For remote tasks, cancellation of the protocol task may not reverse an already committed external transaction.

Test routing and transfer failures

Evaluation sets should include ambiguous destinations, unavailable agents, stale Agent Cards, unsupported modalities, malformed structured inputs, oversized context, secrets in history, hostile delegated content, cyclic handoffs, approval during a handoff, checkpoint resume, duplicate webhooks, stream disconnects, cancellation races, and valid-looking but unacceptable artifacts.

Limitations

This analysis relies on public specifications, official documentation, and open repositories available on 12 August 2026. The reviewed APIs and protocols are changing. OpenAI labels nested handoff history as opt-in beta in the reviewed documentation. Claude Code has multiple related execution surfaces—subagents, background agents, cross-session messaging, and agent teams—that should not be treated as identical. Microsoft Agent Framework documentation and samples may evolve with the framework. A2A implementations can support different bindings, extensions, and optional capabilities.

The comparison covers architectural layers rather than equivalent products. A Claude Code subagent is a host feature, OpenAI agents-as-tools and handoffs are SDK patterns, Microsoft handoff is a workflow orchestration, and A2A is a network protocol. Their placement in one table is intended to clarify selection boundaries, not produce a winner or maturity ranking.

No shared application was implemented across the reviewed systems. The analysis does not measure routing precision, completion rate, context fidelity, token cost, latency, throughput, checkpoint overhead, webhook delivery, interoperability conformance, vendor adoption, pricing, or security incidents. Documentation can establish intended behavior but not prove that every host, agent, or deployment implements it correctly.

A2A’s use of Agent Cards, authentication declarations, task state, and Artifacts does not establish agent trustworthiness or output truth. Likewise, local tool restrictions, handoff filters, checkpoints, and approval events reduce risk but do not prove isolation, authorization correctness, or recovery safety. Production deployments require threat modeling, identity architecture, evaluation, penetration testing, privacy review, and domain-specific controls.