Building LLM Agents: Why “Multi-Agent” Architectures Are Often a Trap

Original source: Cognition | Don’t Build Multi-Agents

Core Idea and the Author’s View

The author points out that the real-world performance of current LLM (large language model) agent frameworks has been disappointing, especially those built around architectures that promote “multi-agent” collaboration. Drawing on trial and error from their own team, they present core principles for building reliable, long-running agents and explain in detail why deceptively appealing multi-agent architectures often violate those principles, leaving systems fragile and unreliable.

I. Context Engineering Principles: The Cornerstone of Reliable Agents

The author argues that we are still exploring the possibilities of LLMs and AI agents, much as early web developers were learning HTML and CSS. “Context engineering” is central to building efficient, reliable agents. It goes a step beyond traditional “prompt engineering,” emphasizing automatically managing and supplying the precise context a model needs in a dynamic system.

Two core principles for building agents:

1. Share Context:

   • Principle: Agents need access to and an understanding of the complete “conversation history” and “decision trail,” not merely isolated messages or the current instruction. This means sharing full agent traces, rather than individual messages alone.
   • Why it matters: LLM models are intelligent, but they cannot work effectively without sufficient context. Just as humans need to understand the causes, effects, and background of a situation when carrying out a task, agents need that information to avoid misunderstanding the task or making incoherent decisions.
   • Counterexample (the fragility of dividing work among multiple agents):
     • Architecture diagram:

       

     • Example analysis: Suppose your Task is to “build a Flappy Bird clone.” The task is broken down into Subtask 1, “build the background for a moving game with green pipes and collision boxes,” and Subtask 2, “build a small bird that can move up and down.”
     • The problem: If a subagent receives only the instructions for its assigned subtask and cannot see the original, complete task description or all the decisions and considerations the main agent made while breaking down the task, misunderstandings are likely:
       • Subagent 1 might misinterpret the style of the “background” and build something that looks like Super Mario Bros.
       • The bird built by Subagent 2 might look nothing like a game asset, or its movement might work completely differently from the mechanics in Flappy Bird.
     • The result: The main agent is ultimately left with the daunting task of combining two outputs shaped by misunderstandings: a mismatched background and a bird that does not meet the requirements.
     • The underlying reason: Real-world tasks often contain layers of subtle differences. During a multi-turn conversation, an agent may need to make several tool calls to decide how to break down the task, and any of those details can profoundly affect how the subtask is interpreted. If a subagent cannot access the complete history, it is prone to drift.

2. Actions Carry Implicit Decisions:

   • Principle: Every action an agent takes contains an implicit decision based on its current context. If those decisions are based on conflicting assumptions, the final result will be poor.
   • Why it matters: An agent’s actions do more than execute instructions; they also reflect its understanding of the task and its internal “thinking” process. These implicit decisions must remain consistent.
   • Counterexample (inconsistency caused by parallel work among multiple agents):
     • Architecture diagram:

       

     • Example analysis: Even if every subagent shares the complete context—for example, they all know they are building a Flappy Bird clone—problems arise if they work in parallel and cannot see one another’s progress in real time.
       • Subagent 1, while designing the background, might choose a particular pixel-art style.
       • Subagent 2, while designing the bird, might choose a completely different cartoon style.
     • The result: You could end up with a Flappy Bird clone in which the bird and background have completely different visual styles.
     • The underlying reason: Subagent 1 and Subagent 2 base their actions on conflicting assumptions that were neither specified upfront nor shared in real time. They cannot see what the other is doing, so their work is ultimately inconsistent.

II. Theory and Best Practices for Building Long-Running Agents

The author emphasizes that these two principles are essential and almost never worth violating. When designing an agent architecture, you should therefore rule out by default any architecture that does not follow them.

1. The simplest and most reliable architecture: a single-threaded, linear agent

• Architecture diagram:

  

• Advantages: Under this architecture, the context is continuous. Every step has full access to all previous conversations, decisions, and tool-call history. This keeps the agent’s decisions coherent and greatly improves reliability.
• Limitations: This simple architecture may encounter context-window overflow when handling very large tasks. As the task progresses, the amount of information the agent must remember and pass along grows rapidly, eventually reaching the LLM model’s context-window limit.
  • Context-window overflow illustration:

    

2. An optimization: introducing a “context compression” mechanism

• Architecture diagram:

  

• Core idea: For tasks that genuinely need to run for a long time and have very large contexts, you can introduce another LLM model whose primary purpose is to compress past actions and conversations into key details, important events, and core decisions.
• Implementation challenges:
  • Correctly identifying and extracting the “key information” is extremely difficult. It requires a great deal of effort to understand which information truly matters and to design a system that can perform the task efficiently.
  • Depending on the specific application domain, you may even need to fine-tune a smaller model to handle context compression specifically (the Cognition team has already done this).
• Benefit: This approach allows agents to remain effective over a longer context.
• Limitation: Even with context compression, you will eventually reach a limit. The author encourages readers to think about better ways to manage contexts of arbitrary length, because this is a “rather deep rabbit hole.”

III. Applying the Principles in Practice: Case Studies

The author suggests that, as an agent builder, you must ensure that every action an agent takes is fully aware of the context behind all relevant decisions made elsewhere in the system. Ideally, “every action can see everything,” but context-window limits and practical trade-offs make that impossible in every case. You need to decide what level of complexity you are willing to accept based on the level of reliability you expect.

Application examples:

1. Claude Code’s subagent strategy:

   • Current behavior: As of June 2025, Anthropic’s Claude Code is an example of an agent that generates subtasks.
   • Key design: It never runs in parallel with a subtask agent. What’s more, subtask agents are usually assigned only one specific question to answer and do no coding.
   • Why: A subtask agent lacks the main agent’s complete context, which prevents it from taking on more complex work beyond answering a clearly defined question, such as writing code. If multiple subagents ran in parallel, they could produce conflicting responses and create reliability problems, just as in the Flappy Bird example above.
   • Benefit: In this case, the benefit of having a subagent is that all of its investigative work, such as looking up information, does not need to remain in the main agent’s history. This lets the main agent maintain a longer context history without exhausting its context prematurely.
   • Conclusion: The designers of Claude Code took a deliberately simplified approach to ensure reliability.

2. The evolution of the “edit application model”:

   • Common practice in 2024: At the time, many models performed poorly at editing code. Coding agents, IDEs, and app builders—including Devin—widely used an “edit application model.” The core idea was to have a large model output Markdown instructions describing code changes, such as “change the function foo to bar,” and then feed those Markdown instructions to a small model to rewrite the file. This approach was considered more reliable than asking the large model to directly produce a properly formatted diff.
   • The problem: These systems were still highly prone to errors. Small models often misunderstood the large model’s instructions because of even the slightest ambiguity, resulting in incorrect edits. For example, the large model might say, “change all calls to the function foo to bar,” but the small model might change only one of them.
   • Current best practice: Today, decision-making and the actual application of code edits are increasingly handled by a single model in a single action. This avoids the misunderstandings and ambiguity that can arise when information passes between models, thereby improving reliability.