Multi-Agent System

A multi-agent system coordinates two or more LLM-driven agents — each holding a role, a set of tools, and often its own memory — working together toward a shared goal. Instead of one model attempting everything inside a single context window, work is split: a researcher agent gathers facts, a writer drafts, a reviewer critiques, a coordinator decides what happens next. Agents communicate by passing messages, results, or structured handoffs, and an orchestration layer determines who acts and when. The design instinct is old and sound — division of labor — applied to models whose attention, like a human's, degrades when a task sprawls.

Common topologies

The best-documented shape is the orchestrator-workers pattern, described in Anthropic's agent-design guidance: a central agent decomposes a task dynamically, delegates subtasks to worker agents (often running in parallel), and synthesizes their results. Alternatives include hierarchical arrangements (a planner supervising executors, as in the planner-executor pattern), sequential pipelines where each agent hands its output to the next, and peer-to-peer designs where agents negotiate directly. Frameworks such as LangGraph, AutoGen, and CrewAI package these topologies, though the pattern needs no framework — it is ultimately structured message-passing between model calls. The right shape depends on whether subtasks are predictable in advance (pipelines suffice) or must be discovered at runtime (orchestration earns its keep). Parallel research across independent context windows is where multi-agent designs most clearly beat a single agent: each worker reads deeply, and only conclusions flow upward.

Trade-offs, stated honestly

Splitting work across specialists can improve quality and makes each agent simpler to reason about, test, and prompt. But every agent is another set of model calls, so latency and token cost multiply — multi-agent systems can burn many times the tokens of a single chat. Errors compound across handoffs: a researcher's small misreading becomes the writer's confident falsehood. Coordination itself is failure-prone — agents duplicating work, losing shared state, or deadlocking on ambiguous handoffs. The sober engineering guidance, echoed in Anthropic's own writing, is to reach for multi-agent designs only when a single agent with good tools, or a fixed workflow, genuinely falls short. Complexity must be purchased with demonstrated need.

Observability or chaos

Multi-agent systems live or die on observability. When a single agent misbehaves you read one transcript; when five agents collaborate, the failure is distributed across their message traffic, and without tracing — which agent said what to whom, with which tool results in hand — debugging degenerates into archaeology. Practical deployments log every handoff with request IDs, keep each agent's context reconstructable, and evaluate the system end to end rather than agent by agent, since a locally correct agent can still feed a globally wrong pipeline. The discipline is the same as any distributed system: if you cannot replay it, you cannot fix it.

Sovereignty and the self-hosted fleet

Multi-agent systems are built from the same primitives as a single agent — tool use, memory, and a loop — often wired to shared capabilities through MCP. Running the whole ensemble on your own hardware changes what the architecture means: the orchestration logic, every inter-agent message, and all the data agents touch stay under your control instead of transiting a third party's logs. That matters more, not less, as agents multiply, because the message traffic between agents is a complete transcript of your operation. An agentic workflow monitoring miners, triaging kernel logs, and drafting repair tickets is exactly the kind of system a sovereign operator can run locally end to end. D-Central documents these architectures for self-hosters: the coordination patterns are free to copy — what you are actually deciding is where the transcript lives.