Multi-Agent Systems

Do We Actually Need Multiple Agents?

One agent with tools can already retrieve information, choose an action, call a service, observe the result, and continue. It can often handle more work than the first architecture suggests.

Then the prompt grows. The tool list becomes crowded. The task needs several kinds of expertise. Some subtasks appear independent. The context no longer fits comfortably in one working set. Someone proposes adding a specialist agent.

Sometimes that is the right move. Sometimes it turns a manageable loop into a distributed system with weak contracts and expensive conversations.

A multi-agent system is a system in which multiple model-driven workers coordinate to complete a task. They may be arranged under a manager, connected through handoffs, run in parallel, or exchange artifacts through a shared store. Each agent may have a distinct prompt, model, tool set, context, role, or authority.

The phrase is useful only if it makes coordination visible. Multiple calls to the same model are not automatically multiple agents. Multiple agents are not automatically a team. A collection of prompts becomes a system when work, state, communication, and responsibility cross agent boundaries.

The durable question is not whether multiple agents can collaborate. It is whether the additional boundary creates enough specialization, parallelism, isolation, or context capacity to justify the communication, consistency, cost, and accountability it adds.

This is Post 13 in The Abstraction Shift: How Software Keeps Moving Up.

In One Sentence

Multi-agent systems distribute model-mediated work across coordinated agents, gaining specialization or parallelism while inheriting the failure modes of distributed systems.

The system needs more than a collection of model calls. It needs task identity, delegation rules, communication contracts, shared or referenced state, completion semantics, error propagation, budgets, authorization, aggregation, verification, and a final owner.

An agent can be treated as a worker with a language interface, but language is not a free communication channel. Messages consume tokens, lose detail, introduce ambiguity, and create new opportunities for contradiction. A shared artifact can preserve fidelity, but it creates consistency and ownership questions of its own.

The central architectural choice is therefore not one agent versus many in the abstract. It is where to put boundaries and what each boundary is allowed to mean.

Why This Exists

One agent can become a poor container for every responsibility:

triage the request;
find evidence;
inspect a codebase;
operate a browser;
call a finance system;
write a report;
review its own work;
explain the result to a user.

Adding instructions and tools can help for a while. Eventually the agent has to choose among too many overlapping capabilities, carry too much context, or reason about too many conditional rules at once.

Multiple agents can help when the task has one or more of these properties:

independent subtasks can run in parallel;
different subtasks need different tools or context;
a specialist prompt is easier to optimize than one general prompt;
the total information exceeds a useful single context window;
separate agents provide independent attempts or review;
organizational or security boundaries map naturally to different workers;
a lead agent needs to decompose a goal that cannot be planned completely in advance.

These are real benefits. They do not come for free.

Every new agent adds:

another context boundary;
another prompt and tool contract;
another source of latency and cost;
another partial failure mode;
another output that must be integrated;
another place where authority can become ambiguous.

The first design decision should therefore be whether one agent with clearer tools, better context selection, or a better prompt would solve the problem. Multiple agents are an architectural response to a measured bottleneck, not a synonym for sophistication.

What We Did Before

Actor systems

The actor model treats independent actors as units that receive messages, maintain private state, and send messages to other actors. It made concurrency and isolation explicit without requiring every worker to share memory.

Multi-agent systems revisit this shape with a model as part of the actor’s decision loop. The old questions remain: who addresses a worker, what state does it own, what messages are valid, what happens when a message is delayed, and who notices that an actor stopped responding?

Worker pools and task queues

Worker pools divide work across processes or machines. A queue holds tasks until a worker claims one. The system can scale throughput without requiring every worker to understand the whole application.

An agent worker may be more flexible about how it completes a task, but the queue still needs a task contract. It needs a visibility timeout, retry policy, deduplication strategy, ownership, and a way to report partial or failed completion.

Map-reduce and parallel pipelines

Map-reduce separates a transformation over many items from the reduction that combines the results. Parallel pipelines use the same basic idea: split work, execute branches, aggregate outputs.

This is a strong lineage for research, classification, document processing, and independent analysis. It also exposes the hard part. The map step is easy to parallelize only when the subtasks are sufficiently independent and the reduce step knows how to reconcile their outputs.

Microservices and service choreography

Microservices split a system by capability, ownership, deployment boundary, or scaling need. Service choreography lets components react to events without one central coordinator deciding every interaction.

Agent boundaries may look similar, but an agent is not a service merely because it has an endpoint. Services generally expose more stable contracts. Agent outputs may vary, omit a field, or interpret the same request differently across runs.

The more a multi-agent system relies on important cross-agent decisions, the more it needs explicit schemas, capability descriptions, versioning, and observability.

Ensembles and expert committees

Ensemble methods combine multiple predictions. Expert committees combine independent judgements. Voting can reduce the chance that one attempt dominates an uncertain task.

Independent opinions help only when the errors are not perfectly correlated and the aggregation rule has a reason to work. Five agents using the same context, prompt, and mistaken assumption may produce five versions of the same error.

Human teams and organizational handoffs

Human teams specialize, divide work, review each other, and use shared documents to coordinate. They also lose context at handoffs, duplicate work, wait on dependencies, and disagree about ownership.

The analogy is useful because multi-agent design is partly organizational design. A role is not a responsibility until its input, output, authority, and escalation path are clear.

Multi-agent systems recombine familiar distributed-work patterns with model-mediated planning, delegation, and synthesis.

The Abstraction Shift: How Software Keeps Moving Up

A single agent with tools has one primary control loop:

goal → context → tool choice → observation → next action → result

The model may select tools and adapt to results, but one loop owns the working context and the next decision.

A multi-agent system adds a coordination layer:

goal → coordinator → task allocation → specialist work → communication or artifacts → aggregation → verified result

Now there are several loops and at least one boundary between them. The system has to decide:

who creates a task;
who can accept or reject it;
what context crosses the boundary;
whether the worker can call tools directly;
how the worker signals progress and completion;
how failures reach the coordinator;
how results are combined;
who owns the final decision.

This is the abstraction shift: the unit of reasoning is no longer only the agent’s loop. It is the topology of loops and the contracts between them.

The gain can be real. Independent workers can explore different directions, use smaller focused contexts, or operate concurrently. The cost is also real. The coordinator now has to integrate distributed state, and the system can fail even when every individual agent appears competent.

What Counts as a Multi-Agent System?

The term should describe a boundary that changes architecture.

A system is meaningfully multi-agent when at least one of these is true:

separate model loops have distinct responsibilities or authority;
one agent delegates work to another;
agents communicate through messages, handoffs, or shared artifacts;
subtasks execute concurrently and later require aggregation;
different agents maintain separate context or memory;
the system evaluates or verifies one agent’s work with another;
an external protocol lets independently deployed agents discover and coordinate with each other.

A system is probably not meaningfully multi-agent when it is only:

a sequential prompt chain with no independent worker boundary;
several calls made by one orchestration loop for simple formatting;
one agent using several tools;
multiple samples that are never independently interpreted or aggregated;
a set of personas that share one context and have no distinct contract.

The label matters because it changes what must be tested. Once work crosses a boundary, the system needs coordination tests in addition to model-quality tests.

The Main Topologies

Manager and workers

A central manager agent decomposes the goal, calls specialist agents as tools, and synthesizes their results.

This topology keeps the user-facing interaction and final composition in one place. It is useful when there is one clear owner for the task and specialists are capabilities rather than peers.

The manager can become a bottleneck. It may also over-delegate, duplicate work, or discard important detail while compressing worker output.

Pipeline and handoff

One agent completes a stage and hands the task to another:

intake → researcher → analyst → writer → reviewer

This resembles a workflow with model-mediated steps. It works when the stages have stable contracts and each stage transforms an artifact for the next one.

The risk is that each handoff can narrow or distort the context. A later agent may be unable to recover information that an earlier agent omitted.

Parallel specialists

A coordinator sends independent subtasks to several specialists and aggregates their results.

This is a natural fit for breadth-first research, document processing, independent code review, or analysis over many records. It is a poor fit when the subtasks depend heavily on each other or all workers need the same evolving state.

Parallelism also creates a synchronization point. The system must decide whether to wait for every branch, accept partial completion, retry only the missing branches, or stop when enough evidence exists.

Peer handoffs

Agents act as peers and transfer a task to the next specialist based on its current state. There may be no central agent that sees every step.

Peer handoffs can map to organizational or domain boundaries. They also make global reasoning and debugging harder. A task may move through several agents while no component has complete knowledge of why it moved.

Shared artifact or blackboard

Agents write findings to a shared store and pass references rather than copying all content through messages. A coordinator or verifier reads the accumulated artifacts.

This can preserve large outputs and reduce message cost. It introduces the need for versioning, ownership, access control, freshness, conflict handling, and a definition of what counts as complete.

Topology determines where context, decisions, failures, and coordination costs accumulate.

One Agent Plus Tools Is Often Enough

The simplest architecture has a large advantage: one loop owns the task.

Start there when:

the task has one coherent context;
tools can be made distinct and well-described;
subtasks are sequential or lightly parallel;
one model can produce and verify the result;
the system needs a simple trace and evaluation surface;
the additional agents would all share the same assumptions and authority.

A single agent can still use prompt templates, structured outputs, retrieval, memory, deterministic tools, evaluators, and workflow checkpoints. Adding those capabilities may solve the actual bottleneck without adding coordination.

OpenAI’s practical guidance describes single-agent systems as a useful starting point because tools can be added incrementally while keeping evaluation and maintenance manageable. This is not an argument against multi-agent design. It is an argument for measuring the need for the boundary.

When to Split an Agent

Split the system when the boundary buys something specific.

Complex logic

If one prompt contains many conditional branches and exceptions, separate agents can make each responsibility easier to understand and evaluate.

The split should reduce cognitive load. If the manager still has to understand every specialist’s internal rules, the system may have moved complexity without removing it.

Tool overload

Tool count is not the only issue. Overlapping tools with similar names, arguments, or authority are especially difficult for a model to select reliably.

A specialist with a narrow tool set can reduce choice ambiguity. First improve names, descriptions, schemas, examples, and authorization. Split only when clearer tools do not solve the problem.

Parallelizable work

Independent work can justify multiple agents when latency matters and aggregation is reliable. The subtask boundary should be real: two workers should be able to make progress without constant synchronization.

If each worker waits for the other’s latest context, the system may pay multi-agent overhead without getting parallelism.

Context capacity

Separate workers can give each subtask a smaller, more relevant context. A coordinator can retain a plan while specialists inspect large sources or code regions.

The boundary should be implemented with durable artifacts or concise structured handoffs. Copying entire transcripts between agents recreates the context problem and adds cost.

Independent review

A second agent can inspect an artifact with a different prompt, tool set, or context. This creates useful separation only when the reviewer has a meaningful independence from the generator.

If both agents see the same unsupported claim and are optimized for agreement, the second opinion may merely amplify the first.

Ownership or security boundary

A separate agent can represent a domain or team with its own tools, data, policy, and release responsibility. The boundary can be valuable even when it costs latency because it makes authority explicit.

Do not use an agent boundary as a substitute for access control. The runtime still needs to enforce identity and permissions.

The Coordination Contract

Every agent boundary needs a contract at least as carefully designed as a tool.

Task identity

Each delegated task needs a parent execution, a task identifier, an owner, a scope, and a lifecycle. The worker should know what it is solving and how its result will be used.

Input and context

Specify the minimum context required to do the work. Prefer references to large artifacts when the worker can retrieve them with the correct permissions. Include freshness, version, and source information.

Output and completion

Define the output schema, evidence requirements, confidence or uncertainty representation when useful, and completion conditions. “I think this is done” is not a reliable protocol.

Failure and partial completion

The worker needs a way to distinguish success, no result, blocked progress, tool failure, invalid input, and partial completion. The coordinator needs a policy for each case.

Communication budget

Bound messages, tokens, tool calls, fan-out, depth, elapsed time, and cost. A worker should not create more workers without an explicit allowance.

Authority

State what the worker may read, propose, change, or publish. A specialist should not inherit the coordinator’s full authority merely because it receives a delegated task.

Provenance

The result should identify which agent produced it, with which model and prompt or policy version, using which tools and artifacts, at what time, and under which task scope.

What Should Stay Centralized?

Distributed work does not require distributed authority.

Keep these responsibilities centralized or independently governed when they determine system safety and correctness:

user identity and top-level authorization;
task scope and budget;
access to sensitive data;
creation of new agents or delegation depth;
shared source-of-truth updates;
final aggregation and conflict handling;
external side effects;
human approval and escalation;
release, publication, or notification;
audit and incident response.

Agents can propose, inspect, classify, transform, and recommend. The coordinator or deterministic runtime should decide whether a proposal can cross an authority boundary.

This is especially important in decentralized systems. Handoff is not authorization. A peer agent that receives a task does not automatically receive permission to perform every action needed to complete it.

Agents can share work without sharing unrestricted authority. The coordinator, artifacts, verifier, and release boundary must remain explicit.

Where the Analogy Breaks

Agents are not interchangeable workers

A worker process usually follows executable code with a stable interface. An agent may interpret the same task differently across runs and may produce an output that is plausible but incomplete.

The worker contract must handle semantic variation, not only transport and process failure.

Parallel does not mean independent

Two subtasks can appear separate while sharing a hidden dependency, a rate limit, a source of truth, or an assumption about the current state.

Declare dependencies and resource ownership. Use external coordination when concurrent actions can conflict.

Communication is not context transfer

A summary preserves some meaning and discards some detail. A raw transcript preserves detail and consumes budget. A shared artifact preserves more information but introduces version and access concerns.

Choose the representation deliberately. Do not assume that a handoff is lossless.

Consensus is not correctness

Agreement among several agents can be correlated error. A majority vote is meaningful only when the attempts have useful independence and the aggregation rule matches the task.

For high-consequence outputs, use domain validation, ground truth, or human review in addition to agent agreement.

Specialization can become fragmentation

If every small responsibility becomes a named agent, the architecture becomes hard to reason about. The system has many prompts and few stable contracts.

Create a boundary when it reduces complexity, adds real parallelism, or represents real ownership. Do not create one merely because the role has a memorable name.

A coordinator can hide accountability

The lead agent may appear responsible for the final result even when a specialist made the critical decision. Conversely, every specialist may be treated as an independent owner even though no one could see the whole task.

Trace the chain from user goal to delegation, result, aggregation, verification, and release.

Under the Hood

A production multi-agent system can be described as eight stages:

1. Frame

Accept the goal, establish identity and scope, identify the source of truth, and decide whether multiple agents are justified for this run.

2. Decompose

Create subtasks with explicit objectives, constraints, dependencies, output contracts, and budgets. Reject decomposition that is too fine-grained to justify coordination.

3. Allocate

Select the worker, model, tools, context, permissions, and topology for each subtask. Record why the allocation was made.

4. Isolate

Give each worker only the context and authority required. Use separate sessions or sandboxes when work can conflict or when a specialist should not inherit unrelated state.

5. Execute

Workers use tools, retrieve evidence, transform artifacts, or make proposals. The coordinator tracks progress, time, cost, and resource contention.

6. Communicate

Workers return structured results, progress, blockers, and artifact references. Messages should be concise enough to fit the coordination budget and rich enough to preserve provenance.

7. Aggregate and verify

The coordinator or an independent verifier combines outputs, resolves conflicts, checks coverage, and tests the result against the source of truth.

8. Commit or escalate

The deterministic runtime records the final state. It performs an allowed side effect, requests human review, retries a failed branch, or stops with a clear explanation.

The difficult stage is usually not spawning a worker. It is integrating the work without losing the information needed to verify it.

A Concrete Example

Consider an incident response workflow for a production service.

The top-level workflow can:

receive an alert and bind it to a service and environment;
assign an incident identifier;
enforce a time and tool budget;
notify the incident owner;
create a shared incident record;
require approval before customer or infrastructure changes;
record the final timeline and resolution.

A coordinator agent can classify the alert and create bounded subtasks:

one specialist checks recent deployments;
one inspects logs and traces;
one reviews infrastructure health;
one estimates customer impact;
one drafts a rollback or mitigation proposal.

The specialists can work in parallel when their read paths are independent. They should return evidence references, timestamps, uncertainty, and a concise result rather than unstructured narrative.

An aggregator or incident lead can compare the findings. A verifier can check whether the proposed root cause is supported by the evidence. The workflow can ask a human to approve a rollback or customer notification.

The specialist agents should not independently:

deploy a change;
alter production configuration;
page unrelated teams without policy;
declare the incident resolved;
publish an unverified root cause.

The multi-agent design helps because the investigation has breadth and different tools. It does not make the final operational decision disappear.

Failure Modes

Duplicate work

Several agents investigate the same subproblem because task boundaries were vague. Include an explicit objective, search scope, and existing-work reference in every delegation.

Missing integration

Workers gather useful facts but the coordinator cannot combine them. Define the aggregation artifact before spawning the workers and require outputs that map to it.

Correlated error

Every agent receives the same misleading context or uses the same faulty tool. Independent prompts are not enough if the underlying evidence and assumptions are identical.

Coordinator bottleneck

One manager serializes every decision and becomes the latency and context bottleneck. Move independent work to parallel branches, use structured artifacts, or keep the system single-agent when the manager adds no value.

Unbounded spawning

A coordinator or worker creates more agents recursively. Limit fan-out, depth, total calls, cost, elapsed time, and delegation authority.

Message bloat

Agents copy large transcripts or repeated findings into every handoff. Use durable artifacts, references, summaries with provenance, and selective retrieval.

Stale shared state

Two workers read an artifact at different versions or write conflicting updates. Version the artifact, define ownership, and reconcile before release.

Partial completion treated as success

The coordinator stops after some workers finish and silently ignores blocked or missing branches. Make completeness explicit and expose partial results to the owner.

Deadlock and waiting

Workers wait for information from each other while the coordinator waits for all workers. Model dependencies, time out waits, and provide a fallback or escalation path.

Noisy consensus

Agents debate without a stopping rule or produce long arguments that do not improve the decision. Use criteria, budgets, and an independent verifier where disagreement matters.

Permission creep

A specialist receives more data or tool authority than its subtask requires. Enforce least privilege at the runtime boundary and make delegation scopes inspectable.

Lost accountability

The final answer cannot identify which agent made a critical claim or who approved the side effect. Preserve task lineage, artifact provenance, and decision ownership.

Cost explosion

Parallelism improves latency but multiplies inference and tool cost. Measure cost per completed outcome, not only cost per agent call.

Context fracture

No single component has enough context to understand the whole task. Use a durable plan, shared evidence state, and a final synthesizer or human owner.

Prompt injection across agents

A worker treats retrieved content or another agent’s message as an instruction rather than data. Mark trust levels, constrain tools, and apply the same input validation and policy checks at every boundary.

Version skew

Long-running tasks use agents with different prompts, tools, policies, or model versions after a deployment. Version the worker contract and make compatibility or migration behavior explicit.

Emergent topology

The system’s actual interaction graph differs from the designed graph because agents hand off, spawn, or retry in unexpected ways. Trace edges, not only nodes, and evaluate interaction patterns.

What Changes Because of It?

Architecture

The architecture gains a coordination plane. It needs task routing, worker lifecycle, message or artifact transport, shared state, aggregation, policy, and failure handling in addition to the agent loops themselves.

The graph becomes part of the product. A system with ten agents and clear boundaries can be easier to operate than one general agent with ten overlapping responsibilities, but only if the boundaries are real.

Engineering

Engineers design both agent behavior and distributed contracts:

prompts and schemas;
tools and permissions;
subtasks and dependencies;
messages and artifacts;
retries and deduplication;
aggregation and verification;
model versions and compatibility.

The hard engineering work moves from writing one very capable prompt to specifying how several imperfect workers exchange enough information to produce a reliable result.

Product and UX

Users need one coherent task experience even if many agents work underneath. Show useful progress, not an unfiltered transcript of every internal message.

When a result depends on disagreement or incomplete work, expose the relevant uncertainty and the choice available to the user. Do not present a synthetic consensus as if one agent had direct knowledge.

Security and governance

The system now has multiple principals, contexts, and tool surfaces. Identity, authorization, data access, and delegation must be evaluated per agent and per task.

An agent-to-agent protocol can standardize discovery and task exchange, but protocol compatibility is not trust. A remote agent still needs an identity, capability contract, allowed scope, and result-validation path.

Operations

Observability must capture the coordination graph:

parent and child task identifiers;
agent and model versions;
prompts, policies, and tool contracts;
allocation and handoff edges;
message and artifact references;
queue time, run time, retries, and cancellations;
cost and token budgets;
aggregation, verification, and final outcome.

Without graph-level traces, a multi-agent incident looks like many unrelated model failures.

Business and economics

Multi-agent systems can trade dollars for time, breadth, or specialized quality. That trade is valuable only when the completed outcome justifies it.

Measure the value of parallelism and specialization against coordination overhead, not against a single model call in isolation. A faster wrong answer is not a throughput improvement.

Human organization

Multi-agent systems often mirror organizational structures: a lead, specialists, reviewers, and owners. That can clarify responsibility, or it can encode a confusing hierarchy into software.

Name the human owner of the final outcome. Agent roles may change as models improve, but accountability cannot be delegated to a graph.

KNOW / UNDERSTAND / BUILD

KNOW

A multi-agent system has multiple model-driven loops that coordinate through tools, messages, handoffs, or artifacts.
The main benefits are specialization, parallelism, context separation, independent review, and ownership boundaries.
The main costs are communication, synchronization, integration, latency, token use, consistency, and accountability.
One agent plus well-designed tools is often the better starting point.
A multi-agent topology is a distributed system with probabilistic workers.
Handoff is not authorization, and consensus is not correctness.

UNDERSTAND

Whether a bottleneck is really prompt complexity, tool overload, context capacity, latency, or ownership.
Which subtasks are genuinely independent and which share hidden state.
How manager, pipeline, parallel, peer, and shared-artifact topologies change failure behavior.
What context must cross each boundary and what should remain private.
How to aggregate outputs, preserve provenance, detect correlated error, and represent partial completion.
Which responsibilities remain centralized: scope, identity, policy, source of truth, external side effects, and release.

BUILD

A single-agent baseline with clear tools and measured outcomes.
A task contract with identity, scope, input, output, completion, failure, budget, and authority.
A coordinator that limits fan-out, depth, latency, cost, and delegation.
Specialists with narrow context, tools, permissions, and evidence requirements.
Durable artifacts or structured messages with provenance and versioning.
Aggregation and independent verification against the source of truth.
Graph-level traces and evaluations for coordination behavior, not only individual answers.
A human escalation path for incomplete, conflicting, or consequential results.

Build It Once

Start with the smallest system that can reveal whether coordination helps:

Build a single-agent baseline and measure completion, latency, cost, rework, and failure severity.
Identify the bottleneck that a second agent is meant to address.
Define one specialist task with a narrow scope and a structured result.
Keep the coordinator deterministic where possible.
Run the specialist in shadow mode or on read-only work.
Compare the result with the baseline, including integration cost and human review time.
Add parallelism only when subtasks are actually independent.
Add durable artifacts before copying large context through messages.
Add policy, provenance, budgets, and failure states before increasing autonomy.
Recombine agents when the boundary no longer pays for itself.

The last step matters. An architecture should be allowed to become simpler. If a stronger model, better tool descriptions, or a clearer workflow removes the original bottleneck, merging agents may improve reliability and reduce cost.

The goal is not to create a society of agents. The goal is to make the smallest coordinated system that produces a better verified outcome than one agent with tools.

Will This Term Survive?

Terminology durability: Exact phrase: MEDIUM. Underlying pattern: HIGH.

Multi-agent systems is a durable description because multiple decision loops and coordination boundaries are a real architectural shape. Related terms will continue to appear: agent teams, agent swarms, collaborative agents, agent orchestration, agent interoperability, and distributed agents.

The metaphor of a team is useful for explaining specialization and communication, but it can hide systems concerns. The durable vocabulary is still task, state, message, artifact, authority, dependency, failure, and outcome.

The long-term pattern will likely include both tightly orchestrated specialists and independently deployed agents that discover one another through protocols. The number of agents is less important than the contracts and topology connecting them.

Where It Fits in the Map

Multi-agent systems connects the series’ control-loop, workflow, capability, context, state, and execution threads.

Post 02, Agent and Agent Design Patterns: provides the composable control-loop patterns. Multi-agent systems add coordination between those loops.
Post 04, Tool Calling: explains the capability boundary. A specialist agent may be exposed as a tool, but the boundary still needs task, output, and authority semantics.
Post 05, Model Context Protocol: provides a protocol lineage for discovering and exposing tools and context. Multi-agent systems extend the question from agent-to-tool to agent-to-agent coordination.
Post 06, Context Engineering: explains why separate context windows can help and why handoffs must preserve the right information.
Post 08, Agent Memory: distinguishes worker-local memory, shared artifacts, and authoritative system state.
Post 09, Reasoning and Inference-Time Compute: frames tokens, calls, latency, and verification as budgets that multiply across workers.
Post 10, Deep Research: is a strong use case for parallel independent investigation and evidence aggregation.
Post 11, Computer Use: shows why a specialist execution agent needs a controlled environment, scoped authority, and verified outcome.
Post 12, Agentic Workflow: supplies the deterministic orchestration shell that should coordinate model-driven workers.
Future Evals and LLM-as-a-Judge: will examine how to evaluate final outcomes and coordination behavior when several valid paths exist.
Future Guardrails and Agent Interoperability: will deepen policy, delegation, capability discovery, and cross-agent trust.

The abstraction shift is not from one agent to many agents. It is from one model-mediated control loop to a system of loops whose relationships become a new part of the architecture.

Sources

How we built our multi-agent research system, Anthropic: describes an orchestrator and worker research architecture, parallel subagents, shared artifacts, coordination challenges, evaluation, tracing, and the cost and reliability tradeoffs of multi-agent systems.
A practical guide to building agents, OpenAI: distinguishes single-agent and multi-agent orchestration, describes manager and decentralized patterns, and recommends maximizing a single agent’s capabilities before adding more agents.
Building effective agents, Anthropic: provides the workflow and agent pattern lineage for routing, parallelization, orchestrator and workers, evaluator loops, and open-ended agents.
Announcing the Agent2Agent Protocol, Google: describes protocol-level agent discovery, task management, collaboration, long-running tasks, and capability exchange across independent systems.
Silo-Bench, arXiv: studies distributed coordination in multi-agent LLM systems and the gap between acquiring distributed information and integrating it into a correct result.
A universal modular actor formalism for artificial intelligence, ACM: foundational actor-model lineage for independent computational units that coordinate through messages.