What is Decorative Multi-Agent?
Decorative Multi-Agent is an AI code smell, a sign of trouble in LLM systems, in the Dispensables group. Five agents with job titles passing text to each other without splitting any real work.
An agency built a virtual team to produce market reports. Five agents. A senior researcher, a data analyst, a writer, a reviewer, and an editor in chief.
Look at the configuration. Only the researcher has a tool, web search.
All the others have none. And the flow is always the same sequence.
The trace shows what happens. The researcher runs the searches, and writes a summary. The analyst rewrites the summary in other words. The writer turns it into a report. The reviewer changes a few sentences. And the editor replies: approved. Five large calls, each rereading the previous one's text. A single agent, with the search tool, delivers the same report. In this lesson, you'll learn to tell decoration from real division of work.
Here's the shape. The only agent with a tool does the real work.
The others read the whole text, and return a similar version.
And the result costs five times as much, and takes five times as long.
How do you spot it? The agents have human job titles, like researcher, analyst or manager, instead of technical responsibilities.
Only one or two agents have tools. The others only read, and rewrite.
The flow is always the same sequence, with no decision about who works.
Each agent receives the previous one's entire text, and returns a similar text.
And removing an agent doesn't change quality in the eval. While the cost is several times that of one call.
The honest way to see this smell is to drop an agent, and measure. Say the agency's eval has forty reports, and a rubric. Claims with sources, numbers that match the page, the agreed structure.
You turn off the reviewer and the editor in chief. The score doesn't move.
You turn off the analyst. The writer works straight from the researcher's summary, and the score stays the same.
One agent that researches and writes is left. The other four were job titles.
And if the score drops when you remove someone, that split is paying for something. Then you name the technical reason, and keep only that.
Here's one for you. You turn off the reviewer and the editor in chief, on an eval of forty reports. The rubric score doesn't change. What's the most useful diagnosis?
Those two roles are decorative. They reread and rewrite, without doing any new work. Collapsing them is the next step. Not reinforcing the job title.
A bigger model on the reviewer, with no criterion of its own, only makes the rewrite more expensive. And adding a sixth agent, an auditor, to catch what the reviewer misses, would be the same smell, with a new badge.
The metaphor is appealing. A team of agents is easy to explain, and looks good in a presentation. A loop with two tools and a rubric in code, much less so.
Frameworks encourage it. Many tutorials open with roles and goals written in HR language. You copy the example, swap the names, and in an afternoon you have five agents running. The demo talks. The cost shows up next month.
Splitting by human role, not by context. In a company, splitting by role makes sense, because people have memory, hours and a specialty. For a model, the reasons to split are different. The context window, tool permissions, review that mustn't see the maker's reasoning, and work that can run in parallel.
And no eval. Without measuring, nobody notices that three of the five agents change nothing. The reviewer improved the tone is a feeling. The rubric says whether it improved what matters.
The cost. Each agent rereads the previous work, so cost grows with the number of roles, not with the value delivered. With illustrative numbers, the first call starts at three thousand tokens of input. Each later role receives the previous one's entire text. Five, seven, nine, eleven thousand. You pay for the same text several times, and what the extra buys is four rewrites. Prompt caching makes the repeated start cheaper. It doesn't erase the four extra calls.
And latency adds up too, because the roles run in a queue. Quality can get worse, like a game of telephone. A correct number in the researcher's summary becomes a different number in the writer's text. And when the report comes out wrong, there are five prompts to investigate, and nobody knows at which pass the fact changed.
The treatment is a refactoring called collapse agents. Merge the agents that only pass text along into one agent, with the right tools. And keep separate only what has a technical reason. Those reasons do exist.
Context isolation. Whoever reads forty pages shouldn't write the report in that same context.
Restricted tools. Whoever summarizes a lead's website shouldn't hold the send email tool.
Independent review. Whoever scores doesn't see the writer's reasoning, and the eval shows a gain.
And parallelism, like twenty different repositories explored in twenty separate contexts.
Quick check. The eval shows that merging the page reader with the writer hurts the rubric. The context fills up with web pages, and the report loses its sources. The team still wants the five job titles from the slide deck. What's the most useful next step? Keep only the measured split, the reader and the writer, and collapse the rest. The eval proved one technical reason between two roles. Context isolation. Not five job titles.
And the classic trap, for someone starting out. Adding a reviewer, because a human team always has one. With no rubric and no eval, that reviewer learns to say approved. You paid for a stamp. And if the sequence of steps is always fixed, search, then write, then format, you may not need an agent at all. A chain, with code in the middle, does it, and each step has a contract.
Four quick cases. A pipeline with one agent that researches, and a second that writes from the sources, with no tools. And the eval shows that merging them hurts quality. Not this smell. The split has a measured technical reason.
Three agents debate in rounds. The optimist, the pessimist and the moderator. No criterion, no eval, and the final answer is usually the moderator's first one. That is this smell. A debate is only justified with a judge, a written criterion, and an eval showing improvement.
A main agent sends twenty subagents to explore twenty different repositories in parallel, and gets a one page summary from each. Not this smell. That's real, independent work, in separate contexts.
And after collapsing, you add an evaluator with a written rubric, that only sees the final report, and the score goes up. Not this smell either. That's independent review, with a measured gain.
So here's the idea to take with you. A model doesn't need an org chart. It needs the right tools and a clean context. Drop each agent and measure. Keep only the splits that move the score, name their technical reason, and collapse the rest into one agent that does the work.
In the next lesson, we'll do that collapse step by step: collapse agents. See you there.
Multi-Agente Decorativo
Decorative Multi-Agent is an AI code smell, a sign of trouble in LLM systems, in the Dispensables group. Five agents with job titles passing text to each other without splitting any real work.
An agency built a “virtual team” to produce market reports. The configuration (anonymized):
agents:
- role: Senior Researcher
goal: Find relevant information on the topic
tools: [web_search]
- role: Data Analyst
goal: Analyze the researcher's information
tools: []
- role: Writer
goal: Write the report based on the analysis
tools: []
- role: Reviewer
goal: Review and improve the writer's text
tools: []
- role: Editor-in-Chief
goal: Approve the final version
tools: []
flow: sequential
The trace shows what happens: the researcher runs the searches and writes a summary. The analyst rewrites the summary in other words. The writer turns it into a report. The reviewer changes a few sentences. The editor replies “approved”. Five large calls, each rereading the previous one’s text. A single agent with the search tool delivers the same report.
The honest way to see the smell is to drop an agent and measure. Imagine the agency’s eval has 40 reports and a rubric: claims with sources, numbers that match the page, agreed structure. You turn off the Reviewer and the Editor-in-Chief. The score does not move. You turn off the Analyst: the Writer works from the Researcher’s summary, and the score stays the same. One agent that researches and writes is left. The other four were job titles.
If the score drops when you remove someone, that split is paying for something. Then you name the technical reason (context isolation, blind review, parallelism) and keep only that.
Signs of Decorative Multi-Agent:
flowchart LR
P(["1. Researcher"]):::llm --> A(["2. Analyst"]):::llm
A --> R(["3. Writer"]):::llm
R --> V(["4. Reviewer"]):::llm
V --> E(["5. Editor"]):::llm
E --> OUT(["6. Nearly the same text"]):::io
Anthropic’s “Building effective agents” guide (Dec. 2024) recommends starting with the simplest design that solves the task, usually one model with tools, and adding orchestration only when the measurement shows a need. Multi-agent is not the starting point.
The numbers below are illustrative. Suppose a report of 2,000 output tokens and a context that starts at 3,000 tokens (system prompt plus the request). Each later role receives the previous one’s entire text.
| Design | Calls | Input tokens (approx.) | What the extra buys |
|---|---|---|---|
| One agent with search | 1, plus the tools | 3,000 plus the results | The work |
| Five roles in a queue | 5, plus the same tools | about 3,000 + 5,000 + 7,000 + 9,000 + 11,000 | Four rewrites |
The queue pays for the text several times. If search already cost something, you pay again for each title to reread the same summary. Prompt cache cheapens the repeated prefix; it does not erase the four extra calls or the serial latency.
| Refactoring | Choose it when |
|---|---|
| Collapse Agents | The agents only pass text along. Merge them into one agent with the right tools, and keep separate only what has a technical reason. Targets: ReAct Loop and Tool Use. |
Technical reasons to separate do exist. Context isolation: whoever reads 40 pages should not write the report in the same context. Restricted tools: whoever summarizes the lead’s site should not hold send_email. Independent review: whoever scores does not see the writer’s reasoning, and the eval shows a gain. Parallelism: twenty different repositories, twenty contexts. See Extract Subagent for those cases.
| Split | Reason | Keep it? |
|---|---|---|
| Researcher, analyst, writer, reviewer, editor in a queue | Job titles from a human newsroom | No, until ablation shows a gain |
| One agent researches and writes | The task fits in one context | Yes, start here |
| Page reader separate from writer | A window full of HTML hurts the writing | Yes, if the eval confirms it |
| Evaluator with a rubric, without the internal draft | Measured blind review | Yes, that is Evaluator-Optimizer |
| Subagents in parallel on distinct sources | Independent work | Yes, that is Subagent Delegation |
The classic trap for someone starting out: adding a Reviewer because “a human team always has one”. With no rubric and no eval, that reviewer learns to say “approved”. You paid for a stamp.
If the sequence of steps is fixed (search, then write, then format), you may not need an agent at all: a chain with code in the middle will do, and each step has a contract. The neighboring smell is Agent Where a Chain Would Do.
None of those cases asks for five job titles in a queue rewriting the same paragraph.
Answer the 6 questions to complete this lesson. Watching alone does not complete it: the check is what counts toward the trail and the certificate.
Decorative Multi-Agent is an AI code smell, a sign of trouble in LLM systems, in the Dispensables group. Five agents with job titles passing text to each other without splitting any real work.
With Collapse Agents. Each refactoring has safe step-by-step mechanics with an eval before and after.
In the real-world scenarios Deep research with citations.