A delegation architecture where a primary agent assigns bounded research, data, and writing tasks to specialist sub-agents before validating and combining their results.
|

Agent Handoffs, Delegation, and Sub-Agents

ByAIRundown Daily Reading Time: 9 minutes
A delegation architecture where a primary agent assigns bounded research, data, and writing tasks to specialist sub-agents before validating and combining their results.
Delegation keeps one primary owner while specialists return bounded results for validation and aggregation.

Multi-agent systems become useful when work can be divided into clear responsibilities. They become fragile when ownership, context, and state move between agents without a contract.

[Delegation](/glossary/delegation/) assigns bounded work while one agent retains responsibility. A [handoff](/glossary/agent-handoff/) transfers active ownership to another agent. A [sub-agent](/glossary/sub-agent/) is a specialist invoked within a larger system.

These concepts are related, but not interchangeable. This article explains how to use them without creating lost context, repeated work, or endless delegation.

TL;DR

  • Delegation assigns a task while the delegating agent usually keeps the parent goal.
  • A handoff changes which agent owns the next decisions or conversation.
  • A sub-agent is a bounded specialist, not merely a function or API.
  • Every transfer needs task scope, relevant context, state, permissions, and a return or completion contract.
  • Use multiple agents only when specialization or context isolation outweighs coordination cost.

Delegation architecture

Delegation keeps one primary owner while specialists return bounded results for validation and aggregation.

The primary agent in this pattern owns:

  • the user’s overall goal;
  • task decomposition;
  • specialist selection;
  • context allocation;
  • result validation;
  • conflict resolution;
  • the final answer or action.

The sub-agents own their assigned tasks, not the complete user outcome. That boundary prevents a research specialist from unexpectedly taking over publication or a writing specialist from changing source data.

What is delegation?

Delegation is the assignment of a task to another capable agent while preserving an accountability relationship.

A good delegation specifies:

  • the task to complete;
  • why it matters to the parent goal;
  • allowed tools and data;
  • relevant context;
  • constraints and deadline;
  • expected result format;
  • what to do when blocked;
  • whether the result returns to the delegator.

“Research this” is a weak delegation. “Find the current refund rule in the approved policy sources, return two supporting passages with source IDs, and do not make a customer-facing decision” is testable.

Delegation can be initiated by a supervisor, orchestrator, or peer agent. The label of the sender matters less than the ownership contract.

What is a sub-agent?

A sub-agent is a specialist agent used as part of a broader system. It has its own instructions and may have its own model, tools, context, memory, and execution loop.

Common specialist roles include:

  • retrieval agent;
  • data-analysis agent;
  • code agent;
  • policy agent;
  • reviewer;
  • writer.

A sub-agent is useful when it creates a meaningful boundary:

  • specialized instructions improve performance;
  • access should be limited to specific tools;
  • context should be isolated;
  • work can run independently;
  • a smaller or cheaper model is sufficient;
  • outputs can be evaluated with a distinct contract.

Creating separate “personas” with the same prompt, tools, and context does not automatically create useful specialization.

Specialist agent vs independent agent

A specialist agent has a narrow capability. An independent agent has its own external goal, lifecycle, and ownership.

A tax-policy specialist called during an expense workflow is a sub-agent. A separately operated procurement agent serving its own users may be an independent agent, even if another system can contact it.

The distinction affects:

  • identity and authorization;
  • service boundaries;
  • state ownership;
  • failure isolation;
  • service-level expectations;
  • whether the agent may reject or renegotiate a task.

Remote communication protocols can connect independent agents, but a multi-agent design does not require a network protocol. Several sub-agents may run in one application process.

Handoff flow

An agent handoff flow where Agent A transfers a packet containing task, relevant context, state, permissions, and a return contract to Agent B, which works and returns a result or updated state.
A handoff transfers active ownership. The transfer packet should be explicit, minimal, and sufficient for the receiving agent to continue safely.

A handoff transfers active ownership. The transfer packet should be explicit, minimal, and sufficient for the receiving agent to continue safely.

A reliable [agent handoff](/glossary/agent-handoff/) follows five stages:

  1. Prepare: Agent A identifies why Agent B is the correct owner.
  2. Package: the system constructs the task, context, state, permissions, and expected outcome.
  3. Accept: Agent B validates that it can perform the task.
  4. Execute: Agent B continues the work under its own instructions and tools.
  5. Resolve: Agent B returns a result, updates shared state, hands off again, or completes the user-facing task.

Different frameworks define handoff semantics differently. In the OpenAI Agents SDK, handoffs are exposed to the model as tools and transfer the active conversation to another agent. Other systems may represent a handoff as a message, graph edge, event, or remote task.

Do not assume the implementation mechanism defines the architectural ownership. Document it.

Handoff vs delegation

Delegation usually preserves the delegator as the owner of the parent task. The delegated agent returns a result.

A handoff transfers active control. The receiving agent becomes responsible for what happens next, at least for that portion of the interaction.

Example:

  • Delegation: A manager agent asks a data agent to calculate retention and waits for the result before writing a report.
  • Handoff: A triage agent transfers the customer conversation to a billing agent, which now decides the next questions and actions.

A system can delegate through a handoff, but the concepts answer different questions:

  • Delegation: who is assigned the work?
  • Handoff: who owns the next decisions?

Delegation vs tool calling

[Tool calling](/glossary/tool-calling/) invokes a capability with defined arguments and receives a result. The tool does not normally become the owner of the user’s goal.

Delegating to a sub-agent may be implemented as a tool call, sometimes called “agent as tool.” Architecturally, the sub-agent differs from a normal tool because it can reason, choose its own tools, take multiple steps, and return a synthesized result.

Compare:

  • Tool: getexchangerate("USD", "JPY")
  • Sub-agent task: “Assess currency risk for the proposed Japan launch using approved sources and return assumptions, scenarios, and evidence.”

Both need schemas and permissions. The sub-agent also needs a bounded goal and stopping behavior.

Sub-agent vs tool

A tool performs a capability. A sub-agent pursues a subgoal.

Prefer a tool when the operation is known and deterministic. Prefer a sub-agent when the work requires interpretation, iterative evidence gathering, or adaptive choice among tools.

Do not wrap a deterministic API in an LLM agent merely to make the architecture look multi-agent. That adds latency, cost, and failure modes without useful judgment.

Agent handoff vs API call

An API call is a communication mechanism. A handoff is an ownership transition.

An API call can:

  • fetch data;
  • execute a transaction;
  • send a task to another service;
  • initiate a handoff.

Calling an endpoint does not prove that another agent accepted responsibility. A robust handoff needs acknowledgment, task identity, state, status, and failure behavior.

This distinction becomes critical across organizations or remote agents. Network success means the message arrived, not that the task is understood or completed.

Task ownership

At every point, one component should own the active task. Ownership includes:

  • knowing the current objective;
  • deciding the next permitted action;
  • tracking completion or blockage;
  • updating authoritative state;
  • producing or routing the final result.

Ownership can be hierarchical:

User Goal → Primary Agent → Delegated Subtask → Specialist

Or sequential:

Triage Agent → Billing Agent → Human Escalation

Avoid shared implicit ownership. Two agents acting on the same open task can duplicate messages or transactions. No owner means the task stalls.

Shared context and state transfer

Agents need enough information to continue, but not the entire history.

A transfer packet should include:

  • task and success criteria;
  • verified facts and source references;
  • unresolved questions;
  • relevant decisions;
  • structured state fields;
  • allowed actions;
  • deadline and budget;
  • expected output;
  • parent task or correlation ID.

Context is what the receiving model sees now. State is the operational record that persists across steps. Transfer only the fields needed by the receiver, and maintain one authoritative source for shared state.

If each agent keeps a private copy and updates it independently, the system will eventually disagree about progress, approvals, or results.

Result return

A sub-agent result should be an artifact with a contract, not a transcript dump.

Useful fields include:

  • status: completed, blocked, or failed;
  • answer or artifact;
  • evidence and provenance;
  • assumptions;
  • actions performed;
  • state updates proposed;
  • unresolved risks;
  • recommended next step.

The parent validates the result before merging it into state. A specialist’s output is an observation, not automatically authoritative truth.

Sequential collaboration

Sequential collaboration passes work from one role to the next:

Research → Analysis → Writing → Review

It is useful when later work depends on earlier results. The risk is context degradation: each transfer may summarize away an important constraint.

Preserve structured artifacts and references instead of repeatedly paraphrasing the full result.

Parallel collaboration

Parallel collaboration delegates independent subtasks at the same time:

  • market research;
  • competitor research;
  • regulatory research.

It can reduce latency and increase coverage. It also creates:

  • duplicate evidence;
  • inconsistent assumptions;
  • conflicting conclusions;
  • larger aggregation context;
  • partial-failure decisions.

Define how results are deduplicated, ranked, and reconciled. Parallel agents should not modify the same external record without coordination.

Supervisor delegation and peer handoffs

In centralized coordination, a [supervisor](/glossary/supervisor-agent/) assigns tasks, reviews results, and remains responsible for team progress.

In peer-to-peer collaboration, one agent hands work to another based on specialization. This can be modular, but it needs:

  • a capability registry;
  • transfer limits;
  • cycle detection;
  • shared task IDs;
  • clear terminal ownership.

OpenAI’s practical guide describes a comparable split between manager-style “agents as tools” and decentralized handoffs. Neither is always better. Central management is easier to control; peer handoffs can keep domain context local.

Practical example: due-diligence report

A primary agent owns a due-diligence report. It delegates company research, financial analysis, and policy screening to three specialists in parallel.

Each sub-agent receives a narrow task and approved sources. The research agent returns cited facts. The data agent returns calculations and assumptions. The policy agent returns applicable rules and unresolved flags.

The primary agent validates the artifacts, resolves conflicting dates, and notices that the policy result requires legal judgment. Instead of pretending to decide, it hands that portion to a human-review queue with the evidence and unresolved question.

After approval, the primary agent writes the final report. It remains accountable for the complete output, while specialists own only their bounded work.

Common failure modes

Lost context

The receiving agent lacks a constraint, decision, or source. Use structured transfer packets and stable references.

Ambiguous ownership

Both agents act, or neither continues. Record the active owner and require transfer acceptance.

Repeated work

Specialists search the same sources or redo completed calculations. Include completed artifacts and assign non-overlapping scopes.

Delegation loops

Agent A sends to B, B sends to C, and C sends back to A. Track delegation depth and visited owners; enforce a stopping condition.

Oversized context transfer

Passing the complete conversation to every specialist increases cost and leaks irrelevant data. Send the minimum sufficient context.

Inconsistent state

Agents update separate copies. Use an authoritative state store with validated updates and version checks.

Unchecked result aggregation

The parent concatenates outputs without resolving duplicates, conflicts, or unsupported claims. Add validation and evidence-aware merging.

Design checklist

Before adding a sub-agent or handoff, answer:

  • What capability boundary justifies another agent?
  • Who owns the parent goal?
  • What exactly is transferred?
  • What permissions does the receiver have?
  • How does the receiver accept or reject the task?
  • What result contract returns?
  • Where is authoritative state stored?
  • How are conflicts and partial failures handled?
  • What prevents cycles and unbounded delegation?
  • Who decides final completion?

If those answers are unclear, the system is not ready for another agent.

My take

Multi-agent design is an ownership problem before it is a prompting problem. Specialization helps only when tasks, state, permissions, and result contracts are sharper than they were in the single-agent version.

Use delegation to isolate bounded expertise. Use handoffs when active ownership genuinely needs to change. Keep a single accountable owner for the complete user outcome.

Sources

Continue learning

Start with [Single-Agent vs Multi-Agent Systems](/single-agent-vs-multi-agent-systems/), then use the [sub-agent glossary entry](/glossary/sub-agent/) for quick terminology.

Similar Posts