7 min read
"Agent" is the word making the most noise in the AI market this year. A call to a model from a script, a chatbot with memory, three chained prompts or an autonomous system with database access all get labelled as "agents" depending on who tells the story. Having a useful operational definition allows distinguishing when this type of architecture is needed and when a linear prompt flow is sufficient.
What distinguishes an agent from a prompt
A prompt is an instruction. The model receives it and generates a response. There is no state maintained between calls, no execution of anything beyond text generation. An agent, by contrast, has two concrete properties that a prompt does not: autonomy over sub-decisions within its scope (within the assigned role, it decides how to complete the task) and accountability for the result it produces (its output can be evaluated, accepted or rejected, and there is an explicit mechanism to do so).
A practical example. A flow that asks a model to summarise a document is a prompt. An agent tasked with synthesising a report has a broader role: it decides which documents are relevant and in what order to address them, when it has gathered sufficient information, and what to present at the end. Another agent can review that report with its own criteria, flag what does not meet them and return the draft for adjustment.
The underlying model can be the same in both cases. What changes is how the work was decomposed and what responsibilities were assigned to each part. A small model with a well-defined role and a clear evaluation mechanism can behave as a useful agent; a large model asked to do everything in a single prompt may not.
When does it make sense to use more than one agent?
Multi-agent is an architecture with a specific cost — more than an automatic improvement over a single agent: more latency, more pieces to coordinate, more surface where something can go wrong. That cost is justified when the work has phases with mutually contradictory success criteria.
Writing and critiquing are contradictory criteria. A model that writes is optimising to generate content coherent with the received instruction. A model that critiques is optimising to find problems in an already-written text. Asking the same model to do both sequentially produces text that tends to approve itself, because the critique criterion ends up aligning with the recent writing criterion.
An agent that researches a topic and an agent that decides whether the research is sufficient have a similar tension. The first tends to keep searching for information. The second tends to close before wasting too much time. The tension between the two produces a decision neither would take alone — to use the available information when it is sufficient, not when it is exhaustive.
When the work does not have this kind of internal tension, adding agents adds no quality. A pipeline where each agent passes its output to the next without contradictory criteria is a more complex system with the same results as a well-designed single agent.
When does it not make sense?
There are three situations where someone builds multi-agent and ends up with a worse system than the simplest alternative.
The first is when the process can already be described as a deterministic sequence. If the flow is "extract a field, validate the format, save to database, send a notification", that is a rules pipeline. Putting an agent into each step makes it slower and less predictable without adding anything to the quality of the result.
The second is when the decomposition into agents is artificial. Sometimes tasks are separated that a model can resolve in a single pass, in order to make the system have more pieces and appear more sophisticated. The typical result is a main agent that does the real work and several accessory agents whose effective function is neither clear nor measurable. The system assumes all the complexity of coordinating multiple agents without obtaining any of the advantages that coordination was supposed to bring.
The third is when the problem requires low latency. Multi-agent introduces coordination, and coordination costs time. An assistant responding in real time in a conversational interface generally needs to be a single agent; coordination between several makes the response too slow for that use case.
How multi-agent systems fail
The failure patterns of multi-agent are different from those of a single model, and they must be anticipated in the design before they appear in production.
The first is error accumulation. One agent passes slightly wrong data to the next; the next builds on that data, adding its own noise. After several steps, the system's output bears no resemblance to any original intent. Detecting where the problem started is possible. Even though each agent did something reasonable with what it received, and errors are less visible at first glance, the task separation allows us to see what each agent did and trace the origin of the error.
The second is the absence of human checkpoints at the point of highest uncertainty. A multi-agent system can process hundreds of cases without anyone seeing samples of what it is producing. Without an explicit mechanism that brings the output to human review at the critical point, errors accumulate and are discovered weeks later, in batch.
The third is the illusion of decomposition. Sometimes the separation into agents is cosmetic. All agents are making decisions so correlated with each other that they collapse into a single distributed agent. The system assumes the cost of coordinating multiple agents — with the latency and operational complexity that implies — without there being any real diversity of criteria to justify that architecture.
Anticipating these patterns changes the design from the start. Building systems with agent architectures requires defining the success criterion of each agent, where the human checkpoints are and what condition sends a case to review. Without that prior definition, the system works in the controlled scenario of development and fails when it enters production with real cases.
The three questions before starting
Before deciding that a project needs multi-agent architecture, it is worth answering three questions.
The first is whether the work decomposes into phases with different and potentially contradictory success criteria. If so, multi-agent may contribute something real. If the work is a linear sequence where each step builds on the previous without tension between criteria, a well-designed single agent will be simpler and more reliable.
The second is about latency. If the system must respond in real time, multi-agent is rarely the right answer. If the system processes asynchronously, quality may justify the additional coordination time.
The third is about validation: where will the human be and what samples will they review, how often and at what point in the flow. A multi-agent system without this designed from the start does not fail on day one. It fails two months later, when someone asks why this week's result does not look like last week's and the team has no explanation they can articulate.
"Agent" will keep being the buzzword. The useful design work starts before choosing the architecture: verifying there is real tension between criteria, that latency allows it and that the human flow is defined. Without that prior work, the system becomes a demo that works in controlled conditions and fails when it enters production with real cases.