The Brain Stem: "Multi-Agent" Is Four Architectures, Not One

Every team says they are building a multi-agent system. Almost none of them can tell you which of the four multi-agent architectures they picked, because they didn't pick. The demo picked for them.

If you are just picking this up, here is the whole premise in a paragraph. An agentic system is not a model with some tools bolted on. It is eleven layers, grouped into seven organ systems, and the model is one of them, arguably the least interesting one. To keep it concrete, the series walks a single ordinary event through all eleven: a senior engineer, Dana Okafor, gives two weeks' notice. Offboarding one person happens to touch every layer, which is what makes it a good way to see the whole body at once. Part 0 drew the map, and the posts since have gone organ by organ.

In Part 1 the request got in the door and the agent got a name. Now something has to decide what to actually do with Dana's resignation, break it into work, and run that work to completion without losing the thread over three days. That is the brain stem. Two layers live here, Orchestration and the Agent Runtime, and between them they answer the question the architecture diagram waves at with a single box marked "agent": how does one request become the right dozen actions, in the right order, run by the right things.

This is also where the phrase "multi-agent system" stops being a slogan and starts being an architecture with consequences. Because there is no such thing as a multi-agent system. There are at least four, they behave differently under load and under audit, and most teams are running one they never consciously chose.

The four shapes, and why the shape is the decision

Dana files her notice. Before her last day, the agent is on the hook for five streams of work:

• Revoke her access across six systems.
• Compute a forfeited equity figure out of a vendor app with no API.
• Transfer a runbook that lives in one person's head.
• Reassign fourteen CRM accounts.
• Get a final paycheck approved by a human.

Each stream is a few steps once you break it down, roughly a dozen subtasks in all, with real ordering constraints between them. Knowledge transfer has to finish before the accounts get reassigned. The paycheck cannot be issued until equity is computed. Some of it runs in parallel, some of it strictly does not.

Now the real question of this whole layer. You have a dozen subtasks and more than one agent to run them. How should those agents relate to each other?

Something has to decide who coordinates, who hands work to whom, and who holds the plan while the job is in flight. That wiring between the agents is what I mean by the shape of the system.

The shape is not cosmetic, and it is not about speed. It decides how traceable the system is. It decides how it fails. It decides whether anyone can reconstruct the run nine months later when an auditor asks. And you choose it early, then live with it, because it is very hard to rewire once the thing is running.

That is why the shape is the decision. There are four of them. Here is what each one would do with Dana.

The way Dana's offboarding actually runs is a supervisor over specialists. One coordinator owns the plan and the ordering constraints, and delegates to a handful of domain agents that each know one lane and nothing else:

• an access agent
• a payroll agent
• an equity agent
• a legal agent
• a knowledge-transfer agent

The supervisor holds the whole picture. The specialists hold their lanes. When the auditor comes asking in nine months, there is one place that knew the entire plan and can reconstruct it.

Now watch what the other three shapes would have cost.

A pipeline runs the stages in a line. Classify, then revoke access, then compute pay, then close out, each stage feeding the next. For genuinely linear work, a document that gets ingested, enriched, classified, then filed, this is the right shape. It is clean, and you can always see where a run is. It is just wrong for this job.

Offboarding is not linear. Access revocation and knowledge transfer should run at the same time, not one after the other. And the moment a stage has to wait on a human, like the paycheck approval, the whole line stops behind it.

A pipeline also cannot handle exceptions. Say the termination is involuntary, or Dana is on a visa, or she is under a litigation hold. Each of those reorders or halts the work, and a straight line has nowhere to put that fork.

A swarm is the fashionable one. Peer agents work as equals, with no central coordinator. Each one grabs a task and hands off to whichever peer should go next. It is fast, it is parallel, and it demos beautifully, because that kind of self-organizing looks a lot like intelligence. For open-ended work with no fixed plan to protect, mapping a research question, fanning out a wide search, a swarm is genuinely the right tool.

Dana's offboarding is the opposite of open-ended. It is an ordered process, and it gets audited. Here is what a swarm costs you there. No single agent ever holds the whole plan. So when the auditor asks whether Dana's production database access was revoked on her last day, there is nobody to ask. You are left piecing the answer together from peers that never shared a plan, and "we think so" is where that sentence ends.

A swarm gives you very high parallelism and very low traceability. The first is visible in the demo. The second is invisible until the first audit, and then it is the only thing anyone can see.

The fourth shape is a full hierarchy: supervisors managing other supervisors, who manage the specialists. That is the right answer for a thousand-task migration or a company-wide reorg. For Dana's dozen subtasks, it is pure overhead. Every tier you add is one more handoff to get wrong and one more layer of delay, for no gain. You would be paying an org-chart tax to offboard one engineer.

None of these four shapes is wrong in the abstract. Each is the best choice for some job. Pipelines are right for linear work, swarms for open-ended exploration, hierarchies for massive decompositions, and a supervisor for an ordered, audited process like this one. The mistake is never picking a bad shape. It is picking a good shape for the wrong problem. For Dana, only the supervisor fits, and the other three fail in ways a two-week demo will never show you, because a demo runs the happy path, and every one of these shapes runs the happy path fine.

The uncomfortable part is that most teams did not choose the supervisor pattern on purpose. They started with one agent, it got overloaded, they bolted a second one next to it, then a third, and whatever coordination emerged from that accretion is now their architecture. The topology is a decision about traceability and blast radius. If you let it happen instead of making it, you optimized for the demo and inherited the audit problem.

Classify, route, plan, orchestrate are four jobs, not one prompt

Zoom inside the supervisor. Before any specialist runs, four decisions have already been made, and this is the part teams most reliably compress into a single mega-prompt that says, roughly, "you are an offboarding agent, handle the resignation."

Pull those four decisions apart, because they are four different jobs wearing one label.

Classification. What kind of request is this? Voluntary or involuntary. Regretted or not. US-based or on a visa. Legal hold or clear. Four months short of a vesting cliff or not. This is a judgment that changes everything downstream, and it is the single highest-leverage decision in the whole run. Get the litigation hold wrong here and the agent will confidently delete things it was legally required to preserve.

Routing. Given the classification, which path handles it, and which model? The routine 90 percent goes to a cheap fast model. The vesting-cliff edge case goes to a frontier model because the cost of a wrong equity number dwarfs the cost of the tokens. Routing is where that choice lives.

Planning. What are the actual subtasks, and in what order, under what constraints? Knowledge transfer before reassignment. Equity before paycheck. Reversible actions can run early; irreversible ones wait for a gate.

Orchestration. Run the plan. Handle the specialist that fails at 3:40 am. Decide when the whole thing is done, and when it should stop and hand a decision to a human.

Now the point. Collapsing those four into one prompt does something worse than make the system hard to read. It removes every place you could have attached a control.

Classify, route, plan, orchestrate. Those are four decisions, and each one is a place you can put a guardrail, a metric, or a test. A single prompt is none of those places.

You want a hard guardrail that says: if classification returns "litigation hold," stop before planning and escalate. In a four-stage design that rule has an obvious home, between the classifier and the planner. In a single prompt there is no "between." There is one opaque call, and you are reduced to begging it in the system message to please remember the legal hold, and hoping.

It shows up again the day something goes wrong. The classifier that mislabels a litigation hold and the planner that orders revocation before knowledge transfer are two completely different failures with two completely different fixes. Inside one prompt, both surface as the same vague symptom, "the agent did the wrong thing with Dana," and you cannot tell which decision broke, so you tune the prompt, redeploy, and wait to find out whether you fixed anything. Four seams give you four places to test, measure, and correct. A prompt gives you one place to guess.

The runtime is the part that actually ships the work

The second layer of the brain stem is the Agent Runtime, and it is the most underrated layer in the entire anatomy. It is everything wrapped around the model:

• The specialists that do the actual work.
• The skills system they draw on.
• The context budget that decides what each one is allowed to see.
• The meta-harness: the loop that retries, checkpoints, enforces the plan, and holds the rules the model is not allowed to break.

The last two are where the reliability actually comes from.

Start with context budget, because it is where both cost and reliability quietly live. The access specialist does not need Dana's vesting schedule. The equity specialist does not need her GitHub team memberships. Deciding what goes into each agent's window, and what is deliberately kept out, is a runtime decision, and it is not housekeeping. Every irrelevant token you load is money spent and attention diluted, and an agent drowning in context it does not need is measurably worse at the job than one handed exactly what the task requires. Scoping context is how you keep a specialist sharp and cheap at the same time.

Then the meta-harness, and the claim the whole series keeps returning to: the harness matters more than the model.

Swap a better model into a bad harness and you get a more articulate failure. The harness is what ships the work. The model just does the talking.

I mean this literally. The model decides what to do about Dana. The harness is what makes it actually do that, reliably, a dozen times, across three days. The harness survives the provider outage at 3:40 am. It checkpoints, so a crash costs two minutes instead of the whole run. It refuses to issue the paycheck without the human gate. It stops when the work is done, not when the tokens run out.

Upgrade the model underneath a weak harness and the offboarding still loses the thread on day two, just with better prose. Keep a modest model inside a strong harness and it still ships, because the harness is what enforces the plan, the stop conditions, and the write-back discipline. I have argued this at length elsewhere, in why your agent forgets the rules and in you're not writing prompts anymore, you're writing loops, because it is the single most expensive thing enterprises get backwards. They shop for models. The model is the commodity. The harness is the product.

Three questions for your own brain stem

You are running a multi-agent system, or funding one. Three questions tell you whether its brain stem holds.

Which of the four topologies are you running, and did you choose it? If the honest answer is "I'm not sure, it grew that way," you are almost certainly in an accidental swarm, and you will find out at the first audit. Name your topology on purpose, and be able to say why the other three were wrong for your workload.

Where in your pipeline could you attach a guardrail between two decisions? If the answer is "nowhere, it's one prompt," you have no control surface. Classification, routing, planning, and orchestration should be four seams you can inspect, meter, and gate independently. If they are welded together, so are your failures.

If you swapped in a smarter model tomorrow, what would actually improve? If the answer is "the whole thing would finally be reliable," you have misdiagnosed the problem. Reliability lives in the harness, not the model. A better model makes a good harness better and a bad harness eloquent.

Most teams answer none of the three cleanly, and again, that is not a failure of skill. It is the failure of a diagram that drew one box marked "agent" and hid four architectural decisions inside it.

What the brain stem decides

The front door gave the agent a name. The brain stem gives it a shape, a set of seams, and a harness that holds the work together long enough to finish. Everything downstream, the tools it reaches for, the memory it draws on, the moment it stops and asks a human, runs inside the structure this layer sets. Choose the structure by accident and every clever thing further down is happening inside an architecture nobody can explain.

The model will keep getting better at deciding what to do about Dana. It will not choose your topology for you, it will not put the seams where your auditor needs them, and it will not build the harness that makes the work survive three days and one outage. That is the brain stem's job, and it is yours to design.

Next: The Bloodstream. The model is a commodity behind a gateway. The tools are where the risk lives, and a browser driving a twenty-year-old equity app is about to prove it.

Matthew Kruczek is Managing Director at EY, leading Microsoft domain initiatives within Digital Engineering. Connect with Matthew on LinkedIn to discuss the orchestration layer underneath your agent program.

References

1. Anthropic. "Building Effective Agents." December 2024.
2. Gartner. "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027." June 25, 2025.
3. Matthew Kruczek. "Why Your Agent Forgets the Rules." matthewkruczek.ai, 2026.
4. Matthew Kruczek. "You're Not Writing Prompts Anymore. You're Writing Loops." matthewkruczek.ai, 2026.
5. Matthew Kruczek. "Multi-Agent Patterns in Practice." matthewkruczek.ai, 2026.