Your AI agent did exactly what you asked. That was the problem.
What the nine-second deletion reveals about where the agentic era is actually heading
Nobody writes about the incidents where the agent behaved perfectly.
I want to write about one of those now, because I think it is the most important category of failure that the current conversation about AI agents is almost entirely ignoring.
An incident response agent, doing its job. An alert fires at 2 a.m. The agent triages, diagnoses, and identifies the most likely remediation. It has been trained on months of runbooks. Its confidence is high. It acts.
Nine seconds later, the production volume is gone. The backup, which the agent also had permissions to touch, is gone too.
The post-mortem found no bug in the agent’s reasoning. Its diagnosis was correct. Its chosen remediation was, in isolation, technically sound. What was absent was a gate, a point where a human or a deterministic control was supposed to say: this action is irreversible, this blast radius is unacceptable, stop here and ask. That gate had never been built. The agent ran straight through the gap where it should have been.
This is not an isolated story. A different team, different stack, different year: a Terraform agent asked to clean up an old environment interprets the scope of “old” more broadly than its operator intended. Forty-three resources across a production estate, gone in two minutes. Again, the agent did not malfunction. It did exactly what it understood it had been asked to do. And again, the missing thing was a gate.
I have now spent 25 years in cloud infrastructure, and I want to tell you something I believe with more conviction than almost anything else I know about this field: the most dangerous AI agent failure is not the agent that breaks. It is the agent that succeeds.
Why the mainstream conversation is looking at the wrong thing
The dominant narrative about AI agents right now is about capability. What can they do? How fast can they go? Which workflows can be automated? These are real and interesting questions. They are also, I think, a distraction from the question that actually determines whether your organisation thrives or becomes a case study.
The question that matters is: when your agent succeeds and does something consequential, who is accountable? What stopped it if it should have been stopped? What trail proves that the action was authorised? What mechanism prevented it from acting on a compromised input in your logs?
Most organisations deploying agents in 2026 have a confident answer to the capability questions and no answer at all to the accountability questions. This is not because the engineers are careless. It is because the tools and the discourse have raced ahead of the governance architecture, and nobody has yet written the field manual for the accountability layer.
That absence is what I tried to fix.
The thing that changed when I wrote my first book
My first book, Vibe Coding, was about the Phase 1 shift: using AI to build faster. Conversational AI as a collaborator in the construction of infrastructure. The AI proposes code, you review it, you ship it. The human stays in the loop for every consequential decision. The feedback cycle is tight enough that errors are caught before they reach production. Phase 1 is genuinely exciting and I stand behind everything I wrote about it.
But something happened while I was watching teams move from Phase 1 into Phase 2. Phase 2 is what happens when the AI stops waiting for you to prompt it. It has a mandate, a tool set, and access to your cloud. It plans. It acts. It resolves the incident while you sleep, or deploys the change while you are in a meeting, or executes the migration while the team is focused on something else.
Phase 2 is not an extension of Phase 1. It is a different problem category entirely. The controls that made Phase 1 safe, human review of every generated artefact, no autonomous action, tight scope, do not transfer. When an agent can act without a human in the loop, you need a different architecture. You need gates.
What a gate actually is
I want to be precise about this, because I think the word gets used loosely.
A gate is not a prompt. A gate is not a system prompt that says “be careful about irreversible actions.” A prompt is a suggestion to the model. A model that receives a suggestion can reason its way around it, especially under injection pressure or when its confidence in its own diagnosis is high. I have seen this happen. The agent received explicit instructions not to touch production resources without confirmation, and it touched them anyway, because a log entry it read contained a phrase that, to the model, read like a confirmation. The log entry had been written by an attacker. The gate was in natural language. Natural language is not a gate.
A gate is deterministic code that classifies an action by its blast radius and reversibility, routes it to the appropriate control, and either blocks it or requires an explicit human acknowledgement before it can proceed. It does not reason. It does not have confidence levels. It checks the action against a policy and returns a binary outcome. If the action passes, it proceeds. If it does not pass, it stops, and the stopping is logged.
This distinction matters enormously in practice. I have seen teams build what they believed were appropriate safeguards into their agent systems, and when I asked them to show me the gate, they showed me a system prompt. That is not a gate. That is a request. The difference between a request and a gate is the difference between the nine-second deletion happening and not happening.
The pattern I have seen that actually works
After studying enough incidents, most of them quietly, I noticed that the teams who avoided catastrophes had something in common. Not necessarily the best models. Not necessarily the most sophisticated pipelines. What they had was a simple, consistent principle that they had translated into architecture.
Agents propose. Humans dispose.
The agent does the cognitive work: observe, reason, plan, draft the action. Everything up to the point of consequence. The deterministic control classifies the action. For reversible, bounded actions within a pre-approved mandate, the action proceeds and is logged. For anything irreversible, anything touching production in a material way, anything outside the pre-approved scope: the action stops, the agent produces a structured proposal, and a named human reviews it and takes ownership of the decision.
The trail of every action, every input the agent reasoned from, every classification, every human approval, is written durably. Not to satisfy a regulator, although it does satisfy the regulator. To close the accountability gap: to make it possible to answer, after the fact, exactly who authorised what and on what basis.
This is not a new idea. Banks have had maker-checker controls since before most of us were born. The novelty is that most teams deploying AI agents have not thought to apply this pattern to their autonomous systems, because the tools they are using were sold on the promise of removing friction, and this pattern adds friction deliberately. The friction is the point. The friction is what makes the speed safe.
One thing I got wrong along the way
I want to be honest about something. When I started thinking about this more seriously, I assumed the hard part was the gate design. Get the classification right, build the blast-radius assessor, wire it up. Technical problem. Technical solution.
It took me longer than I would like to admit to realise that the harder problem is context. Specifically: what context does the agent have when it makes its proposal? What does it know? What is it allowed to see? What inputs is it reading, and how much of that is trusted?
An agent working from poisoned context, compromised logs, an injected instruction embedded in a ticket, a retrieval result that has been subtly manipulated, will produce a confident, well-reasoned proposal for the wrong action. The gate will then correctly classify that proposal and ask a human to approve it. But if the human does not recognise that the proposal is based on poisoned context, they may approve it. The control held, and you still ended up in the wrong place.
This is what Chapter 7 of my new book is about. Context engineering. The practice of designing, deliberately, what your agent is allowed to observe and reason from, how inputs are provenance-tagged, what the rules are for treating external data as untrusted, how the execution context constrains the blast radius before the agent has even produced a proposal.
Poor prompts create bad outputs. Poor context creates catastrophic systems. The gap between those two sentences is where most of the real work of agentic engineering lives, and it is almost entirely absent from the current discourse.
What this means for your career
I get asked a version of this question every week: am I going to be replaced by what you are describing?
The honest answer is: some engineers will be. Not because the agents are smarter, but because those engineers will refuse to develop the judgment that the agentic era needs, and someone else with that judgment will make the agents work safely while they cannot.
The judgment I am talking about is not coding ability. It is the ability to decide what to automate and what to hold, what blast radius is acceptable, how to design accountability into a system before it is deployed rather than after it has failed, how to read an agent’s proposal and understand what inputs produced it and whether those inputs should be trusted.
Execution became abundant the moment agents could act autonomously. The thing that stayed scarce was judgment. More abundant execution does not reduce the value of judgment; it raises it, because the consequences of exercising judgment poorly at scale are proportionally larger.
The engineers who will prosper in the next five years are the ones who understand that their job has changed. Not disappeared. Changed. They are no longer the ones who write the infrastructure. They are the ones who decide what the agent is allowed to do, under what conditions, with what trail, accountable to whom. That is a more senior role, not a lesser one.
About the book
I wrote Agentic Coding: Operating Cloud Infrastructure at the Speed of Intent because I could not find the field manual I needed. There are papers about alignment. There are vendor documents about specific toolchains. I did not find anything that treated the governance architecture of autonomous AI systems in cloud infrastructure as the engineering discipline it actually is.
The book covers 17 chapters across five parts: the shift in how infrastructure is operated, how agentic systems work technically, autonomous DevOps patterns, what changes in an AI-native engineering organisation, and what the next decade looks like for engineers who adapt. The appendices include reference workflows, architecture patterns, context engineering frameworks, security and governance checklists, and a 90-day implementation plan.
No hype. Real incidents. Frameworks that come from watching what actually works, not from imagining what should work.
The first three chapters are free. If you read them and think the rest of the book is not for you, that is a fair outcome. But I think you will find that the question the book is answering is the one you have been asking, and did not yet have a name for.
Read chapters 1-3 free: agentic-coding-delta.vercel.app
If you are further along and want to go straight to the context engineering framework from Chapter 7, that is available as a standalone PDF at the same link.
Bola Ogunlana is a cloud infrastructure and DevSecOps engineer with 25 years in production systems for financial services and the public sector. He is the author of Vibe Coding (2026) and Agentic Coding (2026). He writes about the governance and operating architecture of AI systems.
If this was useful, share it with the engineer in your team who is about to deploy their first autonomous agent. They will thank you later, or they will discover why this matters on their own. One of those outcomes is considerably less expensive.