A multi-agent system can look like an organizational chart: a coordinator assigns research, coding, verification, and reporting to specialist agents. But that analogy hides the engineering problem. Each agent has its own execution context, tools, budget, authority, and failure modes.<\/p>\n
Passing a vague instruction such as \u201cfinish the analysis\u201d across that boundary invites inconsistent assumptions, repeated work, and answers that cannot be traced to their sources. In a Claude-based application, reliable delegation begins with explicit task contracts and durable workflow state, not with the number of agents on a diagram.<\/p>\n
Subagents are useful when specialization reduces context noise, narrows tool permissions or enables independent work. They add overhead when every task requires the same documents to be reread or parallel branches race to update the same resource. Before delegating, define the evidence each subagent needs, the operations it may perform and the form in which it must return results.<\/p>\n
A coordinator should hand a specialist an answerable question, a constrained input set, an expected output schema, and an explicit definition of success. \u201cCheck whether these five policies contradict each other and cite the relevant sections\u201d is a bounded research task. \u201cUnderstand the customer\u201d is not. The latter gives a subagent no reliable stopping point or test for completeness. A narrow contract also makes it easier to evaluate whether delegation was better than keeping the work in one agent.<\/p>\n
For example, a technical support agent might delegate log analysis and configuration review separately. The log specialist receives time boundaries, identifiers, allowed log sources, and a request to identify evidence of failed authentication. The configuration specialist receives approved change records and current access settings. Neither subagent is asked to resolve the incident or change access policy. The coordinator combines evidence and decides whether the next step is diagnosis, clarification, or human escalation.<\/p>\n
Include a failure contract. What should the specialist return if the relevant log period is missing, if a document is inaccessible, or if its evidence contradicts another source? \u201cNo conclusion; missing log partition\u201d is a successful report of insufficient evidence, not a failure to comply. Agents should be able to say that evidence is incomplete without inventing a conclusion to satisfy the requested format.<\/p>\n
A spawned subagent should not be assumed to inherit every message, tool result, system instruction, file handle, or permission from its parent. Model and runtime APIs expose different context-passing mechanisms, so architecture must identify exactly what is delivered to a child task. Relying on implicit shared memory is fragile even in a system where multiple agents happen to run in one process. Define the inputs explicitly and verify what the subagent can see before expecting it to make decisions.<\/p>\n
A practical handoff envelope includes a task ID, purpose, authoritative source identifiers, relevant excerpts or retrieval instructions, freshness requirements, allowed tools, output schema, and a deadline or budget. Avoid sending an entire parent transcript \u201cjust in case.\u201d That makes the child vulnerable to irrelevant instructions, bloated context, and older evidence that no longer describes the current system. If a child needs more source material, it should request access to the relevant evidence through approved tools rather than hallucinate missing details.<\/p>\n
The context management<\/a> problem gets harder when child agents produce summaries. A summary can be useful for coordination but must not become the sole authoritative record. Keep links to original documents, timestamps, and observation IDs so the coordinator can verify high-stakes claims. If two summaries disagree, compare their sources before averaging their conclusions.<\/p>\n Sequential delegation is appropriate when each stage depends on the verified output of the previous one: collect evidence, classify the issue, propose a change, and independently check policy. It is easy to audit but can be slower because later tasks wait. Parallel delegation is suitable for independent source inspections or different hypotheses, as long as the coordinator can distinguish contradictory conclusions and reconcile them. Running dependent tasks in parallel is likely to produce stale reads and avoidable retries.<\/p>\n A hub-and-spoke arrangement can keep the coordinator responsible for user intent and synthesis while specialists perform bounded work. That separation is useful when tools have different permissions: a researcher may read reference documents, a calculator may perform numeric validation, and an operator may prepare a proposed action without being able to commit it. The coordinator should not grant every specialist every tool merely because doing so simplifies initial development.<\/p>\n More agents also increase observability cost, latency and opportunities for disagreement. Before adding a specialist, measure what failed with the simpler design. Did one context window become overloaded? Did one tool set create ambiguous choices? Did expertise differ meaningfully? Was independent verification required? If the answer is no, a deterministic workflow or one agent with well-scoped tools may be clearer and cheaper.<\/p>\n A coordinator should not treat two agent summaries as two independent votes if both agents relied on the same copied source. Independence requires different evidence or different validation methods. Merge results as claims backed by source IDs and observed timestamps, then identify whether disagreements reflect different data, different interpretations, or errors. A majority of correlated model opinions is not a reliable substitute for a primary record.<\/p>\n Suppose one subagent finds that a service outage began at 14:07 while another reports 14:11. The coordinator should inspect the basis of both times: one might refer to the first network alert, the other to the first customer ticket. The correct incident narrative may legitimately contain both. A useful synthesis preserves these distinctions instead of writing that the outage \u201cbegan around 14:09\u201d simply because that is the midpoint.<\/p>\n For tasks with schemas, validate the output structure separately from its meaning. A JSON object with valid fields can still cite the wrong case number. Require the claimed evidence to be retrievable and verify critical arithmetic or policy decisions deterministically. The structured-output validation<\/a> boundary is particularly important when subagent output is consumed by another automated component without human interpretation.<\/p>\nChoose sequential, parallel, and hub-and-spoke patterns deliberately<\/h2>\n
Merge outputs with provenance and disagreement handling<\/h2>\n
Persist sessions without persisting unsafe assumptions<\/h2>\n