At 06:14 on a Tuesday in March, an inference workload at an AI data center I will call Sable Creek sees a traffic spike. A workload-management agent, watching latency climb toward a contracted ceiling, asks the scheduler for more GPUs. The scheduler evicts low-priority training jobs. A power agent sees the new allocation push a rack into a higher tariff tier and migrates the workload to another cluster. A networking agent reroutes the fabric. A security agent sees unfamiliar flows between workloads that were never connected before, cannot see the migration that caused them, and does exactly what a good security agent should do: it escalates, isolates the workload, and opens containment.
The containment quarantines a slice of the inference service. Latency gets worse. The workload agent asks for more capacity. Around the loop again.
At 06:21 the pager fires. The shift lead reads the console top to bottom: GPUs healthy, fabric healthy, power inside contract, security one open investigation, severity moderate. Nine agents, every one reporting normal operation against its own objective, and a facility eating itself. Nothing is malfunctioning. Nothing is under attack. There is no bug to find, because there is no bug.
Sable Creek is a composite, assembled from ACG Research engagements with AI data center operators, carriers, and hyperscalers, and the numbers in this post are stand-ins. But I have seen versions of that morning. So have many of my clients. I have spent the last two years trying to name what happened in it, and the name I landed on is the title of my new book: Conflict of Intent.
The definition
Here is the only definition I use, and every clause is load-bearing:
Conflict of Intent is the condition in which two or more authorized decision-makers, whether agents, automation, or humans, each act correctly on their own objective, policy, and information, and together produce an outcome that the organization that deployed them would not have chosen. Nothing is broken. The harm is in the composition.
Authorized matters because a conflict needs no intruder. Prompt injection and agent hijacking are attacks, and attacks have their own discipline. A conflict is what the system does to itself, with everyone's credentials in order.
Correctly matters because there is no component to fix. The security agent at Sable Creek was right. Given flows it had never seen and no knowledge of the migration, escalation was the correct call, and a security agent that failed to escalate on that evidence would be the one needing repair.
Together matters because the harm is a property of the joint outcome. It cannot be found by inspecting the agents one at a time, which is exactly why single-agent evaluations, single-agent audits, and single-agent red teams miss it.
Why this is new, and why it is arithmetic
Every prior era of infrastructure put its risk in execution or access: the system did what it was told, and the open question was whether it did it correctly. Agentic systems construct what they do. The risk has moved upstream, into the choice itself.
The reason you cannot manage that risk the old way is arithmetic. Sable Creek runs 120 agents at an average of one decision every two seconds: about 5.2 million decisions a day. Its overnight staff is three people. If a competent human review of one consequential decision takes eight minutes, two reviewers working around the clock can perform 360 reviews a day. That is one review for every 14,400 decisions.
No human operations team can review these decisions in real time, or even read them. The window in which a person might intervene does not exist for individual decisions. It exists, if it exists at all, for the policies under which decisions are made. An organization that moves its agents to machine speed while leaving its oversight at document speed has not automated its operations. It has unhooked them.
The accident was visible in the org chart
Here is the cast at Sable Creek, as a table rather than a scene. Read it row by row and it is a reasonable org chart. Every objective is sensible, every owner is defensible, and no team on this list did anything wrong.
Now read it column by column. The cadence column spans four orders of magnitude, from 100 milliseconds to five minutes, so the fast agents will always act inside the slow agents' blind intervals. The "Sees" column is the dangerous one: the rows barely overlap. The power agent sees draw but not workload identity. The security agent sees flows but not power events, and that single missing column is the entire accident.
Each agent's context window was scoped, reasonably, by the team that owned it. Nobody scoped the composition, because the composition was nobody's objective. That is now the first question I ask in any deployment review: not "is each agent well built?" but "who owns the fleet's blind spots?"
Three tests, so the term stays honest
A concept with this much reach needs a gate. If every consequential incident can be relabeled a Conflict of Intent, the term is marketing. So every incident passes through three tests, in order.
Test one: is every component doing what it was built to do? If not, it is a failure, and failure is a mature discipline with mature tools. Knight Capital in 2012 lost over $460 million in 45 minutes because stale code sat on one of eight servers. That is a deployment failure, not a Conflict of Intent, and a framework that cannot bring itself to say so has stopped making distinctions.
Test two: are there two or more decision-makers with distinct objectives, policies, or information? If one agent surprised its own designer, that is a specification failure. Fix the goal, the policy, or the context channel.
Test three: would the organization, shown the joint outcome, reject it? If the answer is no, you have coordination cost, the ordinary friction of concurrent actors. Worth engineering down, not a pathology.
The 2010 Flash Crash passes all three. So does Überlingen in 2002, at the human-agent boundary, and the decade of work that followed, giving the onboard collision-avoidance advisory explicit precedence over a conflicting controller instruction, is the best worked example I know of what fixing a Conflict of Intent looks like. Not a smarter system. A written precedence, enforced.
Good engineering hides the problem
The most uncomfortable finding in the book is this: strong failure-handling machinery actively conceals conflict.
A conflict's early symptoms surface as small, recoverable failures: a timeout here, a retried migration there. A well-built resilience layer absorbs them, exactly as designed, and every absorbed symptom is scored as a success. When one is large enough to warrant a postmortem, the postmortem examines the failure that was recovered, finds the recovery worked, and closes, because postmortem templates ask what broke and nothing broke. The conflict stays resident in the structure that produced it.
I have walked into more than one operations review where the resilience metrics were excellent and the conflict pathology was severe, invisible precisely because the resilience was so well developed. The cheapest conflict detector an organization can build is a recovery log clustered by the pair of agents involved. Not "how often do we recover" but "how often do we recover from the same two agents, in the same direction, with the same compensation." Almost nobody builds it, because the recovery log is filed under success.
What the morning cost
Put stand-in numbers on the 41 minutes at Sable Creek. SLA credits for the financial tenant's degraded latency: $38,000. Five evicted training jobs, two with restart penalties: $54,000. A sustained power-tier step: $9,000. The false-positive investigation and the compliance retention action it triggered: $4,000. Sixty person-hours across three teams to trace and settle it: $12,000. Total, before reputation: about $117,000, for a morning in which nothing broke, nobody erred, and every agent will pass its next review.
Later in the book I replay the same morning through an arbitration engine that can see the migration as an in-flight commitment and knows that eviction and isolation are costly to reverse. The bill in that telling is under 40 milliseconds of added decision latency across nine agents, zero escalations, zero SLA credits, and one line in an enforcement log. The difference is not intelligence. Every agent is exactly as smart in both versions. The difference is that someone, at design time, wrote down who wins.
Where to start: classify what can be taken back
If you take one mechanism from this post, take reversibility. Every action an agent can take is classified before deployment into one of four classes, and the class assigns the burden of proof.
At Sable Creek, the scheduler's eviction tool and the security agent's isolation tool are both R2: costly to reverse, and therefore owed synchronous arbitration. The tool schemas knew nothing about that, which is why two R2 actions fired inside the same second with nothing between them. The ladder is also how you spend human attention rationally at 5.2 million decisions a day: not on decisions, but on the classes where reversibility says it matters.
The eight practices
The framework's working half is eight practices, each with an artifact that exists if the practice is real. A practice without its artifact is an intention.
The practices form a chain, and the dependency runs one way. Establish the intent hierarchy first: it is the single practice whose presence most reliably predicts a deployment's ability to manage its own conflicts, and it costs approximately one meeting and one page. Move hard constraints out of prompts and into guardrails, because a policy stated as a prompt is not enforced, it is encouraged. Make every consequential decision reconstructable. Tier the human loop by reversibility. Put stability above local optimization. Deploy arbitration, partitioned by domain. Validate in a twin before production meets the composition. Quantify in units the business respects.
The first three are a paper quarter. No new machinery runs in production, and the quarter still changes everything, because it is the quarter in which the organization writes down, for the first time, who wins.
A year later
Same facility, same 06:14, same nine agents plus four new ones. The scheduler proposes evictions, clears a protected-jobs constraint, and costs six milliseconds of arbitration. The power agent's migration meets a commitment tie-break and takes the uncommitted pool first. The security agent reads flows annotated with the migration it can now see, and scores nothing. At 06:14:09 the episode is over, in the sense that there is no episode.
Nothing in that paragraph required a smarter model. What changed is that the organization wrote down who wins, classified what can be taken back, budgeted its own attention, built the engine that enforces all three, and rehearsed the composition before production met it. The capability was never the constraint. The composition was.
Gartner now predicts that by 2027, forty percent of enterprises will demote or decommission autonomous agents because of governance gaps identified only after production incidents. Those write-offs will be booked as AI failures. In most of them, the model will have done exactly what it was asked. Calling them AI failures is how an industry teaches itself the wrong lesson twice.
Every agent was right. Whether the system is also right is not up to the agents. It is up to us.
This post introduces the framework from my book When Every Agent Is Right: Governing Agentic AI at Machine Speed (ACG Research, 2026), which builds out the taxonomy, the arbitration engine specification, the reference architecture, and a four-quarter build plan. Over the coming weeks I will take the pieces apart one at a time here: the crosswalk, the arbitration trilemma, the attention budget, and the security model for when the attacker is a prompt. If you run agents in production and you recognized your own facility somewhere in the morning above, I would like to hear about it.
Ray Mota, Ph.D., is CEO and Principal Analyst at ACG Research. rmota@acgcc.com
Originally published on Ray Mota's Substack. Subscribe to get new analysis by email.
