Multi-Agent Systems

This cover deflates the mystique. A multi-agent system can look like a swarm of intelligences, but mechanically it is three concrete things: an orchestration topology, a message protocol, and a memory model. Seeing it that plainly is what lets you build and debug a team with confidence instead of treating it as emergent magic.

The post walks the machinery in order: the common topologies, how messages route between agents, how state is shared or scoped, and how the system knows when to stop. By the end the 'swarm' should feel like disciplined plumbing — fully understood and fully controllable.

The topology is the wiring of the system and the first decision you make. In a supervisor pattern, one orchestrator agent delegates tasks to workers and collects their results — control is centralized. In a network pattern, peer agents pass work directly to whichever peer is best suited next — control is distributed. The shape you choose determines how both control and information flow.

The practical guidance is to start with a supervisor. Centralized control is far easier to reason about, log, and debug because every decision passes through one place. Peer networks are more flexible and sometimes more natural for collaborative tasks, but they trade that flexibility for harder debugging, which the next slide makes explicit.

The comparison puts the two topologies side by side. The supervisor has one agent delegating, workers reporting back, central control, and is easy to reason about. The network has peers handing off directly, no single boss, flexible routing, and is harder to debug. Neither is universally right; they suit different problems.

The honest takeaway is to default to a supervisor unless you have a specific reason not to. Centralized routing gives you one place to inspect every decision, which is worth a great deal when something goes wrong. Reach for a peer network only when the task is genuinely collaborative in a way that a hub-and-spoke shape would distort.

This slide insists that agents communicate through structured messages, not free text. Each handoff carries who sent it, the role, the content, and often a task or result field. Structure is not bureaucracy — it is what lets the orchestrator route messages correctly and lets you log every exchange for later debugging.

The payoff is twofold. Routing becomes deterministic because the orchestrator reads fields rather than parsing prose. And observability becomes possible because every message is a structured record you can store, replay, and inspect. Free-text handoffs, by contrast, are exactly where teams silently corrupt their own state, a failure the mistakes post returns to.

Something has to decide who speaks next, and that routing logic is the control plane of the entire system. A supervisor agent reads the current state and chooses the next worker; a simpler system follows a fixed sequence; a router uses explicit rules or an LLM call to pick. Whatever the mechanism, this decision is where the system's behavior is really determined.

Understanding routing as the control plane reframes debugging. When a team behaves oddly, the question is usually not 'is an agent broken' but 'is the routing sending work to the wrong place.' Centralizing and logging that decision — as the supervisor pattern does — is what makes the system's behavior legible and fixable.

The cycle diagram traces a supervisor's delegation loop: the supervisor reads the current state, decides which worker to delegate to, the worker runs and returns a result, the state is updated, and control returns to the supervisor. Reading it as a cycle makes clear that the supervisor is consulted on every iteration, not just once.

This repeated-consultation structure is what gives the supervisor pattern its control and its debuggability. Because every turn passes back through one decision point, you can log each delegation and each result, and you can reason about the whole run as a sequence of supervisor decisions. It is also where the termination check naturally lives, as the next slide develops.

This slide addresses memory, a design choice that is easy to get wrong. Agents need to share some state but not all of it. A shared scratchpad holds the running task and the results everyone needs to see; scoped memory keeps each agent's private working notes out of the others' contexts. Deciding what is shared versus private is core to keeping the system both coordinated and efficient.

The tension is real. Share too little and agents make decisions blind to each other's work; share too much and you recreate the context-bloat problem multi-agent design was meant to avoid, while ballooning cost. The skill is identifying the minimal shared state that keeps the team coordinated, and scoping everything else to the agent that needs it.

Termination is the safety-critical mechanic newcomers most often skip. A multi-agent loop must know when to stop — whether a final answer has been reached, a max-turns cap has been hit, or the supervisor explicitly declares the task done. Without an explicit stop rule, agents can ping-pong tasks indefinitely, each politely deferring to the other, burning tokens with nothing to show.

Robust systems pair a clear 'done' signal with a hard turn cap and ideally a wall-clock timeout, then fail gracefully when the cap trips. Treat termination as a fuse you install before the team ever runs. The mistakes post elevates 'no termination rule' to the single most common production failure in multi-agent systems.

The trace diagram makes a structured message concrete by showing one delegation end to end: a message from the supervisor to the researcher carrying the task 'find 2024 EV sales,' the researcher running web_search, a result of '13.6M units,' and that result routed back to the supervisor. Each line is a field you could log and inspect.

Reading it top to bottom is reading the system's communication in miniature. Notice that nothing is free text floating between agents — every hop has a sender, a recipient, and a typed payload. That structure is precisely what turns an opaque 'the agents talked to each other' into an auditable record you can debug.

The supervisor-loop code shows how little glue real orchestration requires. It seeds a state object with the task and empty history, then loops up to max_turns. Each iteration calls the supervisor to get a decision about who runs next and why; if the decision is 'finish' it returns the answer, otherwise it delegates to the named worker, runs it, and appends the result to the history.

Two design choices carry real weight. The supervisor returning a structured decision — including which worker and an explicit finish action — is what makes routing and termination clean and inspectable. And the max_turns bound on the for-loop is the infinite-loop fuse made literal. This compact function is a complete, honest orchestrator you fully own.

The recap distills the mechanics to five lines you can hold in your head. Choose a topology, supervisor or network. Pass structured messages, not free text. Have an orchestrator decide whose turn it is. Split memory into shared versus scoped. And always set a termination rule plus a turn cap.

These five points are the operational checklist for any multi-agent implementation. If you can recite them, you can read any framework's source and recognize the same skeleton, and you can build your own orchestration from scratch when a framework gets in your way or hides too much.

The CTA moves from mechanics to a working build. You now understand topologies, structured messages, routing, memory scoping, and termination. The next post assembles all of it into a complete, runnable multi-agent system you can paste and point at your own roles and tools.

Save this post as the reference you return to when a team stalls, loops, or routes work to the wrong agent, and you need to remember which mechanic — topology, message, routing, memory, or termination — is the one that broke.