Multi-Agent Systems

This cover frames the entire day with a single analogy: one agent doing everything is a generalist juggling too many jobs badly, while a team of focused agents behaves like a small company with an org chart. That contrast is the whole reason multi-agent systems exist — not to be clever, but to let each part of a hard task be handled by something narrow enough to do it well.

The goal of this post is to install one mental model before any orchestration detail: a multi-agent system is a set of specialized agents that coordinate by passing messages toward a shared goal. Everything later in the day — orchestration, code, and the failure modes — builds on that single picture.

The definition matters because 'multi-agent' is often used loosely to mean anything with more than one prompt. Pin it down: it is several LLM agents, each holding a narrow role, that coordinate by exchanging messages to finish a task no single agent handles well alone. The canonical example is a researcher that gathers facts, a writer that turns them into prose, and a critic that reviews the result.

The practical consequence is a shift in how you think about a task. Instead of asking 'how do I prompt one model to do all of this,' you ask 'what are the distinct roles this work decomposes into.' That decomposition is the design act at the heart of every multi-agent system.

This slide names the four primitives you will see in every system, no matter the framework. Agents are an LLM plus a role and tools. Roles are the narrow jobs each agent owns. Messages are the typed handoffs agents send each other. And an orchestrator decides who runs next. Hold those four and the dozen competing frameworks stop looking exotic.

Keeping these concepts distinct is what makes a system legible. When a team misbehaves you can ask: was it a bad agent prompt, a blurry role, a malformed message, or a routing mistake by the orchestrator? Each primitive is a place to look, which is exactly the kind of structure a single mega-prompt denies you.

The flow diagram shows the simplest useful team: a researcher gathers facts, passes them to a writer who drafts an answer, who passes the draft to a critic for review, ending in a polished final output. The arrows are the point — work moves in one direction, each role consuming the previous role's output.

Reading it left to right makes the decomposition concrete. No single box is trying to do everything; each owns one transformation. This linear shape is the gentlest topology, and it is where most teams should start before reaching for supervisors or peer networks introduced in the 'how' post.

This slide demystifies what an 'agent' actually is. It is not a special kind of model — it is a configured LLM. A system prompt defines its role, a set of tools defines what it can do, and its own context slice defines what it knows. Change the prompt and the tools and the very same base model becomes a researcher or a reviewer.

The insight that the role lives entirely in the prompt and tools is liberating. You are not training specialists; you are configuring one general model into many specialized stances at runtime. That is why spinning up a new role is cheap, and why role design — not model choice — is where most of your effort goes.

The comparison sets a single agent beside a multi-agent team trait by trait. The single agent runs one prompt that does everything, with roles blurring together, failures hard to localize, and context overloaded. The team gives each agent one job, clear boundaries, failures that localize to a role, and focused context per agent.

The point of laying it out this way is to show the difference is structural, not cosmetic. Each row is a real consequence of having separate reasoning loops versus one. The right column is what you trade additional coordination cost to obtain, and the rest of the day is about earning that trade deliberately.

This slide explains the core 'why' in human terms: a prompt asking a model to research, write, critique, and format simultaneously spreads attention thin and lets instructions blur into each other. Splitting those jobs gives each agent a short, sharp prompt it can actually follow — the same reason a team of focused people beats one overworked generalist.

The deeper mechanism is that LLMs follow short, single-purpose instructions far more reliably than long, multi-objective ones. Every additional competing goal in a prompt degrades adherence to all of them. Specialization is not just organizational tidiness; it directly raises the quality of each step's output.

This slide draws the line that confuses most newcomers: a single agent with many tools is not a multi-agent system. That setup is still one reasoning loop with one context — one mind with many hands. A multi-agent system has separate reasoning loops, each with its own prompt and memory, that exchange messages. The distinction is independent minds versus one mind with extra reach.

The practical implication is about isolation and independence. Separate loops can specialize, run in parallel, and review each other precisely because they do not share one context or one stream of reasoning. If everything lives in one loop, you have a tool-using agent — a perfectly good thing, but a different thing — covered back on Day 76's ReAct.

The code makes the 'role is just a prompt' idea concrete. Two dictionaries define a researcher and a writer purely through their system instructions and tool access: the researcher may use web_search and is told to find facts and never write prose; the writer has no tools and is told to turn the researcher's facts into a clear answer. The base model is identical for both.

This is the cheapest possible illustration of specialization. Notice the explicit negative instructions — 'do NOT write prose' — which keep roles from bleeding into one another. Sharp role boundaries enforced in the prompt are what make the downstream handoffs clean, a theme that returns in the mistakes post on overlapping roles.

The recap compresses the post into a model you can recall instantly. Multi-agent means many focused agents pursuing one goal. An agent is an LLM plus a role, tools, and memory. They coordinate by passing messages. An orchestrator decides who runs next. And specialization beats one overloaded prompt.

Carry this into the rest of the day. The 'why' post argues what splitting the work unlocks, the 'how' post shows orchestration and message passing, the code post hands you a runnable team, and the mistakes post shows how the same team descends into chaos without discipline.

The CTA points forward to the stakes. Knowing what a multi-agent system is matters, but the next post explains why teams reach for multiple agents — focused prompts, independent review, parallelism, and context isolation — and just as importantly, when not to.

Save this one as the conceptual anchor for the day. Every later post assumes you already hold the picture of specialized agents coordinating by messages toward a shared goal.