Almost every multi-agent system shown to me this year has the same story behind it. One agent was not doing a task well, somebody proposed splitting it across three specialized agents, and now there are three agents that also do not do it well, plus a new problem: agreeing with each other. The diagram came out impressive and the result got worse.
The short answer: the four ways to extend an agent answer different questions. They are not alternatives, and they are not maturity stages. Picking the wrong one does not just waste work, it adds failure modes that did not exist before. And the one most often picked prematurely, multi-agent, is precisely the one that adds the most.
What question does each one answer?
Four different questions. If you know which one is yours, the choice is obvious.
| Extension | The question it answers | What it does NOT solve |
|---|---|---|
| Harness | How does the model act instead of only replying? | What it should do, and with what information |
| Skills | Does it know how this task is done here? | Reaching the systems where the data lives |
| MCP | Can it touch the systems where the data is? | What to do once it gets there |
| A2A | Can it delegate to an agent that is not yours? | Coordinating the agents that are yours |
| Multi-agent | Is splitting the work across several worth it? | Each part being solved well |
The market's most expensive confusion sits between rows two and three. MCP hands the agent the key to the warehouse. A Skill tells it what to do once inside. They are complementary, and most production systems use both.
What is the harness, and why does almost nobody name it?
It is the loop that turns a model into an agent. Without it there is no agent, there is a chat.
A language model on its own takes text and returns text. The harness is what makes it act: it takes the instruction, lets the model decide, executes the tool it asked for, hands back the result, lets it decide again, and persists state between steps so the next turn knows what happened in the last one.
It is the least discussed of the concepts circulating in these lists, and the one that most determines whether the system is usable. A bad harness shows up as symptoms people blame on the model: the agent repeats the same step, does not recognize it is finished, or loses halfway through what it had already decided.
It is no accident that those three symptoms appear as named failure modes in the literature, and we will come back to them below.
When do you need a Skill?
Almost always, and it is the cheapest of the four.
A Skill is a folder of instructions that teaches the agent how to do one thing: the criteria, the order, the output format, what to check before delivering. Since December 2025 it has been an open, file-based standard: a SKILL.md with instructions plus whatever resources and scripts it needs [2].
Its key mechanism is progressive disclosure: at startup the agent loads only each Skill's name and description, roughly 30 to 50 tokens each. The full instructions load when a task matches, and referenced files load only during execution [2]. This matters for a practical reason: you can have fifty Skills available without spending context on the forty-nine that do not apply today.
Signal you need a Skill: the agent has access to everything it needs and still delivers in the wrong format, skips a review step, or applies a criterion that is not the right one at your company.
Signal this is not what is missing: the agent knows exactly what to do and cannot, because it cannot reach the system.
When do you need MCP?
When the agent has to touch real systems, and there is more than one.
MCP solves the custom-integration problem: one standard protocol instead of a hand-built connector per tool. If your agent talks to a single system and you already have that connector written, MCP will not change your life today. If it is going to talk to six, and you expect nine next year, the difference is structural.
Signal you need MCP: you are writing the third connector by hand and all three look suspiciously alike.
Signal you do not: one stable system, with an API that already works. Adopting the protocol there is architectural overhead with no return.
When do you need A2A?
When the other agent is not yours. That is the whole rule.
A2A exists so agents from different owners or vendors can discover each other, exchange tasks and delegate work securely. It is an interoperability decision between organizations, not an internal architecture decision.
It gets confused with multi-agent constantly because both involve more than one agent. The difference is the boundary: A2A crosses it, multi-agent does not.
Signal you need A2A: you are integrating with a vendor's, a customer's or a partner's agent, and neither side controls the other.
Signal you do not: the agents are all yours, running on your infrastructure, deployed the same day. A discovery protocol between strangers is ceremony there.
When do you need multi-agent?
Much later than most people think, and there is evidence of what arriving early costs.
UC Berkeley's MAST study analyzed more than 1,600 annotated traces from seven popular multi-agent frameworks and classified 14 distinct failure modes [1]. What matters is not the count, it is where they come from.
Data
| Value | Share | |
|---|---|---|
| Specification and system design | 41.8% | 42% |
| Inter-agent misalignment | 36.9% | 37% |
| Task verification | 21.3% | 21% |
Almost 37% of failures are inter-agent misalignment. That percentage does not exist in a single-agent system: it is a cost that appears the day you decide to split the work. And the largest category, specification and design, also grows with the split, because every new boundary between agents is a new specification somebody has to write well.
The most frequent individual modes are just as revealing.
Data
| Failure mode | Frequency |
|---|---|
| Repeating an already executed step | 15.7% |
| Not recognizing the termination condition | 12.4% |
| Disobeying the task specification | 11.8% |
Repeating a step, not noticing it is done, disobeying the instruction. These are exactly the symptoms of a weak harness, which is the first item on the list and the one almost nobody built before splitting the work across three agents.
Signal you need multi-agent: you have genuinely parallel subtasks, or subtasks requiring mutually incompatible contexts, and one agent already solves each of them well.
Signal you do not: one agent does the task badly and the proposal is to split it. Splitting a problem you do not understand gives you several problems you do not understand.
In what order do you build?
Bottom up, and you almost never reach the end.
| Step | Extension | When to move to the next |
|---|---|---|
| 1 | Harness | When the agent completes the task end to end and knows when it finished |
| 2 | Skills | When criteria and format come out right without anyone correcting by hand |
| 3 | MCP | When the agent reaches every system it needs |
| 4 | Multi-agent | Only if there is real parallelism or incompatible contexts |
| 5 | A2A | Only if the other agent belongs to somebody else |
Most projects that work stop between 2 and 3. That is not a limitation, it is the expected result: steps 4 and 5 solve problems most systems do not have.
How we apply this at MasterDragon
We ask what is missing before asking what to add.
In practice, when an agent underperforms we check in this order: does it recognize when it finished? are the criteria written down or are we assuming them? does it reach the data? Only if all three answers are yes and the work still comes out wrong do we consider splitting it. In most cases the answer is in the second question, and it is solved by writing an instruction properly, not by deploying architecture.
We also build with a single agent by default and split only when we can name the subtask that runs in parallel. If we cannot name it, there is no parallelism, there is an appetite for a more interesting diagram.
If you are about to commit to an agent architecture and want to know which of these four you are actually missing, talk to our engineers. You can start with how we build your software and review our portfolio of shipped AI-native products. The full vocabulary is defined in the agentic AI glossary, what sits underneath an agent that survives production in the 13 layers of a real AI system, and how much autonomy to give each one in engineered agency.
References
- Cemri, M., et al. (2025). Why do multi-agent LLM systems fail? UC Berkeley. arXiv:2503.13657. https://arxiv.org/abs/2503.13657
- Anthropic. (2025, December). Agent Skills: an open folder-based packaging format (SKILL.md) with progressive disclosure. https://anthropic.skilljar.com/introduction-to-agent-skills