2025 is referred to as the year of Agents, with many capable manufacturers launching AI Agents. However, reality often contradicts expectations: seemingly intelligent models frequently crash, producing absurd outputs, resembling “artificial stupidity.” Where does the problem lie? Is it the model’s capabilities? Or is the framework not advanced enough?
Online, I came across an article at https://cognition.ai/blog/dont-build-multi-agents, which discusses the underlying logic of framework design, delving into the pitfalls that are easy to fall into when constructing AI agents, and proposes a more reliable and future-oriented paradigm: Context-Driven Serial Agents + Hierarchical Collaboration Model.
Reliable Multi-Agent Paradigm for 2025: Serial Workflow
Have you ever enthusiastically built an LLM agent, hoping it could autonomously complete complex tasks like in science fiction movies? Yet, the reality is that seemingly intelligent models result in fragile agents that make numerous errors, acting like “artificial stupidity.”
What is the root of the problem? The model itself? Not necessarily. Often, the issue lies in the “foundation” we build it upon—the agent framework. The development status of frameworks for large language model (LLM) agents has surprisingly stagnated. Today, I want to propose some core principles for building agents based on our countless trial-and-error experiences and explain why some seemingly attractive ideas turn out to be “giant pitfalls” in practice.
🚧 Why Discuss “Principles” First Instead of Jumping Straight to the “Framework”?
HTML was introduced in 1993. In 2013, Facebook launched React to the world. Now, in 2025, why does React (and its derivatives) dominate front-end development? Because React is not just a framework; it is a philosophy. It encourages you to build applications in a responsive and modular way—something that seems obvious today but was a valuable insight discovered by developers in the early days.
In the era of LLM agents, we feel like we are still fumbling with raw HTML and CSS, stumbling to find best practices. Aside from some basic concepts, the industry has yet to establish standards.
Worse still, in some cases, libraries like OpenAI’s
<span>swarm</span>and Microsoft’s<span>autogen</span>actively promote what we consider to be incorrect paradigms for building agents. Specifically, they misuse the architecture of multi-agent parallel collaboration, which I will explain in detail later.
Indeed, there are many introductory resources on how to build basic agents available on the market. However, when you actually want to construct a serious production-level application, the challenges are just beginning.
The Theory of Building Reliable Long-Term Agents
Let’s start with a fundamental yet critical issue: reliability.
When an agent needs to run for an extended period while maintaining contextual coherence, the risk of compounded errors can snowball. If not controlled, the entire system can quickly collapse. The core of ensuring reliability is what we call—Context Engineering.
What is Context Engineering?
By 2025, the large models we possess will be extremely intelligent. However, even the smartest person in the world cannot work effectively without understanding the context of the task. “Prompt Engineering” is aimed at better issuing single commands to LLMs. In contrast, “Context Engineering” systematically and automatically manages and conveys all relevant information in a dynamic, long-term task. This is the primary battlefield for engineers building AI agents.
Let’s look at a widely circulated yet extremely fragile agent architecture:
- 1. A main agent breaks down the task into multiple parts.
- 2. It launches multiple sub-agents to process these parts in parallel.
- 3. Finally, the main agent combines the results.
Subtask 1
Subtask 2
Result 1
Result 2
Task
Agent breaks down task
Subagent 1
Subagent 2
Agent combines the results
Result
The allure of this architecture lies in its “parallelism,” which sounds highly efficient. However, it has a fatal flaw.
A Painful Example: “Flappy Bird”
Suppose the task is to “create a clone of Flappy Bird.” A common parallel architecture would proceed as follows:
- 1. Main Agent breaks down the task.
- 2. Subagent A creates the background with green pipes in parallel.
- 3. Subagent B creates the flying bird in parallel.
Subtask A
Subtask B
Result A
Result B
Task: Flappy Bird
Agent breaks down task
Subagent A: Create Background
Subagent B: Create Bird
Agent combines the results
Disaster!
The task is to “create a clone of Flappy Bird.” The main agent breaks it down into Subtask 1 “create a background with green pipes and collision boxes” and Subtask 2 “create a bird that can fly up and down.”
What are the results? Subagent 1 might completely miss the game’s style and create a background in the style of “Super Mario.” Subagent 2 might create a bird, but its design is entirely mismatched, and its flying mechanics differ greatly from the original. Now, the main agent faces these two unrelated outputs, helplessly trying to “stitch” them together.
This is not alarmist. Real-world tasks are filled with subtle details, and any slight information gap can lead to catastrophic outcomes. You might say, why not send the original task to the sub-agents? But in real production systems, dialogues are multi-turn, and there may be tool calls interspersed; any minor deviation in any link can affect the final understanding.
To enable a group of “smart individuals” (sub-agents) to collaborate efficiently, what is the first principle? It is not to issue them independent commands, but to ensure they all refer to the same complete meeting minutes.
Principle 1: Share context, and share the complete agent history, not just a single command.
Now, let’s improve the architecture following Principle 1, ensuring that each subsequent unit can see all previous information.
✅ Improvement Idea: Shared Context + Serial Execution
Subtask 1
Subtask 2
Result 1
Result 2
Task
Agent breaks down task 🟩 Conversation & actions so far
Subagent 1 🟦 Subtask 1 work
Subagent 2 🟩🟦 Subtask 2 work
Agent combines the results 🟩🟦🟪 Combining work
Result
Unfortunately, we still haven’t completely escaped the predicament. This time, both sub-agents know that the final goal is “Flappy Bird,” but they remain “blind” to each other. Subagent 1 and Subagent 2 cannot see what the other is doing, leading to inconsistent outputs—one might adopt a retro pixel style, while the other opts for a 3D realistic style.
This is akin to musicians in a band wearing noise-canceling headphones; although they all look at the same score, they cannot hear each other’s performances, resulting in a cacophony. Subagent 1’s choice of pixel art implies an implicit decision that “the overall game is in retro pixel style.” Since this decision is not perceived by the other agents, conflicts arise.
Principle 2: Actions contain implicit decisions, and conflicting implicit decisions inevitably lead to disaster.
I believe these two principles are crucial and should not be violated. Therefore, any agent architecture that contradicts these two principles should be excluded by default.
Since the parallel path is so fraught with challenges, let’s return to basics and consider the simplest, most reliable method:
✅ The Most Reliable Paradigm: Linear Serial Agents
Simple & Reliable
Task
Agent breaks down task
Agent does subtask 1
Agent does subtask 2
Agent combines the results
Result
✅ Conversation & actions so far
✅✅ Subtask 1 work
✅✅✅ Subtask 2 work
✅✅✅🟪 Combining work
C1,C2,C3,C4
Each step can fully inherit the previous context and decisions, the simplest and most reliable.
Here, the context flows perfectly and continuously. However, its drawback is also evident: for extremely long tasks, the context window will eventually fill up, leading to information loss.
🧠 But Serial Also Has Limits: Context Window Overflow
but struggles with longer tasks ...
Task
Agent breaks down task
✅ Conversation & actions so far
Agent does subtask 1
✅✅ Subtask 1 work
Agent does subtask 2
✅✅✅ Subtask 2 work
Agent does subtask 3
✅✅✅... Subtask 3 work context overflow
...
The biggest problem with serial agents is—as the task duration increases, the context window will eventually burst.
Honestly, a simple linear architecture can solve 80% of the problems. However, if you pursue perfection and want to handle truly complex long-term tasks, we can introduce an advanced technique: Context Compression.
🧰 Advanced Technique: Context Compression
🟧 Key moments & decisions
🟧 Key moments & decisions
🟧 Key moments & decisions
🟧 Key moments & decisions
🟩 Conversation & actions so far
🟦 Subtask work
🟪 Combining work
🟧 Key moments & decisions
Task
Agent breaks down task 🟩 Conversation & actions so far
Agent does subtask 1 🟩🟦 Subtask 1 work
Agent does subtask 2 🟩🟦 Subtask 2 work
Agent does subtask 3 🟩🟦🟪 Subtask 3 work
...
Context Compression LLM
We introduce a dedicated LLM whose sole job is to “compress” lengthy historical records into summaries of key decisions and events.But this is very, very difficult.
The core challenge is that compression itself is a lossy operation, which can easily result in the loss of subtle context crucial for subsequent tasks. The compression model itself may also misunderstand or hallucinate, introducing new errors. Additionally, this extra LLM call can increase the overall system latency and cost. Therefore, context compression is not a silver bullet but an advanced technique that requires careful evaluation and fine-tuning. At Cognition, we even fine-tuned a dedicated small model for this purpose.
For the curious reader, I encourage you to think of better ways to handle arbitrarily long contexts. This will ultimately be a rather profound question!
Applying Principles to Reality
🤝 Tool Paradigm vs. Distributed Paradigm: A Comparison of Two Collaboration Architectures
As task complexity increases, we still face the question of how Agents collaborate. In the industry, two popular models are:
🧩 Tool Paradigm: Tool-Calling Collaboration
Tool Paradigm
Main Control Agent
Tool Agent-1
Tool Agent-2
Tool Agent-3
- • A single main control Agent, with other agents called like “tool functions”
- • Centralized context, short links, easy debugging
- • Suitable for structured processes and tasks with clear sovereignty
🔄 Distributed Paradigm: Independent Agent Collaboration Network
Distributed Paradigm
Agent-A
Agent-B
Agent-C
Agent-D
- • Multiple Agents operate relatively independently, passing messages to each other
- • Context is decentralized, links are complex, prone to errors
- • Suitable for multi-role, exploratory tasks (but with high demands)
🧮 Tools vs. Distribution: Comparative Analysis Table
| Dimension | Tool Paradigm | Distributed Paradigm |
|---|---|---|
| Main Control Mode | Single Agent Control | Multiple Agents Relatively Independent |
| Context Storage | Centralized Storage by Main Control Agent | Decentralized Among Agents |
| Invocation Method | Function Call Style | Message Passing Style |
| System Complexity | Low | High |
| Scalability | Plugin-style Expansion | Network-style Expansion |
| Applicable Scenarios | Work Order Systems, Retrieval Tasks | Multi-role Collaboration, Exploratory Tasks |
When designing your own agents, repeatedly ask yourself: Can every action of the system refer to all relevant, previously made decisions?
- • Case of Claude Code: As of June 2025, Claude Code generates sub-tasks when needed, but it never allows sub-task agents to work in parallel, and these sub-tasks usually only answer questions rather than write code. Why? Because it understands that sub-task agents lack the complete context of the main agent and cannot handle more complex tasks. If they work in parallel, the sub-agents may provide conflicting answers. The designers of Claude Code intentionally chose this “simplified” but reliable model.
- • Evolution of Code Editing Models: In 2024, many coding agents (including early versions of Devin) popularized an “edit-apply” model: large models output human-readable Markdown modification instructions, while a small model is responsible for applying the instructions to code files. However, this often led to errors because the small model could misinterpret the large model due to subtle ambiguities in the instructions. Today, the industry trend is to have a single, more powerful model complete decisions and executions in one operation to avoid information transfer loss.
-
📌 Recommendations for Hybrid Strategies in Practical Applications
The most stable combination is:
Claude Code adopts this hybrid approach: the main agent is responsible for all context and decisions, while sub-agents only perform “knowledge-based Q&A” and execute in series, with very few parallel calls.
- • Core control logic → built with serial agents + tool paradigm
- • Creative exploration, diversity of viewpoints → assisted by lightweight distributed paradigm
Let’s Talk About the Hot Topic of “Multi-Agents”
When it comes to parallelism, many people ask: Why not let agents “hold meetings” to discuss and resolve conflicts like human teams?
This is indeed the ultimate ideal. When human engineers A and B have a code conflict, they can meet, communicate, and reach a consensus. However, the problem is that, with the current level of technology, enabling LLMs to engage in high-quality, long-context proactive dialogues has very low reliability.
Since the advent of ChatGPT, “multi-agent collaboration” has become a hot direction. However, I must point out an observation that may disappoint many: In 2025, any model that allows multiple agents to collaborate in parallel on a shared complex goal will ultimately lead to a fragile, chaotic system. This is because decision-making is overly decentralized, and context cannot be effectively shared.
It is important to emphasize that we do not completely deny “multi-agents.” If a task can be broken down into completely independent, non-dependent sub-items (for example, a “supervisor” agent allows three “employee” agents to summarize three unrelated articles), this hierarchical model is entirely feasible. What we oppose is the parallel model that attempts to mimic human complex collaboration.
I personally believe that the key to solving this problem lies in first maximizing the communication efficiency of single-threaded agents with humans. Once agents can align efficiently with us, their efficient alignment with each other will also become possible.
Moving Towards a More General Theory of Agents
The observations discussed today regarding context engineering are just the tip of the iceberg of future standards for agent construction. At Cognition, agent construction is at the forefront of our thinking. Our internal tools and frameworks are built around these repeatedly validated principles.
However, we are well aware that theory is not perfect, and technology is evolving rapidly. Therefore, maintaining flexibility and humility, and exploring together with all practitioners, is crucial.
The journey of building agents has just begun. This is not only a technical challenge but also a test of our cognition and creativity. Let us work together to build a more reliable and intelligent future with deeper principles.
🔚 Summary: Towards a More Reliable and Intelligent Agent Architecture
- • Parallelism does not equate to efficiency, and serial does not equate to backwardness
- • Context integrity is the primary condition for building reliable agents today
- • Multi-agents are not a “silver bullet”; their parallel autonomy must be limited and used cautiously
- • Truly universal agent architectures may still require our collective invention
The future of agent development is not merely a stack of coding capabilities but a deep exploration of cognition, alignment, and collaboration methods.
Welcome to join the dubbogo community DingTalk group: 23331795, and feel free to scan the code to join the dubbogo community group:
