Multi-Agent Systems: Dividing Work Without Losing the Whole Task

What another agent changes

An agent uses observations to choose its next action toward an assigned goal. In a prescribed workflow, application rules determine the stages and transitions, including branches, repetition, and parallel operations. The distinction is not whether execution responds to new information, but which choices the application leaves to the agent. Agent Engineering develops this distinction. A multi-agent system distributes those choices among several participants, whose decisions must still produce a compatible result. [1]

Coordination manages dependencies among activities: one participant needs another's result, two participants need the same resource, or several contributions must satisfy one requirement. It is the mechanism that keeps locally reasonable decisions compatible with the overall task. [2]

Agents need not use different models or processes. Conversely, separate processes may simply execute predetermined work. A role's instructions, model selection, tool access, and workspace are distinct configuration choices; a specialist name does not create any of them automatically. [3]

Separate participants can investigate different directions or divide information too extensive for one working context—the input available to a model for its current decision. Anthropic's research-system account describes these benefits alongside greater model usage and difficulty with tightly interdependent work. Separation helps only if each participant returns a contribution the others can use; otherwise, it creates more investigation without a better combined result. [4]

Coordination foundations

The central coordination problems predate language models. Systems needed ways to combine partial knowledge, allocate work, and keep participants informed when circumstances changed. The following developments addressed different parts of that problem; they are complementary ideas, not stages in an inevitable replacement sequence.

Language models expanded what a participant could interpret and produce through a message interface. They did not make assignment, communication, or shared commitments unnecessary. Those responsibilities still determine whether a collection of capable participants behaves as a coherent system. [8][7]

Decompose for recombination

Decomposition divides an overall requirement into contributions that can be combined to satisfy it. Start by asking what each assignment needs from the others. The more one assignment depends on or constrains another, the greater their coupling, and the more coordination they require. Assignment size, or granularity, creates a second tradeoff: smaller assignments clarify actions but add decisions and handoffs. The planning chapter explains subgoals; assigning them to separate agents also requires deciding how their results will fit together. [9][2]

There are different reasons to separate work. Investigators can pursue different evidence, specialists can receive tools suited to their responsibilities, and workers can process large inputs without passing every detail to the coordinator. Medic, a system for diagnosing failing Apache Spark jobs, illustrates the last case: a subagent analyzed charts of job metrics and returned summarized findings to the parent agent. This kept the detailed analysis out of the parent's context. Such separation does not remove dependencies: the parent still needs the findings before using them in its diagnosis. [4][10][11]

Expand ⤢

Choose boundaries by inspecting prerequisites, shared assumptions, readable inputs, permitted writes, and the final acceptance condition. For example, inspecting a producer and a consumer separately can expose useful parallel work, but their reports must still be checked against the same interface contract. Concurrently changing both sides without preserving that contract creates additional coordination instead. [2][12]

The testing interface can determine whether useful independent work exists. In Nicholas Carlini's February 2026 compiler-building report, independent failures initially gave parallel agents separable debugging tasks. Linux compilation later concentrated them on the same bottleneck, causing duplicated effort and conflicting changes. The team used the existing GCC compiler for most files and its developing compiler for selected files, making failures easier to localize and divide among agents. This was an experimental project, not a controlled agent-count speedup study. [13]

Roles and decision rights

A role specifies a reusable responsibility. An instance is a participant performing it, and an assignment is the particular work it currently owes. Its deliverable is the result another participant will inspect or consume. These distinctions prevent a broad label such as reviewer from substituting for a concrete promise. [3][14]

Specialization should change actual instructions, information, capabilities, or assessment duties. In Medic, dedicated prompts and restricted tool subsets made diagnostic responsibilities easier to maintain and test separately. That is a maintenance benefit reported for this system, not proof that every specialized prompt creates expertise. [11]

Keep the acting software, its accountable owner, and the requester it represents distinct. Permission to investigate is not permission to commit a change; delegated authority governs that boundary. Likewise, separate conversations or repository copies are not necessarily execution isolation. A locally useful objective must remain subject to global constraints, such as preserving the public interface. [16][3][12]

Coordination structures

Once contributions have boundaries, choose how work is assigned and released. In supervisor–worker delegation, a supervisor requests bounded work and retains orchestration responsibility. A handoff instead transfers responsibility for subsequent work under the application's contract. Either arrangement can use the same underlying model. [17][18]

Negotiated allocation is useful when the appropriate worker is not fixed beforehand. Contract Net's manager announces eligibility conditions, required bid information, and an expiration. Participants bid; the manager selects a contractor and supplies the information needed to begin. Manager and contractor are task-specific roles, so a contractor can subcontract. Selection still depends on application-defined capability and eligibility rules. [6]

Shared state consists of records accessible to several participants. A blackboard uses shared intermediate results to coordinate further work. In Hearsay-II, changes to hypotheses activated eligible knowledge sources. A contemporary example, ActiveGraph, uses behaviors that react to graph state and emit events; completing research can release a dependent writing task. [19][20]

Choreography coordinates through published events rather than a central caller: each participant subscribes to relevant events and publishes its own outcomes. This reduces direct coupling but distributes delivery and debugging obligations. A missing result might mean publication failed, consumption failed, or duplicate handling went wrong. Shared-state activation and event choreography can coexist, but neither makes write authority implicit. [21]

Communication structure and authority structure are separate. A central supervisor can leave domain judgments to specialists while owning integration. Conversely, peer messaging still needs rules for resolving dependencies. AutoGen makes a related distinction between participant reply behavior and speaker-selection control. A graph or conversation interface alone does not specify who may accept a result. [22][8]

Send usable results

Inter-agent communication is an interface, not an unrestricted conversation. A request asks for work; an observation reports something encountered; a proposal recommends a change; progress describes unfinished work; an accepted decision records what the authorized owner has settled. Treating these as interchangeable text can turn a suggestion into an unintended instruction or a progress update into a completion claim. [23][24]

Common ground, operationally, is the task-relevant information participants have established for their joint work; it need not mean identical beliefs. Communicate changes that affect another participant's choices. STEAM made this tradeoff explicit: leaving teammates uninformed can damage coordination, but communication itself costs resources. Its selective policy addressed this in symbolic-agent simulations, not language-model teams. [7]

A usable result identifies its assignment, sender, inspected scope, assumptions, findings, supporting artifacts, and unresolved limitations. Provenance records origin and derivation: the inputs used, the activity producing a result, and the responsible participant. The W3C PROV model separates these entities and relationships; a report derived from another report is not another original observation. [25][26]

Only information crossing the result boundary is available to the recipient. LangChain's subagent guidance identifies a concrete failure: a worker investigates successfully but omits its findings from the returned response. Forwarding everything is not the only remedy. Select relevant findings, preserve references to detail, and retain qualifications. Context selection and recoverable compaction develop this tradeoff. A schema can require fields without proving their contents true. [17][28]

Accept shared-state changes

An agent's current context is a local view. A candidate artifact is a proposed contribution. A task record describes obligations and status. An accepted decision governs subsequent work. Keeping all four in one database does not make them equivalent, nor ensure that every participant has read the latest version. [29][30]

Authoritative state is the application-controlled record used to decide what may happen next. Workers can produce separate contributions while an explicit acceptance boundary controls shared changes. LangGraph's orchestrator-worker example, for instance, gives workers their own state and collects outputs in a shared field. Collection itself is not verification or conflict resolution. [29]

ActiveGraph's proposal path records a target version before application. If two proposals target the same version, applying one makes the other stale. The second needs reconsideration against current state. This applies to the explicit proposal path, not all mutations; freshness checks do not establish semantic correctness or permission. [24]

Read and write ownership should follow these distinctions. A message sends selected information to named recipients. A shared task ledger exposes assignments and accepted status. A blackboard exposes intermediate material that can activate further work. Each needs explicit rules for refreshing readers and accepting writes. An ordered commit boundary can prevent lost updates without serializing every investigation; state acceptance explains the underlying protection. [20][31]

When an input is superseded, record which contributions depended on it and notify their owners to revalidate. Provenance supplies the relationships, not automatic invalidation. Retained knowledge needs the same care: memory consolidation must not turn repeated copies of a finding into additional support. [25][27]

Transfer responsibility explicitly

A successful handoff requires agreement about the work that continues, not merely delivery of a message. The recipient needs the current objective, relevant state, permitted actions, deliverable location, outstanding obligations, and a route for clarification or refusal. Use durable task identities and retained artifacts so these obligations survive a worker's lifetime. [32][15]

The FIPA Request protocol distinguishes agreement or refusal from reported success or failure, although explicit agreement is optional in specified circumstances. An operational counterpart is PagerDuty acknowledgment: it records a responder claiming an unresolved incident, while missing acknowledgment permits escalation. Neither precedent makes a completion report independent proof of the requested outcome. [23][33]

A practical ownership policy keeps the sender responsible while acceptance is pending or refused, assigns execution responsibility after acceptance, and names who owns recovery if the recipient cannot continue. Bind these decisions to the assignment revision. Changed scope should supersede affected assignments rather than silently reinterpret their results. Integration should wait for required accepted contributions; optional work needs an explicit disposition, not an indefinite wait. [33][24][34]

Transport does not supply the whole agreement. Direct calls can suffice inside one application. Model Context Protocol (MCP) exposes tools and context; Agent2Agent (A2A) defines remote task exchanges, status, and artifacts. An MCP tool can wrap an agent without thereby acquiring A2A semantics. A framework handoff can also change control state without establishing business acceptance. Choose the integration boundary separately from the responsibility contract; the A2A specification describes its task model. [35][36][18]

Check the combined result

A semantic conflict is an incompatibility in meaning, assumptions, or combined effects. It can exist even when contributions are well formed, current, and individually acceptable. An invariant is a condition the combined result must preserve. Software contracts define such obligations; integration must check them across contribution boundaries. [12]

Sousa, Dillig, and Lahiri's November 2018 Verified Three-Way Program Merge illustrates this with two null-pointer protections. Each branch removes one protection while retaining the other. Combining their edits removes both. SafeMerge checks semantic conflict freedom rather than relying on textual compatibility. [12]

The same integration obligation applies to recommendations. Grounded Reasoning Systems for Cloud Architecture separates specialist candidate generation from central reconciliation, then elaborates surviving recommendations. The coordinator looks for conflicts and redundancies before investing in detailed proposals. This is a workflow example, not proof that a coordinating model always resolves them correctly. [22]

Integration should therefore compare assumptions and effects against the shared requirement, not merely concatenate outputs or select the last writer. When requirements themselves disagree, preserve the alternatives and identify the authorized decision-maker. Conflicting code and organizational guidance should remain visible together; silently choosing one can conceal the very issue requiring review. Another fluent summary is not a substitute for that decision. [22][37]

Preserve useful independence

Correlated mistakes occur together because participants share a misleading source, assumption, model behavior, or influence from another answer. Several agreeing reports can all descend from one mistaken premise. Different role names or models do not establish independent confirmation; the information and checking paths matter. [4][38][27]

Independent initial work followed by comparison differs from discussion in which participants revise after seeing one another's answers. In Debate or Vote, majority voting explained much of the gain over one response across seven tested benchmarks and exceeded the tested debate variants on average. More rounds sometimes hurt accuracy. These were mainly answer-generation tasks with a shared underlying model, not shared-state tool workflows. Sampling and agreement explains aggregation separately. [39]

Make the second participant's assessment duty concrete. Eugene Yan and Henna Dattani's May 27, 2026 security-review guide separates vulnerability discovery from adversarial verification. The verifier receives the finding and codebase in a fresh container, without the discoverer's conversation or filesystem, and searches for reasons the finding is wrong, including overlooked mitigations. [40]

Expand ⤢

That boundary reduces exposure to the discoverer's narrative; it does not remove shared code, model assumptions, or verifier error. Failure to reproduce an exploit does not prove its absence. Preserve the claim's origin, the check performed, and the check's result. Agreement about what to do remains distinct from correctness of the supporting claims. Checks and their limits develops the latter distinction. [40]

Control competing work

Contention is competition for limited access. Two agents can interfere through a mutable file, database record, browser session, or service quota even when their assignments differ. A shared browser is especially concrete: one participant's navigation changes the state the other is observing. Partition resources where possible and coordinate access where sharing is necessary. [2]

Duplicate work repeats an investigation or action. Independent replication can be deliberate scrutiny; accidental repetition wastes capacity. Unique task IDs distinguish records, not semantic scope: two differently named tasks can pursue the same bug. The compiler project used task claims and separate repository clones but still encountered overlapping work and integration conflicts. [13]

A lease grants temporary permission; expiry does not prove that its holder stopped. Fencing checks an ownership generation where an update is accepted. Chubby uses sequencers to reject obsolete lock-holder requests that arrive late. Apply the same distinction when reassigning agent work: a replacement must not make an old result newly authoritative. Stale-result rejection covers the runtime mechanism. [41]

Deadlock is circular blocked waiting—for example, each of two participants waits for a result the other will produce only afterward. Livelock is continued activity without progress, such as repeatedly revising assignments in response to one another without settling either. Neither is diagnosed merely by slowness or message volume. Identify the missing progress and actual dependency before adding workers or retries. [43][44]

Budget the complete team

Fan-out launches separate work; fan-in combines the required results. Under fixed durations and represented constraints, the critical path is the longest dependency path determining earliest completion. A required slow contributor delays integration even if every other worker is finished. Shortening work off that path does not necessarily shorten the task. [45]

Consider two independent inspections taking six and four seconds, followed by four seconds of integration and checking. Keep these work durations fixed while varying dispatch overhead and resource availability. Elapsed completion depends on the resulting schedule; summed leaf-operation durations measure something different and are neither token counts nor monetary charges. [45]

Additional resource waits need their own intervals or constraints. If both inspections require one exclusive session, the assumed overlap is infeasible. Do not count prerequisite waiting again inside an operation's duration. Changing concurrency can also change queueing, so yesterday's observed waits are not constants for a new schedule. [46]

Amdahl's law expresses the fixed-workload limit imposed by unchanged serial work: accelerating only one portion leaves the rest. For agents, delegation may also change investigation depth, communication, and quality, so the law is a useful constraint rather than a universal scaling forecast. Completion-path budgeting treats the timing analysis in more depth. [47]

Allocate the aggregate budget across the delegation tree. Bound concurrency and delegation depth, and reserve capacity for synthesis, checking, and recovery. Giving every child the parent's entire allowance multiplies exposure rather than preserving the limit. Repeated summaries and unnecessary exchanges belong in the consumption ledger alongside useful investigation. [48][49][50]

Pydantic AI documents passing a parent's usage object into delegated runs for aggregate accounting. Its Temporal-activity exception matters: a copied context does not propagate delegated usage back that way. Across different models, aggregate tokens also do not reconstruct price. Keep requests, tokens, priced usage, elapsed time, and human review effort separate. [48][51]

Contain failure and unfinished work

Failure containment limits which assignments, artifacts, resources, and decisions a failure can affect. A crash leaves execution unfinished; an incorrect contribution threatens dependent conclusions; a blocked dependency prevents useful continuation; a common failure can affect every participant. Separate proposal areas and validation before shared publication keep a worker's output from automatically becoming the team's accepted state. [52][30]

Logical roles are not containment barriers. Enforce tool permissions and execution isolation at the actual resource boundary. Then use recorded dependencies to select repair scope: preserve unrelated accepted work, but revalidate conclusions that relied on an invalid contribution. Lineage identifies candidates for repair; the application must decide whether they remain valid. [3][25]

Python 3.11's TaskGroup and gather illustrate different local policies: TaskGroup cancels siblings after a non-cancellation exception; gather normally lets them continue, and can collect exceptions alongside results. These semantics do not detect plausible wrong answers or provide durable distributed ownership. [34]

Structured concurrency ties child lifetimes to an owning scope. Across worker or coordinator loss, retained assignments still need a named recovery owner. Deliberately detached work needs its own owner and control handle. Cancellation scope must be explicit: Pydantic AI distinguishes a delegate cancelling itself from a shared token cancelling a run tree. [48][53]

A stop request is not proof that remote execution ended. Temporal documents cooperative cancellation and timed-out attempts that may continue while another attempt runs. Preserve uncertain external outcomes and reconcile them before repeating consequential actions; effect recovery owns that mechanism. A deadline can end the current attempt without making missing required work complete. [54][53]

Find the consequential exchange

A trace correlates operations in an execution; a span records one operation. Observability explains those primitives and their propagation. Multi-agent diagnosis additionally needs to reconstruct what one participant made available, what another actually received, and which contribution the system accepted. [55][56]

Lamport's ordering of distributed events gives a useful constraint: sending a message precedes its receipt, and these relationships compose with local event order. Nearby timestamps alone do not show that information crossed a boundary. Even a recorded receipt establishes possible influence, not that the model understood or used the message. [57]

In the reported pharmaceutical analytics failure, attribution identified reduced insurance coverage and patient affordability as causes of declining prescriptions. The later recommendation emphasized sales-representative activity instead, then forecast improvement from that intervention. The observed problem was a broken connection between cause and action. The speakers attributed it to their decomposition; the example alone does not isolate architecture from model capability. [58]

The repair depends on where the connection failed. Missing evidence calls for investigation; a finding omitted from transmission calls for a better result contract; received information ignored during synthesis calls for different synthesis constraints; an incoherent recommendation accepted afterward calls for a stronger final check. Why Do Multi-Agent LLM Systems Fail? documents lost context, ignored inputs, missing clarification, and inadequate verification as distinct observed failures. Such labels organize diagnosis; controlled changes test its explanation. [52][56]

Compare complete designs

Compare a capable single agent, a prescribed workflow with useful parallel operations, and the proposed cooperating team. A paired comparison evaluates alternatives on the same tasks. Restore each starting environment, repeat trials to expose variability, and inspect the final artifact or environment outcome rather than accepting the system's own completion claim. [59]

An equal-resource experiment asks which architecture uses a stated allowance better. A practical comparison asks which design meets a quality requirement and deadline at acceptable cost. These are different claims. Towards a Science of Scaling Agent Systems found task-dependent results: separable financial investigations benefited, while all tested multi-agent variants underperformed the single-agent baseline on sequential inventory-changing planning. Matching maximum total iterations did not equate realized tokens, prices, or latency. [60]

An architectural ablation removes or changes one mechanism to test its contribution. Remove peer discussion while retaining independent work; replace dynamic assignments with prescribed ones where feasible; change context separation without silently increasing resources. The debate-versus-voting result makes communication removal an informative test, not a universal recommendation to suppress communication. [39][60]

Keep a boundary when focused responsibility, separate information, or useful parallel progress improves the complete outcome enough to repay coordination. Simplify it when prescribed work delivers the same benefit with less uncertainty. Remove it when repeated explanation, conflicting contributions, or recovery dominates. Victor Dibia's eval-driven design guidance captures the practical discipline: establish a working baseline, then add agent complexity only when task-specific evaluation supports it. [61][9]

Open questions

1. 01

   Predicting useful decomposition remains difficult because task coupling can emerge during execution. Progress would mean recognizing when independent work has become a shared bottleneck and revising assignments without losing useful progress. [13]

2. 02

   Selective communication must preserve consequential changes without consuming the benefit of delegation. Useful progress would demonstrate task-specific policies that reduce exchanges while retaining coordination under unexpected conditions. [7]

3. 03

   Semantic integration is harder than version checking: current, individually valid proposals can still conflict. Progress would connect executable shared requirements to acceptance checks that detect incompatible combined effects without rejecting useful alternatives. [12]

4. 04

   Measuring the value of agent boundaries requires separating decomposition from extra computation and human repair. Stronger comparisons would include credible single-agent and prescribed-workflow baselines, matched operating conditions, and measured integration and recovery effort. [14][51]