Subagent or multi-agent? Choose the delegation topology

“Subagent or multi-agent?” sounds like a choice between two sizes of system. A subagent is already one way to organize multiple agents: a parent delegates a bounded task to a specialist and receives a result. The useful question is who controls the next step, who speaks to the user, and who owns a failure after work is delegated.

Begin with one agent as a measured baseline. Add a specialist only when a real task reveals a benefit that outweighs the extra context transfer, coordination, review, and recovery work. A specialist may be a good researcher while the parent remains responsible for the answer; in another task, a specialist should take over the conversation. Running independent work at the same time is a separate choice that can be combined with either arrangement. The earlier workflow-or-agent decision asks whether the model needs to control the next step at all; this page starts after that decision.

Four shapes, two separate decisions

First choose the control topology: one agent, a manager that calls specialists and combines their findings, or a handoff to a specialist that continues the conversation. Then decide whether independent branches may run concurrently. Parallelism says when work runs, not who has final authority.

Shape	Who chooses the next user-facing step?	Good fit	New obligation
One agent	The same agent throughout the task	The task fits one scope and a single trace remains manageable	Keep its tools, context, and stop rule bounded
Manager calls specialists	The manager; specialists return bounded findings	Separate expertise or data scopes must be reconciled into one answer	Specify each subtask, result format, merge rule, and failed-branch owner
Handoff to a specialist	The receiving specialist after a defined transfer	The user’s next conversation belongs in a different domain	Pass the right state, disclose the transfer, and define return or escalation
Parallel delegation	The parent or code coordinator still owns the merge	Subtasks can read independent evidence without a required order	Budget fan-out, partial results, timeouts, conflicting findings, and shared writes

An “agent as a tool” often implements the manager pattern: the specialist reasons over its assigned task and returns an output, while the manager keeps the conversation. A handoff changes the active agent. The implementation details vary across frameworks, so record the ownership in your design rather than relying on a framework label. If a subtask only needs a fixed extraction or lookup, it may need a regular tool or model step instead of another agent. The tool contract defines that operation; the permission ladder still applies separately to every consequential action.

Ask whether the work can really be separated

Write the candidate subtask in one sentence: “Given these inputs and this scope, return this evidence and uncertainty.” It is delegable when the specialist can finish without silently changing another branch’s assumptions. Name the source version, identifiers, units, and allowed tools. Decide whether the specialist may request clarification, and where that request goes.

Shared state is the usual hidden cost. A manager should not ask three agents to analyze “the building” if each silently chooses a different property or reporting period. Pass a stable building ID, a dated data snapshot, and an output schema. If one branch discovers that the source data is stale, the merge should flag the mismatch rather than present a polished average of incompatible findings.

Ask who is allowed to see the transferred context. In OpenAI’s Agents SDK, a specialist called with Agent.as_tool() starts a nested run that does not automatically inherit the parent’s conversation state. A handoff instead gives the receiving agent the earlier conversation history by default unless the application filters it. Send the minimum facts the receiving specialist needs, with a trace reference to the source; keep credentials and unrelated personal records out. The application must enforce access at the receiving tool and data layer. A model-written summary is not authorization.

Example one: an office energy retrofit review

A facilities team must rank retrofit options for three office buildings. The evidence includes time-of-use meter readings and tariffs, HVAC maintenance history, budgets, payback assumptions, and lease constraints. One agent can inspect the approved files sequentially and draft a recommendation. This is the baseline: the team can measure completeness, time, corrections, and cost before adding another agent.

If the baseline repeatedly misses the interaction between domains, a manager can call three bounded specialists. The electricity specialist reports consumption changes, tariffs, and the reading period; the HVAC specialist lists recurring faults and affected equipment; the finance specialist checks budget, payback assumptions, and lease restrictions. Each returns a building ID, source locator, finding, and uncertainty. The manager checks that all three used the same reporting period, reconciles conflicting evidence, and signs the final recommendation. The specialists do not approve work orders or speak to the client.

Those three reviews can run in parallel only if they are read-only and do not depend on one another’s results. The manager still waits for all required evidence or marks a missing branch. A lease restriction that invalidates a proposed equipment change must override a tempting savings estimate. If maintenance findings require a second meter query, that follow-up is dependent work and should run after the first merge, not be guessed by a parallel branch.

Compare both designs on the same past cases, including a missing meter month, a mislabeled building, and conflicting lease versions. Count a recommendation as complete only when every material claim has a compatible source and a named decision owner. If specialists add cost without improving that outcome, retain the single-agent route.

Example two: a library account handoff

A library assistant answers opening hours and lending questions. A patron then reports that a returned book still appears overdue. The assistant can classify the issue and hand the conversation to an account specialist. After the transfer, that specialist asks about the return place, date, and receipt and explains the resolution path; the original assistant should not keep narrating an answer it can no longer verify.

The transfer packet contains the reported problem, the relevant loan reference if the patron supplied one, consent and authentication state from the application, and what has already been attempted. It excludes unrelated chat history. The account specialist must verify identity through the library’s approved service before reading or changing account records. It checks the return scan and exception ticket before explaining what can be confirmed; correcting an overdue charge still requires its own authorization. If verification fails or the record is disputed, a named human team owns the case. A handoff is useful here because the specialist must continue a focused dialogue, not merely send a paragraph back to the general assistant.

Counterexample: shared inventory is a parallel-write trap

Suppose a sales agent and a service agent both read that one replacement part is available. Each is asked to reserve it for a different customer. Running them in parallel against that shared inventory can produce two confident promises from one stale snapshot. Better summaries and more specialist agents do not solve the race.

Use one transactional inventory service to decide the reservation, with a version check and a stable operation ID so retries do not create another reservation. Agents can independently gather customer context, but the shared write needs one authoritative executor and a clear result: reserved, rejected, or outcome unknown pending lookup. If the service cannot establish the outcome, a person reconciles it before either agent promises availability. Treat this as a boundary on concurrency, not a reason to copy more context between agents.

Count the full bill and the critical path

Record model calls for every branch, repeated input context, tool charges, retries, merge calls, and human review. A cheap specialist response can still raise total cost when its setup and source material are copied to several runs. Record both total spend and wall-clock time. Sequential work tends to add branch durations; parallel work is limited by its slowest required branch plus fan-out, queueing, and merge time. A timeout can erase the expected speed gain.

Set a budget before testing: maximum specialists per case, permitted tools, tokens or currency per branch, a deadline, and a fallback when one branch does not return. Define whether partial evidence can support a limited answer or whether the case must stop. A manager that silently omits a failed specialist has turned a coordination failure into a content error. Use the runtime loop guard to decide whether each active run continues; this topology record assigns responsibility when work crosses agents.

Fill the delegation decision record

Complete one record for each task type before implementation. The fields are also useful when reviewing a real trace:

Field	Write down
Task and baseline	The user outcome, acceptance test, and measured single-agent result
Candidate topology	One agent, manager with specialists, handoff, or a combination with parallel reads
Controller and final answer owner	Who chooses the next step, talks to the user, and approves the final result
Subtask boundaries	Each specialist’s inputs, permitted tools, output schema, and forbidden effects
State contract	Record IDs, source versions, data shared at transfer, and access checks
Dependency and concurrency	Which branches are independent, which must wait, and who merges conflicts
Cost and deadline	Full model and tool budget, wall-clock target, and retry limit
Failure owner	Who handles timeout, conflicting evidence, partial results, and an unknown write outcome
Comparison and revisit date	Cases tested, quality and cost difference from baseline, and date to recheck

Use the same evaluation cases for the baseline and candidate. Include at least one stale source, one cross-scope data request, one branch timeout, and one disagreement that cannot be averaged away. Review final-answer correctness, cited evidence, elapsed time, total cost, human corrections, and whether the trace identifies the responsible owner. Keep the simplest topology that meets the acceptance test. Revisit the choice when volume, tools, or data boundaries change.

Common questions

Is a subagent different from a multi-agent system?

A subagent is a specialist delegated work by another agent, so it is a multi-agent arrangement. “Multi-agent” also covers handoffs and other patterns. Specify the control and state transfer instead of using the number of agents as the design decision.

Does parallel delegation always make a task faster?

No. It helps when the branches are independent, the slowest branch is shorter than the sequential total, and coordination overhead is small enough. It may cost more even when wall-clock time falls. Shared writes and dependent investigations need a different schedule.

Should every specialist receive the full conversation?

No. Give it the task, allowed scope, verified state, and relevant source references. Filter sensitive or irrelevant history and enforce permissions again at the tools. A concise handoff can also make a missing fact visible instead of burying it in a long transcript.

Boundary

This record chooses a collaboration shape; it does not grant permission to disclose data or make consequential changes. Payments, account changes, production writes, and regulated decisions need enforced authority, approval, and a recovery path at the actual system boundary. If no one can name who resolves a partial result or conflicting write, keep the action with a single accountable executor until that gap is closed.