One AI agent or several? When subagents are worth using
Whether subagents are worth using depends on how much shared context your task needs and how clearly you can bound each delegated assignment. Independent tool calls can run in parallel within a single agent loop. Parallel execution alone is therefore no reason to introduce multiple agents.
For technical product leads and IT teams, the useful question is: which information must remain available across decisions, and which assignment can be completed reliably from a bounded input package?
This article compares the approaches, works through a fictional procurement example and provides a delegation card and a small evaluation plan. It does not establish a universally better architecture.
What a shared loop and subagents mean
In a single agent loop, one agent repeatedly selects its next action, uses tools and processes their results in a shared working context. That does not mean one model call or one enormous prompt. Relevant instructions and data can be loaded when needed.
A subagent handles a delegated assignment in its own context, with its own instructions and assigned tools. A coordinating agent receives the result and combines it with other information. What crosses the boundary, and what the subagent may decide, must be explicit.
Whether the process needs an agent at all is a separate decision covered in AI agent vs workflow vs automation. Here, the question is how to divide work within an agent-based task.
What Anthropic now recommends, and how far it applies
In its article dated 22 October 2026, Anthropic describes enterprise deployments where certain routing, planning and domain agents could be folded into a single loop with instructions loaded on demand. It still identifies reasons to use subagents, including measurable context problems and independent work requiring fresh context windows. These are vendor experiences with Claude, not a universal architecture comparison. Source: Building agents.
This is consistent with Anthropic's 13 June 2025 account of its multi-agent research system. That report describes benefits for broad research across independent directions and limitations where tasks depend heavily on shared context. The observations concern that research system and its internal evaluations. Source: Multi-agent research system.
Research also cautions against a blanket ranking. The preprint Same Context, Different Agents, submitted on 14 October 2026, studies context techniques with seven models on 1,514 tasks from five data-agent benchmarks. The effect of orchestration depends on the baseline agents' behaviour. The study does not cover every B2B process or the procurement example below. Source: Sourati et al., arXiv:2610.20959.
The practical implication: diagnose your application's actual problem. An unwieldy prompt, missing domain instructions and oversized source documents are different issues. Adding another agent does not automatically fix them.
Decision table: shared context or bounded delegation?
This table is an architecture aid, not a measured benchmark.
| Observation in your task | Reasons to retain shared context | Reasons to consider bounded delegation |
|---|---|---|
| New requirements affect many decisions | One current requirement must apply everywhere | Changes are versioned and affected assignments can be restarted selectively |
| Subtasks depend heavily on each other | Intermediate findings continually change the next steps | An assignment still has a stable, verifiable completion point |
| Many domain instructions are rarely needed | Load the relevant instructions into the same loop on demand | The specialist work genuinely needs its own extended investigation |
| Large sources crowd out relevant instructions | First try targeted retrieval and context selection | A bounded investigation can return compact findings with evidence |
| Several data fetches are independent | Call tools in parallel and assess results together | Independent multi-step investigations also need separate contexts |
| Permissions differ | Restrict tools and execution technically | A separate service actually enforces the required boundary |
Before splitting the work, ask whether the coordinator can validate the result without repeating the entire investigation. If it needs every discarded assumption and intermediate step, the proposed boundary may be wrong.
Fictional B2B example: three suppliers and a new requirement
This example is entirely fictional. It is neither a customer case nor a report of completed tests. A procurement assistant compares documents from three software suppliers. Initially, the criteria cover functionality, price and deployment options.
While the comparison is in progress, procurement adds: The required functionality must work without an external cloud connection. This becomes revision R2; the original requirements are R1. An optional cloud feature does not automatically disqualify a supplier. The issue is whether the required operation depends on it.
How an incomplete handoff distorts the comparison
One subagent has already assessed supplier A against R1 and returns “suitable”. Another is reviewing supplier B, but its assignment only says “check deployment options”. It finds “on-premise available” and misses a mandatory cloud-based licence check. A third returns an older product description for supplier C; the current addendum specifies another cloud dependency.
Combining these results without their requirement revisions and source versions mixes different criteria and document states. A polished final answer could recommend an unsuitable supplier. The immediate failure is not the agent count: it is the absence of a consistent requirement revision and reliable acceptance checks for delegated findings.
What must happen when R2 arrives
- The coordinating application records R2 as current and identifies affected assignments.
- R1 findings remain traceable but cannot be accepted as final. Affected assignments are updated or restarted.
- Each result identifies the document version, evidence location and requirement revision it checked. “Not mentioned” remains “not established”.
- Before recommending a supplier, the same R2 requirement is checked across all three. Contradictions become open questions rather than a silent preference for the more convenient source.
A shared loop avoids some handoffs here. It can still reuse an old summary or overlook a requirement. It also needs explicit requirement state, evidence and a final validation step. Shared context does not replace validation.
A reusable delegation card
The card records what must survive a context boundary. Complete it before delegation and fill in the result fields when the assignment returns.
| Field | What to record | Example from the fictional procurement task |
|---|---|---|
| Assignment | Goal, boundary and completion condition | Determine whether supplier B supports the required operation without an external cloud connection |
| Inputs and revision | Approved sources, document versions and current requirements | Versioned supplier B documents; R2 criteria; explicit list of required functions |
| Result and sources | Structured finding, evidence locations and missing proof | Meets / fails / unresolved; document, page or section, with a short supporting passage |
| Decision authority | Permitted decisions and excluded actions | Assess properties; do not select a supplier, contact anyone or place an order |
| Conflicts | Handling of missing or contradictory information | Return both evidence locations and escalate the unresolved issue to the coordinator |
| Changes during execution | Revision checks, stale-result handling and update acknowledgement | On R3, pause the affected check and update the assignment; do not accept an R2 result as current |
| Final validation | Owner plus technical and substantive acceptance checks | Coordinator checks revision, sources, completeness and the cloud requirement before recommending |
In the implementation, add a unique assignment ID, a deadline and a state such as “pending”, “valid”, “superseded” or “failed”. A late result must not overwrite a newer decision. The application must enforce these rules; a polite instruction in a prompt is insufficient.
Three variants for the same task
| Variant | Design | What it tests |
|---|---|---|
| A: single agent loop | One agent keeps the requirements and comparison together and calls approved tools | Can the shared working context handle the entire task? |
| B: single loop with domain instructions | The same loop loads guidance, such as a cloud-dependency checklist, when needed | Does more targeted knowledge help without additional handoffs? |
| C: bounded delegation | One agent delegates a clear assignment, such as an evidence-based check of supplier B, and validates the return | Does the independent investigation justify the handoff and validation effort? |
For a fair comparison, give every variant the same sources, requirements and permitted actions. Record the model version, settings and total budget. C does not receive an undisclosed larger budget simply because it uses multiple contexts. A and B may also call independent tools in parallel.
Six test cases and 36 proposed runs
Start with these six cases and define the expected outcomes before running anything.
| Test case | Expected behaviour |
|---|---|
| Complete data | Compare all required properties using current evidence |
| Missing property | Identify the missing evidence; do not infer a property from unrelated statements |
| Contradictory documents | Report both evidence locations; do not assert suitability without a defined conflict resolution |
| Changed requirement | Apply R2 and recheck affected R1 findings |
| Late result | Detect a superseded return and preserve the current decision |
| Failed assignment | Make the gap visible and use the predefined retry or escalation path |
For the last two cases, simulate a delayed or failed tool step in A and B, and the corresponding delegated work in C. This keeps the business problem comparable. All variants must clearly identify a recommendation based on an incomplete assessment.
Three variants × six cases × two repetitions = 36 proposed runs. This is an evaluation plan. These runs were not conducted for this article. Two repetitions per case cannot support a statistically robust ranking; their initial purpose is to expose concrete failure modes.
First assess evidence accuracy, preservation of requirements, conflict handling and compliance with permitted actions. Then record elapsed time, model and tool costs, and human rework. A faster run does not compensate for violating a mandatory requirement.
The AI agent evaluation guide covers acceptance checks for outcomes and tool calls. For the economic comparison, use cost per successful task, including failed attempts and rework.
A separate agent context is not a permission boundary
A separate prompt does not prevent unauthorised data access. A technical boundary depends on enforced identities, tool permissions, data filters and execution environments.
If a subagent currently has read-only access to a specific set of supplier documents, folding it into the main loop must not expand access to other documents or enable writes. Check effective permissions at the application level before and after the change. The same applies to tenant isolation, approvals and auditability.
“Do not place orders” belongs in the assignment. Withholding order-placement permissions belongs in the implementation.
Next step: test one boundary, then decide
Choose one concrete assignment from your existing process. Fill in the delegation card and mark information that could change while work is in progress. Then compare A, B and C using the six cases.
Reject a variant while it loses mandatory requirements, invents evidence or exceeds its permissions. If several variants pass the substantive checks, compare maintainability, cost and elapsed time. Only generalise after testing further representative cases.
If you need to make this decision for a pilot or an existing application, I can support the architecture decision and implementation plan as an AI Solution Architect & Hands-on AI Engineer. The starting point is your actual process, its context dependencies and verifiable acceptance criteria.