Your Agents Are in Production. That’s When They Get Rolled Back.

The second AI reckoning is not about cost. It is about control.

A few weeks ago I wrote about the first AI reckoning, the one on your invoice. Token prices fell about 98 percent and enterprise bills tripled anyway, because the unit of work quietly grew from a single call into an orchestrated agent. The fix was token discipline: stop measuring tokens consumed and start measuring cost per resolved task.

This is the second reckoning, and it is the one that takes systems down rather than budgets. Agents have crossed from demo to production this year, and that crossing is exactly when they start getting pulled back out.

Two numbers that do not agree

Look at what enterprises are doing with agents and you get whiplash.

On one side, the spend. Agent software is on track for roughly $206 billion in 2026, up about 139 percent in a year, the fastest-growing slice of enterprise software. Gartner expects 40 percent of enterprise applications to embed task-specific agents by the end of the year, up from under 5 percent in 2025. The money has made its decision.

On the other side, the body count. Gartner also projects that more than 40 percent of agentic AI projects will be canceled by 2027, and that a matching 40 percent of enterprises will demote or decommission autonomous agents because of governance gaps found only after a production incident.

Read those together. Companies are buying agents as fast as they can and killing them almost as fast. The bottleneck is no longer whether an agent can do the work. It is whether anyone can keep it inside the lines once it does.

The mistake that causes the rollback

Almost every rollback I have seen, and almost every one in the data, traces back to a single confusion. Teams reason about how capable an agent is. The thing that actually hurts you is how much it is allowed to touch.

Those are different axes, and conflating them is the whole problem.

A highly capable agent with narrow access is safe. It can be as clever as you like, because the worst it can do is bounded by the one system and the one scope its job requires. A simple agent with broad access is a loaded gun. It does not need to be smart to wire the wrong customer’s data into an email or push a bad change into a system of record. It just needs permission, and too many agents are handed permission to everything before anyone has scoped them to anything.

The target is the unglamorous corner: high ability, narrow access. A capable agent that can only reach what it needs. The danger zone is not a smarter model. It is a model plugged into your whole stack because wiring it up was easier than scoping it.

Why the gap shows up late

The reason this keeps catching teams is timing. Agents look fine when you are watching them.

In a pilot, the agent handles the happy path beautifully. In the demo, it gets signed off. Then it scales, and volume drags in the edge cases nobody scripted. The agent does something technically within its permissions and completely outside anyone’s intent, and the way you find out is an incident, not a code review.

Governance designed after the incident is the most expensive kind of governance there is. By then the agent is in production, touching real systems, and the conversation has moved from engineering to legal and comms. The cheap version is boring and it happens before launch: decide the agent’s scope, its budget, and the conditions under which it gets switched off, while changing those things still costs nothing.

One policy for every agent is itself a failure

The instinct, once a team gets burned, is to clamp down uniformly. Write one governance policy, apply it to every agent, call it handled. Gartner’s specific warning is that this backfires, and it is right.

Uniform governance fails in both directions at once. It smothers the harmless read-only assistant in approvals it does not need, so people route around it. And it under-controls the money-moving agent, because the same policy that felt heavy for a summarizer is dangerously light for something that touches customer accounts.

The workable approach tiers agents by blast radius, by what they can actually break, and escalates controls to match. A tier-one agent that only reads and suggests needs little more than logging. A tier-two agent that acts reversibly in a sandbox or staging system needs approvals. A tier-three agent that acts in your systems of record, moving money, changing customer data, sending external communications, needs the full treatment: least-privilege scope, a complete audit trail, and a kill switch someone is watching. Match the control to the damage, not to a policy template.

Follow the acquisitions

If you want to know where the hard problem actually is, watch what the big vendors are buying. In a matter of weeks this spring, Asana bought StackAI, Palo Alto bought Portkey, Coupa bought Rossum, Salesforce bought Contentful, and Vertice bought Vendr.

Every one of those is a purchase of the ability to act, not advise. Generating good output is commoditized now; every model does it. The prize, the thing worth acquiring, is reliable and governable execution inside the systems where business actually runs. The Asana deal said it plainly: its agents could plan and track work but could not execute end to end inside Salesforce and Oracle, so it bought the company that could.

That is the buyer’s signal, and it is worth taking seriously. When five enterprise vendors acquire execution and control layers almost simultaneously, they are telling you the model was never the moat. Reliable, scoped, auditable action inside your systems is. There is a related trap to watch on the way in: of the thousands of vendors now calling themselves agentic, Gartner reckons only around 130 are real. The rest is agent washing, a chatbot in a new jacket. The question that separates them is simple. Does it act, or does it just answer, and can you scope, audit, and kill it.

Set the bar, then hold it

The discipline that fixes this is the same one from the cost reckoning, pointed at control instead of spend. You decide the boundaries before the agent runs. The agent does its job inside them. You watch a real record after. The rollbacks happen when teams do the middle part and skip the other two.

Setting the bar means least-privilege access to one scope, a spend budget, an explicit list of which actions require a human in the loop, and the conditions that trip a kill switch. All decided up front, when they are free to change.

Holding the bar means an auditable log of every action the agent took, monitoring sized to its blast radius, alerts the moment it behaves outside its scope, and the organizational willingness to pull it the instant it breaches. Not a quarterly review. A switch someone can flip today.

This is the through-line of both reckonings. The cost one said: grade an agent on what a finished task costs you. The control one says: grade it on what it is allowed to touch, and be able to prove it. Same move in both cases. Set a bar before, hold it after, on a number or a boundary that actually means something.

The pattern under both reckonings

It is tempting to read all of this, the tripled bills and the rolled-back agents, as the air coming out of the AI balloon. It is the opposite. This is what it looks like when a technology stops being a demo and becomes infrastructure. Demos do not have budgets or blast radii. Production does.

The teams that come out of this ahead are not the ones that deployed the most agents or the fewest. They are the ones that learned to scope before they shipped and audit after, who treated an agent’s access as something you specify on purpose rather than grant by default. The first reckoning taught the industry what a finished task costs. The second is teaching it what a finished task is allowed to do. Both lessons are the same lesson, and both arrive the same way: through a bill, or an incident, that nobody scoped in advance.

Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.

This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers. We’re always looking for writers. If you’re building with AI and have something worth sharing, reach out.

My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.

My books on Amazon: Claude Code for Everyone Else and From Vibe to Production.

I also take on a small number of mentees one-on-one on MentorCruise.