Multi Agent System Failures: 33 Skills Told One Agent He Was Another

In a multi agent system, a defect rarely stays in the agent where it started. On 9 August 2026 we found that 33 of our revenue agent's skill files opened by telling him he was our operations agent. Nobody wrote that on purpose. The files had been copied from one agent to another, header and all, and the error travelled with them.

That was the worst finding in a sweep we ran across all four agents in our internal AI operating system. It was not the only one. The same day, one wrong belief about an API had been copied into ten skill files, an architecture document and two agents' working assumptions before anyone noticed it was wrong. This post walks through both, in the order we found them, and ends on the rule we now apply to every agent build.

What goes wrong in a multi agent system that does not go wrong with one agent?

Errors replicate. A single agent with a bad instruction makes the same mistake repeatedly. A multi agent system copies the bad instruction into other agents, other skill files and other documents, and each copy is read as an independent source. Fix the original and the copies keep teaching the mistake.

Mert Cemri and colleagues studied this failure class directly. Their Multi-Agent System Failure Taxonomy (MAST), built from more than 1,600 annotated traces across 7 multi-agent frameworks, sorts failures into 14 modes in 3 categories: system design issues, inter-agent misalignment and task verification. Their inter-annotator agreement was a kappa of 0.88, so the categories are not loose. What we hit sits squarely in the first category. No model failed at reasoning. The design let one agent's documentation become another agent's identity.

Our setup at the time: four agents, each in its own container with its own credentials. JARVIS works for the founder, Taurus runs operations as the COO agent, Kiara handles HR and Neo runs revenue. Each has a SOUL file (who it is, what it may do) and a library of skills (how to do specific jobs). Agents write to their own skill libraries as they learn. That last detail matters later.

How did a third of one agent's skills end up addressed to a different agent?

They were copied. When we built Neo's skill set, the fastest starting point was Taurus's, which already covered reporting, CRM reads and campaign checks. Every banner-carrying skill in Taurus's library opened with one line:

"You are the COO agent."

The copies kept that line. Thirty-three of Neo's skill files told him he was the COO. The same banner told him that pausing an ad was a normal part of his job, which it is not. Ads belong to Taurus. Neo's own SOUL file said the opposite: "Never claim to be one of them, and never answer as though you held their access."

So one agent held two contradictory identities in writing. One file said he was Neo, the revenue agent. Thirty-three said he was the COO. Nothing in the runtime flagged this, because the runtime does not read identity. The credentials were correct, the container was correct, and the gate that decides what each agent may execute was correct. Only the prose was wrong, and the prose is what the model reads while it reasons.

Melvin Conway put the general version of this in 1968: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." Our skill libraries turned out to be a copy of how they were built. Neo's library was a fork of Taurus's, so his idea of himself was a fork of Taurus's too.

What happens when an agent's skill file and its identity file disagree?

The model settles it by whichever file it read most recently, and a skill is almost always read more recently than the SOUL. Skills load for the task at hand. The SOUL loads once, at the top. In a direct contest between one SOUL file and 33 skill files, the numbers favoured the wrong answer every time a relevant skill loaded.

That is why prompt-level identity is weaker than it looks. An identity statement is not a setting. It is one sentence among many in the context window, and it competes with every other sentence that makes a claim about who the agent is. Any file that opens with "You are" is an identity file, whatever its filename says.

We did not catch this from a bad action. We caught it because we were already sweeping Neo's files for a different defect, one we had found in Taurus the same afternoon.

How far did one wrong belief travel through the system?

Ten files, one architecture document and two agents, in less than a day. The belief started as a single message on our agent bus, and every copy after that was written in good faith by an agent doing what it should: recording what it had learned.

The belief was this. Our task-management platform exposes a reporting API that returns a field called team_id, and its write API expects a field called section_id. JARVIS escalated that the two were different identifiers, so the IDs Taurus already had were the wrong kind. Our own follow-up agreed. Taurus accepted it. Seventeen messages passed between Taurus and JARVIS in three hours, trying to obtain IDs he believed he could not see.

The platform's engineer replied with the schema. The reporting view selects sections.id and renames it team_id. They were the same UUID under a different column name. Taurus had held the right IDs since 10:30 that morning and had been told twice they were wrong. Nothing in either API response said the column had been renamed, and two agents and our own engineering session all inferred a difference from the name alone.

When the founder asked whether the same assumption had spread anywhere else, a search found it in ten skill files, none of them the ones we had already fixed:

• Two platform-behaviour reference files saying reporting team IDs were "not sufficient proof" of a section ID
• A deployment-control skill forbidding agents to use a team UUID as a section ID
• An entire preflight reference file built on the premise that the real UUIDs could not be obtained
• Three workflow-design references repeating the same claim in slightly different words
• A design skill calling the platform's reporting access read-only, on a key that exposed 68 actions, including creating sections
• JARVIS's own mesh-operations skill, telling him to treat application reporting keys as reporting-only

Our data store's architecture document also described the platform as reachable only through "its read-only reporting API". That system has 68 write actions.

Why did fixing the original not fix the agent?

Because the agent does not read the original. It reads the copies. By the time we corrected the bus message and restored Taurus's authority in his SOUL file, nine of his own skill files still told him to obtain section UUIDs through a lookup that did not exist. He would have rebuilt the same deadlock the next morning while following his own documentation correctly.

The first cleanup pass missed three of the ten. They made the same claim in different words: "not automatically a valid", "is not proof", "not enough". A search for the sentence we had originally written found the sentences that matched it. A wrong belief does not keep its wording when an agent writes it down. Each agent paraphrases it into the file it happens to be editing.

The fix that held was the most literal one. The preflight file that had said "their real section_id UUIDs were not included in the response" now carries the five real UUIDs. A document that states the answer is harder to misread than one that states the absence of a problem.

The general rule we took from it: after reversing any belief an agent has acted on, search for every phrasing of it across every agent, not just the one you wrote. In a multi agent system, a correction goes out the same way the error did, one file at a time, and it has to reach all of them.

Why were the agents' own lessons never under version control?

Because nobody thought of agent-written skills as code. When we committed the ten corrected files, all ten went in as additions. Taurus had been writing operational doctrine into his skill folder for days, including naming standards, platform behaviour and preflight sequences, and none of it existed in the repository.

Everything else was versioned: the data store, the approval gate, the control plane. The one layer that changes most often, and changes without a human in the loop, had no diff, no history and no review. Nothing sat between an agent learning something wrong and that wrong thing becoming policy for every future session.

If you are building agents that write to their own instructions, that folder is production configuration. Put it in version control and read the diffs. If you want a team to design that layer with you, our AI agent development work starts with the credential boundary, the write gate and a versioned skill store before any agent touches live data.

What else did the sweep turn up once we checked all four agents?

More of the same class, and none of it in the agent we had been watching. The founder asked for the same pass on Kiara and Neo that we had just done on Taurus. Here is what it found:

• Kiara's SOUL told her everything consequential went to the founder for approval. The gate had already granted her nine self-service action types.
• Neo's SOUL said the CRM was read-only for him, while contact and opportunity updates had been in his self-service set since the set was created.
• 33 of Neo's skills addressed him as the COO, as described above.
• 129 skill files across all four agents still named founder approval as the only route, after we had added a second approver. They now print what the gate's own listing shows.
• Four data-store skills told agents to submit an action type called data.write. The gate's registry has 28 types, and that is not one of them. Any agent following those files would have been refused outright.

The last finding was our own. While wiring the second approver, we had put Neo on the list for resuming paused ads and setting ad budgets. That would have let JARVIS approve an ad-spend change requested by the agent whose own SOUL says ads are not his. Nobody decided that grant. We wrote a permission table in one sitting, and "these seem to go together" reads exactly like a decision afterwards. We removed it.

Why was the defect never in one agent?

Because the agent that looked broken was the only one talking about it. Taurus looked like the problem because he was the one escalating. The same fault, capability granted in the runtime and withheld in the prose, was in all three subordinate agents. Add an identity error in a third of one agent's skills and a nonexistent action type in four more files.

An agent that believes it cannot do something and says so creates messages, and messages get read. An agent that believes the same thing and quietly skips the work creates nothing to read. In a multi agent system, the loud agent points you at a defect that the quiet agents usually share.

The rule we now apply to every build: when one agent behaves more timidly than its permissions allow, the others are not fine. They are just quieter about it. Audit all of them together, because they share ancestry.

How do you audit a multi agent system for inherited errors?

Check the files the agents read, across all agents at once, against the system they describe. These are the checks we run now, each one taken from a specific miss above:

• Search every skill library for lines that begin "You are" and compare each against that agent's SOUL. A mismatch is an identity defect, not a typo.
• When you copy a skill set from one agent to another, strip the banner before the first commit. The copy is a new file and should not inherit the old agent's identity.
• After correcting a belief, search for the idea, not the sentence. List three or four ways an agent might have paraphrased it and search for each.
• Check every action name in every skill against the gate's registry. An instruction to submit an action that does not exist fails the first time anyone follows it.
• Put agent-written skills under version control and review their diffs the way you would review a config change.
• Build permission tables with each grant as a separate decision, with a stated reason next to it.

None of this needs new infrastructure. It needs a search tool, the registry and an afternoon. The full architecture behind the four agents is written up in how we built our AI agent architecture, and the broader pattern of written restrictions the runtime no longer enforces is in stated controls are not controls.

The primitive: a wrong belief writes itself into the places that will regenerate it. Correcting the source does not correct the copies, and the copies are what the agent reads tomorrow.

Frequently asked questions

Does giving each agent its own container prevent this?

No. Container isolation separates credentials, files and processes, and ours did that correctly throughout. The identity error lived inside Neo's own container, in files he was supposed to read. Isolation stops one agent reaching another's secrets. It does nothing about what an agent was told about itself, which is a content problem, not an access problem.

Should agents be allowed to write their own skills at all?

Yes, but treat those writes as configuration changes. Agent-written skills are how a system keeps what it learns between sessions, and turning that off throws away most of the value. The fix is review, not prohibition: version the folder, surface the diffs, and check new claims about platform limits against the platform before they harden into policy.

How often should a multi-agent system be swept for this?

After any correction to a belief an agent has acted on, immediately and across every agent. Beyond that, whenever a skill set is copied to create a new agent, and before any change to permissions. Our worst findings came from copying and from permission edits, both of which are events you can hook a check to, not calendar dates.

Is a copied skill library always a mistake?

No. Copying a working library is a sensible way to start a new agent, and most of Neo's 33 files were useful. The mistake is copying the parts that describe the agent along with the parts that describe the task. Separate the two: identity and authority go in one place per agent, and skills should describe the job without saying who is doing it.

What would have caught the 33 files earlier?

A one-line check comparing each skill's opening "You are" statement with the agent that owns the file. We had no such check because we never thought of skill banners as identity declarations. It now runs against every library, and it is cheaper than any of the manual sweeps that found these issues.

If you run more than one agent and have never read their skill libraries side by side, that is the first thing to do. Talk to us and we will go through yours with you, starting with every line that tells an agent who it is.