Designing Multi-Agent Systems

When people first build an AI system, a common instinct is to design the most capable version they can imagine from the beginning. For many, that means several cooperating agents, each with its own role, passing work to one another. The intuition is understandable: if the problem is hard, it seems that a sophisticated architecture should be the starting point.

The source argues that this instinct is a misconception. This article walks through what the source recommends instead: build something simple first, watch how it behaves on real cases, and only then decide where an agent is actually needed. Along the way you will see how each stage of that sequence feeds the next, and how the agent's job is pinned down before it is built.

The source's recommendation is tighter than simply choosing a smaller system. For the first slice of work, it says not to reach for multi-agent designs at all. The default move is to build one agent or, more likely according to the source, no agent at all, just a workflow.

A workflow is the simpler starting point because the sequence of steps is set up in advance, and the system follows that structure. A multi-agent system, by contrast, involves several agents with their own roles that hand work to one another. The workflow is easier to reason about because its path is fixed before it runs. The source also points out that building a workflow first gives you something concrete that can actually run.

Read the diagram as a column comparison. The left column describes the workflow, where the path is decided beforehand. The right column describes a multi-agent system, where several agents with separate roles coordinate. The source's advice is that the left column is where a first build should begin, because it is the design you can get running and study before adding anything more complex.

The source describes a sequence of stages rather than a single decision. First, the workflow is built. Second, it is deployed to production so its real behavior can be observed. Third, the production traces are examined. Fourth, the agent's job is specified. Only after that is an agent built. Each stage depends on the one before it: the workflow must exist before it can be observed, and the observations must exist before the agent's job can be specified.

The diagram shows the five stages as a chain, with the last arrow returning from the built agent to the observation stage. The source writes the sequence as a chain that ends in an agent. The return arrow is a reasonable reading rather than an explicit rule from the source: once an agent is running, its production traces can be examined in the same way, so the observation step can repeat. Treat the loop as a way of keeping every new agent tied to evidence from real use.

Once the workflow is live, the source says to watch the production traces. A trace is the record of how the workflow handled actual cases in production. The source relies on these records to decide where an agent should go. The key idea is that the cases the workflow handles poorly will indicate where the agent is needed. In other words, the weak spots of the workflow point toward the job the agent should take on.

This changes what a good agent proposal looks like. Instead of asking where an agent might be interesting, you ask which specific cases the workflow fails to handle and what decision would resolve them. The trace supplies the evidence for both questions.

After observation, the source says the agent has a clear job. That job is stated in three parts: a specific decision the agent makes, the specific tools it uses, and the specific human escalation path it follows. Each part narrows the agent's responsibility. The decision defines what the agent is responsible for choosing. The tools define what it can act with. The escalation path defines when a human must take over.

The concept map shows the agent job at the top with its three parts beneath it. Read each edge as a question the specification must answer. The decision answers what the agent chooses. The tools answer what it can act with. The escalation path answers when control returns to a person. A specification that leaves any one of these vague is not yet a concrete design.