DesignFlix 27: How Multi-Agent Planning Works

Ever wondered how an AI system handles a task that's too much for one agent?

Suppose we ask it to investigate slow checkout requests. It has logs to read, database behaviour to inspect, possible fixes to compare, and a conclusion to defend. That's quite a lot to squeeze into one conversation. We could split the investigation between several agents, but then we have another problem: getting them to work together.

That's what multi-agent planning is about. Let's follow that investigation and see what a useful AI team needs.

Agents, assemble!

Start with a job we can divide

An agent is a model working with instructions, context, and tools. It might read a log, search documentation, write a patch, or run a test. Giving it a role helps us decide which of those things it should do.

For our checkout investigation, the request needs a little more detail before anyone starts. Are all requests slow, or only some? When did it begin? What would count as a convincing explanation?

A coordinator, often called an orchestrator, turns those questions into a plan. It might ask one agent to inspect request traces, another to examine database waits, and a third to check the payment service. Those are separate paths through the same problem, so they can make progress without waiting for one another.

The coordinator also decides how the findings will come back. Otherwise we may get three long essays and still have no idea what to fix.

Give each role a useful responsibility

The original post describes six roles. Here's how they could help with this investigation:

• A researcher collects relevant logs, traces, and documentation.
• A planner decides which questions to investigate first.
• A coder prepares a diagnostic change or a proposed fix.
• A critic looks for explanations the team has overlooked.
• A verifier checks whether the evidence supports the proposed diagnosis.
• A summarizer brings the findings together for the person who asked.

We don't have to create six agents because there are six names on the list. A researcher and a verifier might be enough for a small investigation. Roles are useful when they separate work that would otherwise get muddled together.

Different roles can also use the same underlying model. The instructions, available tools, and information passed to each agent are what give it a particular job.

Make the handoff useful

Imagine the database agent reports, "The database is probably overloaded." What should the next agent do with that? It's a suspicion, but it doesn't tell us which request was slow or what the agent measured.

A small, structured finding is easier to check. For example, a hypothetical result could look like this:

{
  "request_id": "checkout-demo-17",
  "finding": "Waiting for a database connection took most of the request time",
  "evidence": { "pool_wait_ms": 820, "query_ms": 24 },
  "next_check": "Compare connection waits across other slow requests"
}

Those numbers are illustrative. What matters is the relationship: this sample spent far longer waiting for a connection than running the query. The verifier now knows what to investigate, instead of having to reconstruct the reasoning from a confident-sounding conclusion.

A useful handoff carries the finding, its evidence, and what is still uncertain. The final summary needs all three too.

Parallel work still needs an order

The log and database investigations can run together. A fix should wait for their findings, and testing the fix should wait for an implementation. If we ignore those dependencies, we get an agent solving yesterday's version of the problem while another agent changes the requirements.

This is where the coordinator earns its place. It keeps the team working on the same request and makes sure an unanswered question doesn't disappear during a handoff.

A council compares answers to the same question

You may also have heard the term LLM Council. Andrej Karpathy's project uses a particular arrangement: several models answer the same question, review and rank anonymized answers, and then a chair model combines the results.

That could help us compare proposed fixes once we have the investigation data. Each model receives the same evidence and offers a view; the chair brings those views together. It is a different arrangement from assigning one agent to logs and another to database behaviour.

The distinction matters when we build the workflow. Do we want several opinions on one decision, or several agents doing different parts of a job? Both can be useful, but they need different instructions and handoffs.

If every model agrees on a diagnosis, have we checked the system, or only checked that the models agree?

For a technical problem, we still need the traces, measurements, or test results. A unanimous vote is interesting. A reproducible explanation is something we can act on.

You call that an answer?

Keep the team small enough to follow

More agents mean more model calls, more context to pass around, and more findings to reconcile. They can also repeat the same mistake if they start with the same incomplete evidence. Anthropic discusses these coordination and evaluation challenges in its account of building a multi-agent research system.

Permissions deserve attention as well. An agent investigating a production problem can begin with read-only access. Preparing a fix doesn't need to mean deploying it, changing customer data, or granting every teammate the same tools.

I'd start with a coordinator, a focused investigator, and a verifier. Give them one real task, agree on what a good result looks like, and compare their work with a single-agent approach. Keep the extra roles when they help you find something you would otherwise miss. That's a better reason to assemble a council than the number of agents in a diagram.