In March 2025, researchers at the University of California, Berkeley published the first systematic look at why systems with multiple AI agents fail in practice. The team analyzed seven different automation frameworks, more than 200 tasks, and 1,600 real execution traces, reviewed by human experts.
The core finding upends a common assumption. Most failures do not come from the AI model getting an answer wrong. They come from a simpler, older problem: two automated processes acting on the same piece of work without anyone deciding, in advance, who has the final say when they disagree.
This matters to decision-makers because no company stops at a single agent. It runs several, in parallel, on the same process — one triages, another approves, a third records the outcome. When nobody designed what happens at the point where they diverge, the outcome of an identical request ends up depending on a detail no executive would knowingly sign off on: which automation happened to run first.
It is not a bad-model problem, nor a disorganized-company problem. It is a structural one, the same kind any operation has already faced when two human teams act on the same process without a clear agreement on who has the final word. The difference is speed: between people, the conflict surfaces in days; between automations, in seconds, often without anyone noticing it happened at all.
When the outcome depends on who ran first
The Berkeley research named MAST the list of 14 failure modes it found, grouped into three categories: issues in how the work is specified, misalignment between the agents themselves, and missing verification of the result. The taxonomy came out of a detailed review of 150 traces, with human experts agreeing with each other 88% of the time — a high level of agreement for this kind of judgment call.
The most telling group for anyone running operations is the misalignment between agents. It surfaces three patterns any process manager would recognize, only now happening in seconds with no one in the loop to notice: an instruction gets lost between one step and the next; an agent accepts the previous one's output without checking whether it is correct; the process closes out before every check has actually run.
Translated into an everyday routine: one agent applies an old version of the refund policy, another applies the current one, and whichever answer wins depends on the order the two happened to run that day — not a rule anyone wrote on purpose. Nobody at the company chose that criterion. It simply emerged from two systems being switched on without ever being reconciled.
In May 2026, the consultancy Gartner reached a similar conclusion from a different angle: applying the same governance rule to every AI agent, regardless of how much autonomy each one has, tends to push the company toward the agent's own failure. The warning cuts against the common reflex of writing one policy "to cover everything" — what actually works is differentiating, step by step, what each agent may decide on its own.
The same pattern shows up in another common combination: a customer-service automation processes a return while a billing automation, running in parallel on the same customer, has already fired off a debit notice for the item that was just returned. Both were correct within their own step. Neither knew the other existed, and nobody had defined which answer should win in front of the customer.
More rules do not settle the conflict
The most common reflex when this kind of contradiction shows up is to write one more rule, a more detailed policy document, or trust that the AI model itself will notice the conflict and adjust. None of the three works, because the problem is not a missing rule — it is the absence of a place where the rule gets applied before the disagreement turns into a decision.
Deloitte measured this gap in research published in 2026 with 3,235 technology and business leaders across 24 countries: only 21% of organizations say they have a mature governance model for agentic AI in place. In an earlier survey, the same firm found that 42% of companies are still building out their own agent strategy roadmap, and 35% have no formal strategy at all.
Deloitte's report names exactly the missing piece: clear boundaries that define which decisions agents can make on their own and which require human approval. Without that boundary drawn out, every new agent that reaches production is one more potential source of contradiction — and a policy written after the first incident always arrives too late for the case that already happened.
Adding a "supervisor" agent to arbitrate the others does not solve it either, unless that supervisor itself has a declared scope and a clear point where it hands the decision to a person. Swapping two agents with no defined authority for three does not change the shape of the problem — it just adds more places where disagreement can be born.
What has to be in place
An environment where several agents work on the same process without contradicting each other is defined by verifiable mechanisms, not a policy document.
Corporate identity behind every agent. Each automation acts on behalf of a real person, with the same access the company already controls — never a generic, ownerless account nobody can explain later.
A declared scope per step. Before acting, each agent knows exactly what it can decide on its own and what it needs to hand off. The scope is not discovered during execution — it is defined before it.
Human approval at the point of conflict. When two automations disagree, or one of them goes beyond what it can decide alone, the process stops and asks a person for a decision, instead of resolving by whoever got there first.
A per-step audit trail. Every step records what was decided, with which information, and by which agent, so the disagreement surfaces before it becomes a decision — not during an investigation after the fact.
Approved knowledge as a shared reference. Different agents consult the same current policy base, with a clear owner and version, instead of each automation working off its own copy of the rule.
This is how Skyller was designed: agents with a declared scope per step, human approval at the point of conflict, and an audit trail available at any time.
From silent contradiction to a traceable decision
The most immediate gain is also the easiest to measure: less rework. When disagreement between agents surfaces the moment it happens, someone decides once — instead of the team finding out weeks later, through a customer complaint or an audit, that two different answers came out of the same process.
Organizations need clear boundaries that define which decisions agents can make on their own and which require human approval.
There is a less obvious gain that matters more over time: trust. A team that can reconstruct why an agent decided a certain way ends up trusting the next agent the company puts into production. A team that cannot reconstruct it starts checking every result by hand — and the automation stops saving the time it was supposed to save.
There is also an effect on how fast a company can expand. A company that already knows where each agent stops and asks for approval can build the next automated process on top of the same structure, instead of reopening the authority discussion from scratch for every new agent. That is what separates growing the number of automations from accumulating blind spots.
Before putting two agents into production
- Who decides when the agents disagree? Name the person or the role responsible before turning on the second automation — not after the first incident.
- Does each agent know exactly how far it can decide on its own? If the answer is "it depends," the scope is not declared. It is being discovered in production, one case at a time.
- Is there a record of which agent decided what, and based on which version of the rule? Without it, no audit can reconstruct why two identical requests got different answers.
- What happens when one agent finds a case another has already handled? If the answer is "the second one overwrites the first," the company has a race — not a process.
- Has anyone tested the two agents together, on the same case, before putting both into production at once? Testing each automation in isolation never reveals the conflict — it only shows up when both run on the same real request.
