How Agent / Skills / Teams Architectures Evolve, and How to Choose Among Them

A few days ago I read several AI engineering articles shared internally by some of the senior folks at Alibaba and Ant Group. A handful of them were so good that I learned a great deal from them, so I want to share what I took away here.

Background

For the past few years I have been exploring, building, and shipping in the Agent space, and along the way I have accumulated quite a few technical write-ups. Many of you have probably read my earlier piece, How Do You Build and Tune a Highly Available Agent? A Look at Alibaba Cloud’s Methodology for Building Service-Domain Agents. That article gave a fairly systematic treatment, from the conceptual origins of Agents to the challenges of putting them into production and the concrete solutions in between. Later, as context engineering, Multi-Agent, Agent Skills, and other techniques kept advancing, I wrote How Do You Make an Agent Behave as Expected? Ten Lessons from Building Cloud Assistant Aivis with Context Engineering and Multi-Agent Systems, which dug into our hands-on experience with a number of Agent implementation details.

From the explosion of generative LLMs to the rapid rise of Agents they made possible, the wave of AI progress has never paused. Over the past six months or so, as Anthropic has practiced and shipped brand-new paradigms like Agent Skills and Agent Teams on Claude Code, the logic for building Agents and the boundaries of what they can do are being redefined. Standing at this point in time, when we once again ask “how do you build an excellent Agent?” and “how do you choose a technical architecture?”, the old perspectives may no longer be enough to handle all the variations across scenarios.

In my view, before we get into specific technology choices, the first task is to understand the evolutionary path of Agents. That path is actually fairly clear and traceable: from the earliest single-point prompt invocation and workflow orchestration, to multi-agent collaboration and autonomous planning, and later to the reusable capabilities of Agent Skills and the parallel exploration of Agent Teams. Only once we understand this evolutionary thread can we make sharper technology choices when facing complex scenarios.

So, drawing on my own hands-on experience and the following articles, this post reorganizes and shares my thinking about the architectural evolution and selection of Agents, Multi-Agent, Agent Skills, and Agent Teams:

• Towards a Science of Scaling Agent Systems by Google DeepMind
• The Complete Guide to Building Skills for Claude by Anthropic
• Orchestrate Teams of Claude Code Sessions by Anthropic

The Essence of Agent Architecture Evolution

Why has the market produced such a dizzying variety of Agent architectures? Trace it back to the root and you find it is not pure showmanship, but a compensation mechanism for the underlying capability gaps in large models. In essence, the history of Agent architecture evolution exists because, against the backdrop of base models that cannot perfectly internalize “domain knowledge” or efficiently reuse “long-term memory,” we keep trying to “bolt on” those capabilities from the outside. Fundamentally, the two needs around large models, injecting domain knowledge and managing memory, are what have continuously driven the evolution of Agent architectures.

Let’s indulge in a thought experiment: suppose one day we achieve a world where the LLM base model is born with a perfect ability to absorb domain knowledge and manage memory autonomously. As long as we “feed” it massive industry documents and business rules, it instantly remembers them and executes tasks precisely. In that world, all the architectural patterns we discuss today, RAG, Multi-Agent, Workflow, Skills, would likely lose their reason to exist, because the model itself has solved the questions of “what to learn” and “what to remember” at the source.

But reality is harsh. Cast your mind back to 2023-2024, the early days of large models. The industry broadly believed that the best answer to injecting vertical-domain knowledge was model training. This “pre-train then fine-tune” paradigm, which had been developing since the BERT era, carried straight into the LLM era. We took a base model as the foundation, applied SFT, DPO and other fine-tuning methods, then added reinforcement learning such as RLHF and GRPO, all in an attempt to “burn” domain knowledge into the model’s parameters. During that period we also ran many deep rounds of model training and fine-tuning on early Qwen versions as our base model.

But as training went deeper, several unavoidable pain points surfaced:

• Training is expensive and slow. Every round of vertical-domain training demands enormous human and material effort to clean data, construct synthetic data, and design evaluation sets. It requires not only costly GPU compute but also long training cycles.
• Evaluation and generalization are hard. Once training is done, how do you rigorously prove the new model is meaningfully better than the base model without losing general-purpose generalization? That is a huge challenge. Many times, while improving performance on a specific task, we unexpectedly triggered “catastrophic forgetting” in other scenarios, leaving the model relatively effective on certain vertical tasks but easily losing generalization elsewhere.
• Base models iterate far faster than training cycles. This is the most fatal point. Open and closed base models are iterating at a nonlinear pace. Often, by the time we have spent months and poured resources into training a domain-specific model, a new generation of base model has already shipped, and its native capabilities easily surpass the old version we worked so hard to train. This “graduate and unemployed on the same day” predicament makes building domain models purely through training extremely uneconomical.

Beyond cost and timeliness, shifts in hardware barriers and the model ecosystem accelerated this transition. As scaling laws took effect, the parameter counts of top models grew ever larger, and a single machine, or even a small cluster, could no longer shoulder the training. More importantly, the most powerful models today are largely closed-source. Even if we train on top of the best open-source models, the end result usually struggles to match the latest base models from the closed-source giants. Against this severely lopsided “return on investment,” doggedly persisting with model training is clearly no longer the wise choice.

This tells us that today’s LLMs still face significant challenges in internalizing knowledge for specific domains and managing long-horizon memory. Since modifying model parameters “inward” is a dead end, or simply too poor a value proposition, we naturally turn “outward” for solutions: how do you inject domain knowledge more efficiently through architectural design, without changing the model weights?

This is precisely the logical starting point for the evolution of Agent architectures. We are forced to build layer upon layer of structure and tooling around the large model, using “engineering” means to help it retrieve knowledge, assemble context, and maintain memory. This is the most fundamental reason for the flourishing variety of Agent architectures today. We no longer obsess over making the model “remember” all knowledge; instead, we design a mechanism that lets the model “find” and “understand” the knowledge it needs. Building on this idea, Agent architecture evolution has gradually diverged into four main paths: Single Agent → Multi-Agent → Agent Skills → Agent Teams.

Single Agent: Knowledge Injection and the Battle with the Context Window

When exploring how to ship Agents, the first thing we usually try is the Single Agent architecture. Its core logic is very intuitive: since the large model cannot directly internalize our specific domain knowledge, we just “mindlessly” inject that knowledge into the model’s context via the System Prompt, hoping it can generate the expected answers based on the injected information.

The biggest advantage of this approach is extremely low implementation cost and extremely high development efficiency. You only need to organize the domain knowledge, write it into a system-level System Prompt along with clear instructions, and then use the base model’s native ReAct loop to autonomously call tools, track context, and solve problems. For scenarios like generating simple code snippets, writing copy, or producing some kind of standardized output, this serial, single-Agent mode often delivers the smoothest experience, and it is the prototype scheme with the highest ROI for validating ideas.

But as we went deeper, we found this seemingly simple architecture hides a fatal bottleneck: the context window explodes.

Although mainstream large models now claim support for million- or even ten-million-token context lengths, in real production, if you truly “dump” massive background knowledge or long documents straight into the model, the results often disappoint. Behind this lies a technical truth that is easy to overlook: a long context is not the same as a long memory. Once the input volume crosses a certain threshold, the model is very prone to the “Lost in the Middle” problem, that is, “attention loss” or “forgetting key information”, leaving it unable to pinpoint the domain knowledge it needs, so the final output drifts from expectations.

Here we need to be clear about the scope of the discussion. By Single Agent, this article mainly means the “narrow” notion of a ReAct-based autonomous Agent, a native Agent run mode driven by a System Prompt that calls tools serially. As for those structurally complex Workflows with multiple branching decisions, we prefer to treat them as an advanced Tool or Sub-Agent rather than a pure Single Agent form, so we won’t dwell on them in this section. For an introduction to, and the controversy around, Agents versus Workflows, see my article The Controversy Over the Concept of “Agent”.

In short, the strengths and weaknesses of the Single Agent are very clear:

• Strengths: the most native architecture, the shortest development path, extremely high runtime efficiency; well suited to quickly building a demo or handling scenarios with little knowledge dependency.
• Weaknesses: extreme dependence on the quality and length of the context window. The moment large amounts of domain knowledge need to be injected, the context easily explodes, scattering the model’s attention and sharply reducing stability.

This raises the key question we need to think about next: when a single-point breakthrough hits the context bottleneck, how do we evolve the architecture to solve the knowledge-carrying problem while keeping flexibility?

Facing this dilemma, the industry’s common solution is to introduce RAG (Retrieval-Augmented Generation).

RAG can be seen as an important evolution on top of the Single Agent. Its core logic is “search first, then answer”: before injecting knowledge into the large model, it first uses a search tool to perform a round of recall, extracting only the fragments most relevant to the user’s question and providing them to the Agent as context.

To a degree, this cleverly sidesteps the context-window length limit, letting the Agent “fetch knowledge on demand” rather than “swallow it whole.” However, RAG architectures carry a fatal dependency chain: garbage in, garbage out. The Agent’s final performance hinges heavily on the accuracy of the upstream search stage. If the retrieval stage fails to recall the correct knowledge fragments, then no matter how powerful the downstream large model is, it cannot generate a correct answer.

There is a notable capability gap here: RAG’s upstream retrieval typically relies on keyword matching (such as BM25) or small-parameter embedding models (such as BERT or BGE). Even though many LLM-based embedding models have appeared in recent years, on the whole the semantic understanding and reasoning depth of these dedicated retrieval models still lag behind a large model’s ability to read and understand the full text directly. This “small model assisting the large model upstream” pattern often causes key information to be missed or mis-recalled, becoming a bottleneck that constrains Agent performance.

Based on the above analysis, we can clearly delineate the boundaries of the Single Agent. It is not suited to every scenario, but under the following conditions it remains the choice with the best value and fastest time to ship:

1. Low scenario complexity: the business logic is relatively simple and does not require complex multi-step reasoning or long-chain planning.
2. Manageable knowledge volume: the total domain knowledge is moderate, or after cleaning, the core instructions and background knowledge can be stated clearly within about 20K tokens and injected directly via the System Prompt.
3. Guaranteed retrieval quality: when RAG must be used, the premise is that your knowledge base is well structured and your existing retrieval algorithm (keyword or vector) can achieve high recall accuracy.

Put simply, if your need is “small and beautiful,” or your domain knowledge has clear boundaries and a mature retrieval pipeline, then the Single Agent architecture is entirely up to the job, with no over-design required. But when you face massive unstructured data, complex reasoning needs, or scenarios extremely sensitive to retrieval accuracy, you need to step out of the single-point mindset and explore more complex architectural evolution.

Multi-Agent: Trading Off Architectural Isolation Against Communication Bandwidth

Faced with the limits of the Single Agent in injecting massive knowledge and handling complex scenarios, the Multi-Agent architecture emerged. This is not just stacking up the number of Agents; it is a qualitative leap. Take our practice with Alibaba Cloud’s customer-service-domain assistant Aivis: by building an architecture in which roles such as Planner, Reasoner, and Executor collaborate, we decompose complex macro problems into micro sub-tasks, with different Agents each playing their part.

There are actually many Multi-Agent patterns. In Google’s paper they are grouped into four main types: Independent, Decentralized, Centralized, and Hybrid.

• Independent: multiple Agents process sub-tasks in parallel without communicating, merging results only at the end.
• Decentralized: a peer-to-peer mesh structure where Agents communicate directly to share information and reach consensus.
• Centralized: a “hub-and-spoke” model in which a central Orchestrator assigns tasks to workers and synthesizes their outputs.
• Hybrid: combines hierarchical supervision with peer-to-peer coordination to balance the control of a central Orchestrator against flexible execution.

The first two can be viewed as having only Sub-Agents, while the latter two both feature a central Orchestrator acting as the main Agent. The core logic of these Agents lies in “routing and dispatch” and “domain isolation”:

• Main Agent (Orchestrator): plays the role of the “brain,” responsible only for intent recognition and task routing, judging “who should this question go to?” without having to bear the knowledge burden of every domain.
• Sub-Agents: each has an independent Identity space and internalizes specialized knowledge for a specific domain (such as ECS remote diagnostics or RDS performance tuning). Each Sub-Agent need only focus on solving one class of vertical scenario, so its Prompt is leaner and its domain knowledge more focused.

This way, the Multi-Agent architecture brings clear advantages:

• Lower monolithic complexity: the huge body of domain knowledge is broken up, avoiding the possibility of a single Agent’s context window exploding.
• Independent tuning: each Sub-Agent can iterate independently. If “ECS remote diagnostics” underperforms, you only need to tune that one Sub-Agent’s prompt or tool chain without affecting other modules, greatly improving maintenance flexibility.

However, as the number of Agents grows, say, when an Orchestrator in some scenario dispatches to hundreds of Agents, new bottlenecks appear, and we find that Multi-Agent is no silver bullet either. It introduces two new challenges:

• Pressure on routing accuracy: when the number of Sub-Agents reaches dozens or hundreds, the main Agent faces enormous classification-decision pressure. It must precisely judge user intent within a very short context and dispatch to the correct Sub-Agent. Once the main Agent commits a misrouting, all the downstream Sub-Agents’ efforts head off in the wrong direction. This “one careless move loses the whole game” risk keeps compounding as the number of nodes increases.
• Context fragmentation from “local optima”: this is the most hidden and most fatal pain point in Multi-Agent architectures. Because Sub-Agents often care only about the locally optimal path of their own task, lacking awareness of the global context and the user’s full intent, the following phenomena are very likely:
  • Repeated work: for example, the user asks “ECS remote connection fails,” and Agent A diagnoses “high resource load”; the user follows up with “why is the load high,” and Agent B, taking over, doesn’t know a load check was already done earlier, so it may run the same query again, wasting compute and adding latency.
  • Conflicting conclusions: conclusions different Agents reach from local information may contradict what came before, making the answer internally inconsistent and confusing both the model and the user.

To address context fragmentation, Multi-Agent setups can consider letting Agents share context history. But in engineering practice, this introduces a communication-bandwidth limitation:

• Lossy compression of information: during Multi-Agent communication, what the main Agent passes to a Sub-Agent is often a summarized or rewritten context rather than the raw conversation stream. This lossy transmission can easily lose key details.
• Token explosion and growing latency: if, to preserve quality, you force the model to widen the communication bandwidth to pass more context, you quickly trigger a fresh context-window explosion and significantly increase both LLM generation time and overall pipeline latency.

So, although the Multi-Agent architecture solves knowledge isolation, it shifts complexity onto inter-Agent communication bandwidth and coordination. If you want to guarantee Agent quality, you must pour enormous human effort into polishing every Agent node and communication protocol, designing fine-grained summarization strategies, and handling all sorts of edge cases. This is a classic case of diminishing marginal returns: as the number of Agents grows, the difficulty of guaranteeing overall system stability rises nonlinearly, while the gains in quality come to depend ever more on tedious manual intervention.

Multi-Agent is therefore a double-edged sword: it can break through the ceiling of single-point capability through division of labor, but it also introduces complex coordination overhead. Finding the balance between the flexibility that “architectural isolation” brings and the information loss that “communication bandwidth” causes becomes the key to building a high-quality Multi-Agent system. This is exactly why building a Multi-Agent system is so difficult.

Agent Skills: Reusable, Progressive Capability Disclosure

Facing the complex coordination overhead, routing misjudgments, and high maintenance costs of Multi-Agent architectures, many big companies have been exploring other best practices for Agents. In particular, in The Complete Guide to Building Skills for Claude, Anthropic proposed a brand-new idea: stop blindly piling up Multi-Agents, and instead build reusable, file-system-based capability packages, Agent Skills.

This shift, in essence, reminds us that our original reason for introducing Multi-Agent was to solve the isolation and efficient injection of domain knowledge, yet it brought complex context management and communication mechanisms. If there were a mechanism that could load knowledge dynamically without sacrificing context stability, then heavy inter-Agent communication might no longer be a required option.

The Agent Skills pattern actually returns to the architectural body of the Single Agent, but grants it powerful dynamic extensibility:

• Capability encapsulation and reuse: complex domain knowledge, operational standards, and best practices are packaged into independent “Skills file packages” (much like individual guide books), so the capability can be quickly reused across different Agents.
• On-demand scheduling: the main Agent no longer needs to preload all knowledge; instead, during execution, it dynamically “reads” and loads the relevant Skills files based on the current task’s needs.
• Progressive disclosure: this really is the essence of the Agent Skills pattern. The Agent first locates the needed skill through a directory overview, then gradually reads the specific steps. If it discovers missing knowledge mid-execution, it can proactively trigger the loading of the next Skill to fill the gap.

This pattern gives a single Agent the ability for “local specialization”: at the macro level it keeps a unified memory and state, while at the micro level it can flexibly command thousands of vertical-domain expertise areas just like calling tools.

At this point you might ask: “Isn’t this just dynamically modifying the System Prompt? We tried that before; why didn’t it work?”

There is a fairly key technical difference here. In many early attempts, people tried to dynamically replace the System Prompt directly. This easily causes the model to experience cognitive dissonance: for example, when the System Prompt changes from instruction A to instruction B, the conversation History still retains the interaction records generated under instruction A. The model gets confused: “Is my identity now governed by B? And the earlier answers, which standard were they based on?” This misalignment between context and system instruction often leads to muddled output logic and even hallucinations.

Agent Skills cleverly avoids this problem: the System Prompt stays constant. The core system instructions, such as the persona identity and basic requirements, remain unchanged, ensuring a unified model cognition. Meanwhile, the User Prompt is injected dynamically: the content of a Skill is progressively disclosed to the model via the User Prompt, in the form of “user input” or “tool return result.” To the model, this is like the user continuously providing new reference material during the conversation, rather than forcibly changing its “persona.” The model can clearly perceive: “Ah, I’ve now received a new guide for troubleshooting ECS remote connections; I should answer that earlier question based on this new information.”

As a result, the Agent Skills architecture brings significant benefits:

• Low-cost knowledge injection: it truly turns massive domain knowledge into “manuals.” The model reads on demand with no need to preload everything, lighter than Multi-Agent and more precise than RAG.
• Global context consistency: because the same main Agent always executes (akin to the Orchestrator in Multi-Agent), it fully knows which steps have been executed, which Agent Skills have been read, and the current task state, thoroughly eliminating the information fragmentation and duplicated work seen in Multi-Agent.
• Avoiding context explosion: through “read a little, do a little, read a little more” streaming processing, the instantaneous context length is kept under control.

Of course, the Skills pattern is not a cure-all and has its drawbacks. If Skills are switched too frequently, the accumulated context can still grow long. So in real deployments, you usually need to pair it with context-compression or sliding-window context-management strategies, promptly clearing useless intermediate process information so the model always stays focused on the current, most critical reasoning path.

From Multi-Agent’s “divide and conquer” to Agent Skills’ “consolidate and apply,” we see a more elegant engineering evolution that brings the Agent back to its essence. It replaces complex network communication protocols with the structured power of a file system, and replaces brute-force full injection with progressive information disclosure. For most enterprise scenarios that pursue high stability and low maintenance cost while needing to handle massive domain knowledge, this may well be the current best practice for building Agents.

Agent Teams: An Exploratory Form of “Collaborative Co-Creation”

At the latest frontier of Agent architecture evolution, Anthropic, in its experimental article Orchestrate Teams of Claude Code Sessions, proposed a relatively new concept: Agent Teams. Its core logic is somewhat similar to the “Independent” or “Decentralized” Multi-Agent patterns above, but not entirely the same, and it is aimed primarily at solving complex, unknown problems.

To understand the value of Agent Teams, we first need to clarify how it differs from the traditional Multi-Agent pattern:

• Traditional Multi-Agent: under a traditional Multi-Agent architecture, a Sub-Agent is generally more like an independent “employee.” It receives instructions, completes its task independently, and then submits only a final result report to the master model. In this process, Sub-Agents have zero interaction with one another, or they communicate via a communication protocol between Agents; their contexts are isolated, they don’t know what the others are doing, and they cannot leverage each other’s intermediate findings. (Note: this describes most Multi-Agent architectures, where Sub-Agents don’t communicate, but it’s not absolute. For instance, in the Decentralized pattern, Agents can also be designed to communicate peer-to-peer.)
• Agent Teams pattern: here the Agents are organized into a true “special-ops squad”:
  • Parallel exploration: multiple Agents with different Identities launch at once, running concurrently against the same problem from different angles.
  • Context sharing: this is the most critical change. All members write progress, findings, and thoughts in real time into a shared Task List or Shared Context space.
  • Dynamic collaboration: an Agent can perceive not only its own task but also “see” what teammates are doing. This mechanism breaks down information silos and achieves true team intelligence.
  • Aligned goals: the Agents in an Agent Team share the same ultimate goal (completing the user’s main task), differing only in their division of labor during the process.

So, what problem does Agent Teams solve? Here, Agent Teams was not designed to solve the “domain knowledge injection” or “context-window explosion” problems mentioned earlier. Its core is more about exploring highly uncertain decision problems.

When you face a fairly complex problem with no standard answer at all, one where you don’t even know where to start:

• The risk of a single path: a traditional Single Agent or serial Multi-Agent can usually only follow one preset or highest-probability path to the end; once the direction is wrong, the whole thing fails.
• Multidimensional trial and error: Agent Teams lets the system dynamically spin up multiple sub-identities, each trying a different solution idea (for example, one attempts a code fix, one checks configuration, one analyzes logs).
• Emergence of the optimal solution: by running multiple paths in parallel, the system can compare the intermediate results of each route and ultimately converge on the best scheme, or fuse the strengths of several schemes.

Agent Teams in fact represents a new engineering philosophy: in the face of the unknown, parallel diversity beats serial certainty. It suits “no clear road map” scenarios such as extremely complex R&D debugging, open-ended creative generation, and multi-factor root-cause analysis of faults. Of course, this pattern also has drawbacks. While it avoids the time lost to serial waiting, parallelism also means a multiplied increase in compute cost. At the same time, how to design an efficient “shared Task List” mechanism so that multiple Agents reading and writing shared state don’t conflict or fall into deadlocks is also a key difficulty in deployment. And Agent Teams doesn’t run everything in parallel either; the main Agent decomposes according to the task’s requirements to judge which sub-tasks need to run in parallel and which have sequential dependencies. But this parallelized exploration and the context-sharing mechanism do bring a different, qualitative change.

How to Build Agent Systems Scientifically

In the wave of shipping Agents, for the past few years everyone really was “crossing the river by feeling the stones,” basically relying on intuition or experience to design architectures. Part of the reason is that Agent architectures evolved too fast to spend much energy on deep analysis; another part is that LLM-based systems and projects carry far more uncertainty than traditional software development. But this way of choosing an architecture is still highly unscientific, so pursuing how to build Agent systems scientifically and choose architectures remains a core topic of discussion in both industry and academia today.

Google DeepMind’s recent paper Towards a Science of Scaling Agent Systems opens a new chapter in the scientific design of Agent system architectures and gives us an empirical methodology grounded in extensive benchmarking. To be sure, when this paper was written, it certainly didn’t anticipate that Anthropic would later release the Agent Skills and Agent Teams mechanisms, but its discussion of Single Agent and Multi-Agent already offers a great deal of scientific, constructive advice.

By comparing Single Agent with the four Multi-Agent architectures, that is, the five mainstream architectures discussed above (Independent, Decentralized, Centralized, and Hybrid), the paper reaches several counterintuitive yet highly instructive conclusions.

Combining our earlier discussion of Single Agent, Agent Skills, Multi-Agent, and Agent Teams, we can refer to these conclusions to calibrate our selection strategy:

Stronger models do better, but more Agents do not necessarily do better

To quantify the impact of model capability on Agent performance, Google evaluated Single Agent and the four Multi-Agent architectures across OpenAI GPT, Google Gemini, and Anthropic Claude. The results reveal a complex relationship between model capability and architecture. Generally, the more capable the model you use, the better the Agent performs; Agent capability is basically positively correlated with model capability.

But Multi-Agent is not a universal solution. Sometimes going Multi-Agent does significantly improve results; sometimes it unexpectedly lowers them. So “mindlessly” stacking up the number of Agents and adopting a Multi-Agent architecture does not necessarily improve model performance noticeably.

Minimize communication cost and bandwidth

Google’s experiments found: under a fixed token budget, frequent inter-Agent communication significantly lowers overall system performance.

• Why: communication itself consumes the precious context window, squeezing out the space available for reasoning and knowledge injection.
• Implication: this once again confirms the point we made in the “Agent Skills” section, that logic which a single Agent can digest internally should not be split into multiple rounds of dialogue. Excessive inter-Agent communication often lets information noise drown out core instructions. Unless necessary, pursue an architecture with low communication bandwidth or even zero communication.

The 45% threshold rule for Single Agent

Experimental data show that once a single Agent’s task success rate reaches 45% or higher, simply increasing the number of Agents yields diminishing, or even negative, marginal returns.

• Core value: blindly increasing the number of Multi-Agent instances does not necessarily “raise the ceiling.”
• Warning: if your single-agent baseline already exceeds 45%, blindly adding a complex Multi-Agent coordination mechanism will instead lower overall performance and bring negative returns; you should simplify the architecture.

The error-amplification effect

This is the most sobering datum: a pure Independent architecture can amplify errors by up to 17.2x, whereas introducing a centralized mechanism keeps error amplification controllable at 4.4x.

• Reading: unsupervised “wisdom of the crowd” easily devolves into “collective hallucination.” Without a strong Manager performing validation and correction, the probability of multiple Agents erring simultaneously and reinforcing each other is very high.
• Conclusion: therefore, when using Agent Teams for parallel exploration, you must also pair it with a strong centralized decision mechanism; otherwise stability is out of the question.

The scenario decides the architecture: there is no master key

Google ran multiple Agent architectures across benchmarks for different tasks. The conclusion: task type determines the best architecture.

• Planning tasks (PlanCraft): Agent Planning tasks. This kind of task is logic-heavy and tool-light, so a Single Agent is often the most efficient choice, avoiding unnecessary scheduling overhead for tools and Sub-Agents.
• Tool-use tasks (WorkBench / BrowseComp-Plus): these include tool planning, tool selection, and fetching information via a browser. This kind of task is naturally suited to a decentralized Multi-Agent architecture to fully realize its efficiency advantages.
• Vertical-domain tasks (Finance Agent): such as financial trading. These scenarios have zero tolerance for error, so centralized collaboration works best. It can keep a degree of parallelism while strictly controlling every operation through the central Agent, balancing efficiency and safety.

The Art of Choosing an Agent Architecture

Let’s revisit the four Agent architecture evolution paths we discussed: Single Agent → Multi-Agent → Agent Skills → Agent Teams. They are not mutually replacing; they are solutions for scenarios of different complexity. In real deployments, how do you make the most reasonable technology choice? Based on our hands-on experience, combined with several articles from Anthropic and Google, I’ve distilled a methodology of “start simple, scale only when needed”:

Agent Architecture	When to Use	Selection Advice
Single Agent	Simple scenarios, the default choice • Clear business logic, moderate knowledge volume • Fits entirely within the context window	Fast to build, lowest latency, best cost. In scenarios with clear knowledge boundaries, a single Agent’s native reasoning often beats any complex decomposed architecture. As long as your domain knowledge “fits,” don’t hesitate to choose the Single Agent architecture. Don’t over-design just to chase architectural “sophistication.”
Agent Skills	Medium complexity, the general-purpose solution • Massive domain knowledge that can’t be injected at once • Relatively standard business logic • Not overly complex dynamic planning	Balances knowledge capacity against context stability. When a Single Agent hits a knowledge bottleneck, try the Agent Skills pattern first. The key is to design a sensible Skills file structure (directory indexes, step-by-step guides) so the model learns to “look up the dictionary” rather than “memorize the whole book.” This is the best-value solution for most enterprise domain-knowledge problems today.
Multi-Agent	High complexity, expert-level challenges • Very complex tasks with strict responsibility isolation • Fine-grained process control achievable • Extremely high demands on the ceiling of the final result	A relatively high theoretical ceiling. Through professional, fine-grained tuning (routing strategies, communication protocols, independently trained Sub-Agents), you can build results that exceed single-point capability. But development is hard and maintenance is costly. Routing misjudgments, context fragmentation, deadlocks, and the like easily occur. Use with caution. Only consider this when the two options above truly can’t meet your needs, you have professional Agent-architecture capability, and you’re willing to invest heavy human effort in long-term polishing. For most ordinary business scenarios, the ROI of Multi-Agent often falls short of expectations.
Agent Teams	High complexity, exploring unknown territory • Completely unknown, no standard answer • Open-ended problems requiring exploration of multiple schemes	Parallel exploration, multidimensional trial and error. Use multiple Agents to attack from different angles at once, achieve “wisdom of the crowd” through shared context, and ultimately converge on the optimal solution. Think of it as an enhancement mode for special scenarios. It’s not for routine knowledge Q&A or process execution, but specifically for cracking the “tough nuts” that even human experts need repeated attempts to solve.

Architecture selection advice

I believe the ideal path for building Agents should follow Occam’s Razor: do not multiply entities beyond necessity. Laying out the priority path for choosing an Agent architecture, it basically comes down to this ordering:

• P0: if it can be solved with a Single Agent, never go to a complex architecture.
• P1: when you hit a knowledge bottleneck, introduce the Agent Skills mechanism first, extending the capability boundary through dynamic, progressive loading of Skills.
• P2: only when the above fail, and you have an extreme pursuit of the performance ceiling, should you cautiously start a Multi-Agent architecture, prepared for long-term tuning.
• P3: for highly uncertain exploratory tasks, flexibly layer on the parallel-collaboration capability of Agent Teams.

There is no absolute “best” Agent architecture, only the “most suitable.” I hope this selection framework helps everyone take fewer detours when shipping Agents and build more robust, more intelligent, enterprise-grade Agents at lower cost.

Summary

As Agent technology matures and develops, building Agents is shifting from “tuning by feel” to “systems engineering.” Whether it’s the experimental data in Google’s paper, the best practices in Anthropic’s blog, or the lessons we’ve learned the hard way with Cloud Assistant Aivis, they all point to the same truth: the complexity of an Agent architecture must match the complexity of the problem.

Manus AI’s website has long carried a slogan, “Less structure, More intelligence.” Blindly chasing the “fancy” appeal of Multi-Agent often lands you in a communication quagmire and the trap of error amplification; yet clinging to a single-point Agent when you should be going parallel forfeits the dividends of efficiency. Only by scientifically weighing architectural complexity, cost, error control, and parallel gains based on the characteristics of the scenario can you build an Agent system that is truly robust, highly available, deployable, and more intelligent.

This article is also the journey of my own technical exploration, a personal view and a record of experience, written in haste. If there are any errors, please feel free to correct me!