Multi-Agent Systems
When More Than One AI Process Shares a Mission
One Mission, More Than One Worker
Our Agent Loop followed one model-driven process through repeated inference, tool use, observations and state updates. A larger system can divide work among multiple agent processes.
A multi-agent system is not one larger mind. It is a coordinated system containing multiple agent processes, each with its own work, state and interactions.
Those agents may use the same underlying model, different models, different tools, different permissions, or different instructions. What makes the system multi-agent is the organization of multiple agentic processes—not simply the number of GPUs or model copies.
A Simple Mission
Suppose the mission is:
Instead of one agent doing everything sequentially, an orchestrator could divide the work.
Host / Service
Check reachability, service state, ports and system-level evidence.
Logs / Configuration
Inspect logs and configuration diagnostics for likely failure evidence.
External View
Test DNS and HTTP behavior from the client-facing side.
Synthesis
Receive evidence from the other agents, reconcile it and prepare the final report.
Delegation Creates a Graph
The mission is no longer best pictured as one straight timeline. It becomes a dependency graph.
A, B and C may begin independently. D cannot finish until the evidence it requires arrives. Some branches may complete quickly; others may wait on tools, networks, permissions or external systems.
Parallel work removes some sequential waiting. Dependencies put waiting back wherever later work requires unfinished results.
How Do Agents Communicate?
Not telepathy.
If Agent A's finding influences Agent D, some mechanism must carry that information. Examples include:
Message
One process sends structured text or data to another.
Shared Store
An agent writes results to a database, queue, file or task store that another process reads.
Orchestrator
A controller receives one agent's result and places selected information into another agent's context.
Tool / Event Bus
External infrastructure transports events, tasks or results between components.
Every Agent Still Performs Ordinary Inference
Adding agents does not replace the mechanism we already built.
Then come logits, token selection, generation and possibly a structured tool request. A multi-agent system is built above those familiar inference mechanics.
The new complexity comes from having multiple loops, multiple contexts, multiple tool interactions and communication between them.
Separate Contexts
Agent A and Agent B do not necessarily share one context window.
| Agent | May Receive | May Not Receive |
|---|---|---|
| A — Host | Mission, host identity, service tools, prior host observations | Every raw log examined by B |
| B — Logs | Mission, log sources, config-test tools | Every network test performed by C |
| C — External | Mission, hostname, DNS/HTTP tools | Internal configuration details |
| D — Synthesis | Selected findings and evidence from A/B/C | Potentially large amounts of irrelevant intermediate material |
This can reduce context load and specialize work—but it creates a new problem: what information should be transferred?
Compression Can Lose Evidence
If Agent B examines 10,000 log lines and sends D only:
the summary may be useful, but important provenance has disappeared. A stronger handoff might include the finding, source, timestamp, exact relevant event identifier, diagnostic result and confidence/uncertainty.
Multi-agent systems therefore create an information-compression problem:
Each arrow is a place where detail can be selected, transformed, summarized—or lost.
Roles Are Instructions, Not New Species of Model
An “investigator agent,” “planner agent,” or “reviewer agent” may simply be a model instance given different instructions, tools, state and permissions.
Role specialization can come from system design even when the underlying model is identical.
Conversely, a system can deliberately use different models because one is faster, cheaper, more specialized, or suited to a particular task.
Same Model, Different Agents
Agent A
Model M + host instructions + diagnostic tools + state A.
Agent B
Model M + log-analysis instructions + log tools + state B.
Agent C
Model M + external-test instructions + network tools + state C.
Three agents need not mean three different trained models. They may be three separate inference streams built around the same model weights.
Capability Arrays Can Differ
Each agent can receive only the tools relevant to its role.
| Agent | Capability Array |
|---|---|
| A | ping_host, service_status, listening_ports |
| B | read_log, config_test |
| C | dns_lookup, http_request |
| D | read_agent_results, produce_report |
This reduces unnecessary access and makes the system easier to reason about.
RWCX Applies Per Agent
Page 33's control boundary becomes even more important here. Each agent can have a different operating envelope.
And our refinement from Page 33 matters:
R / W / X describe operations or permissions. C asks the separate consequence question: what state changed?
A model may request an operation. The orchestrator checks authority. The tool may execute. WITNESS can then ask whether external state actually changed.
Coordinator Patterns
There is no single required multi-agent architecture. Several patterns are possible.
Supervisor
One coordinating agent delegates work and receives results.
Central Orchestrator
Non-model software assigns tasks and routes messages according to explicit workflow logic.
Peer Collaboration
Agents exchange messages or tasks with one another under defined protocols.
Pipeline
One agent's output becomes the next agent's input in a mostly fixed sequence.
Real systems can combine these patterns.
Agreement Is Not Automatically Truth
If three agents independently produce the same conclusion, that may be useful evidence—but it is not automatically independent confirmation.
If all three use the same model, same prompt assumptions, same flawed source or same mistaken intermediate result, they can share the same error.
For stronger verification, independence may require different evidence sources, different tools, different methods, or a verifier that tests the claim against the external world.
Agents Can Disagree
Suppose:
B: configuration syntax test fails.
C: DNS resolves correctly but HTTP connection fails.
These findings are compatible and reinforce a diagnosis. But agents can also return genuinely conflicting observations.
The system then needs a policy: gather more evidence, repeat a test, prefer a more authoritative source, ask a human, or report the disagreement explicitly.
Do not force uncertainty into artificial agreement.
Race Conditions and Stale State
Multiple agents can operate concurrently. That introduces familiar distributed-systems problems.
Stale Observation
Agent A reads state at 10:01. Agent B changes or observes a changed world at 10:02. A's information may already be outdated.
Race Condition
Two agents attempt dependent or conflicting operations without adequate coordination.
Duplicate Work
Agents unknowingly perform the same expensive operation.
Conflicting Writes
Two authorized agents attempt incompatible changes to shared state.
Once agents can change external systems, ordinary lessons from databases, operating systems and distributed computing come roaring back.
Synchronization Points
A system may deliberately stop until required branches complete.
The fastest agents do not eliminate the dependency on the slowest required result.
And sometimes waiting is the correct behavior. Acting before necessary evidence arrives can be worse than being slow.
Cost Scales Too
More agents can provide specialization and parallelism, but they also create more:
Multi-agent architecture is therefore a design tradeoff, not an automatic upgrade.
Where Is “The Mission”?
The mission itself may be represented in several places: initial instructions, orchestrator state, task records, agent contexts and human approvals.
No single transformer needs to contain the entire live mission state continuously.
This connects directly to Page 32: agent state, context and persistent storage are different things.
The WITNESS Problem Gets Bigger
With one agent, we already had an event field. With several agents, WITNESS must preserve both time and lineage.
For each important event we may need:
A simple chat transcript is no longer enough.
From Timeline to Dependency Graph
↓
A ─────┐
B ─────┼──→ D SYNTHESIS → REPORT
C ─────┘
Events can overlap in time while still having causal dependencies. WITNESS therefore benefits from recording identifiers and parent/child relationships rather than relying only on timestamps.
“What happened next?” is not always the same question as “What caused this?”
No Evidence of a Hive Mind Is Required
Fast, coordinated behavior can look remarkably unified from outside. But a coherent system-level result does not require hidden mind-to-mind communication.
Before proposing anything exotic, HAAW asks for the ordinary mechanisms:
If those mechanisms explain the observed coordination, we have no need to invent another one.
The Boundary
A multi-agent system contains multiple agentic processes working within a coordinated mission.
Each agent may have its own context, state, role, capability array and permissions.
Information moves between agents through observable system mechanisms.
Parallel work creates speed opportunities; dependencies create synchronization and waiting.
Agreement between agents is not automatically independent verification.
Once multiple agents share or change external state, familiar distributed-system problems appear.
The apparent unity belongs to the system. Underneath it may be many separate inference loops exchanging information.
HAAW Checkpoint
Multi-Agent System: A coordinated system containing multiple agentic processes.
Agent Role: Instructions, responsibilities, tools and constraints assigned to an agent process.
Delegation: Assigning part of a larger mission to another agent or process.
Message: Information explicitly transferred between components.
Shared State: External information accessible to more than one process.
Supervisor: A coordinating agent that delegates work and receives results.
Orchestrator: Software that manages tasks, routing, state, permissions and execution flow.
Synchronization Point: A dependency boundary where later work waits for required earlier results.
Race Condition: Behavior whose result depends improperly on timing or ordering of concurrent operations.
Lineage: The recorded parent/child and source relationships connecting events, evidence and derived results.
Independent Verification: Confirmation designed to avoid merely repeating the same source, assumptions or failure mode.
Central lesson: Multiple agents mean multiple inference loops plus communication, coordination, state and control—not a mysterious shared mind.
Coordination and Communication — Messages, Shared State, Synchronization and the Cost of Working Together