Gartner put a number on the coming agent shakeout. Which side of it you land on is decided before the first agent runs, by a dimension most teams never scope.
An agent in your operation takes a wrong action at two in the morning. A purchase order to the wrong supplier, a refund that should have been held, a message sent to a list it should never have touched. The question that decides everything is not whether the agent was smart. It is how much that one action had cost by the time anyone noticed, and whether any of it can be pulled back.
That is the question Gartner was really answering when it predicted that over 40% of agentic AI projects will be canceled by the end of 2027. The figure gets quoted as if it landed last week. It did not. Gartner published it in June 2025 and named three causes: escalating costs, unclear business value, and inadequate risk controls. A year of re-coverage has stripped the date off the number, but the prediction window is already half spent.
None of the three reasons is the model
Read the three causes again. Escalating costs. Unclear business value. Inadequate risk controls. Not one of them is a limit of the model. Drop the most capable model released this year into a project with no defined outcome and no owner, and you get a more articulate version of the same failure. The programs that die in 2027 will not die because the agent could not reason. They will die because no one decided, in advance, what the agent was allowed to break.
This is the uncomfortable part for teams who bought the capability and skipped the operating discipline. The demo works. The pilot works. Then the project moves toward production, someone finally asks what happens when the agent is wrong, and the answer is a long pause. That pause is what a cancellation sounds like, a few budget cycles early.
Blast radius is the dimension that decides
There is a specific property that separates the agents that survive from the agents that get scrapped, and it has a name. Blast radius: when an agent acts wrong, how large is the damage, and how reversible is it.
An agent that drafts a recommendation has a blast radius of nearly zero. If it is wrong, you discard the draft and it asks again tomorrow. An agent that moves funds, commits an order, or issues a refund has a blast radius measured in real money and real trust, and much of what it does is committed the instant it fires. Same underlying technology. Opposite risk. The difference is not intelligence. It is what the action touches and whether you can take it back.
This is why two organizations can deploy the identical agent and reach opposite outcomes. One staged the action, put a ceiling on it, and caught errors before commit. The other pointed the agent at production with unbounded authority and monitoring that only noticed after the fact. The first has a tool. The second has a liability that has not gone off yet.
Five questions that sort a survivable agent from a scrapped one
For every agent workflow you are running or planning, the answers to five questions tell you which side of the number you are on.
What is the worst realistic outcome of a single wrong action: a reversible inconvenience, a recoverable loss, regulatory exposure, or irreversible harm. How is a wrong action caught: a guardrail before commit, monitoring after commit, or a human noticing downstream. What can actually be rolled back, and what is committed the moment it fires. Is there a bounded limit on how much damage one agent can do before a human is forced in, or is autonomy unbounded once granted. And if the agent began acting wrong at two in the morning, how long until someone knew, and how long from knowing to stopped.
A program that cannot answer these is not more advanced than one that can. It is closer to the 40%.
The scrap happens at scoping, not at deployment
The failure feels like it happens in production, the moment the wrong action fires. It actually happened much earlier, at scoping, when the blast radius was left at its default setting of unbounded and no one wrote that down as a decision.
This is the other half of a gap I described in Your Agents Are Using Someone Else's Credentials: authority handed over without boundaries. Borrowed authority sets how far an agent can reach. Blast radius sets how much it can break before you can stop it. Put them together and you have the whole of what When You Deploy the Agent, You Own the Mistake named. The mistake is committed, and it is yours.
Containing it is not model work. It is operational work: staging irreversible actions, setting per-action and cumulative ceilings, moving detection ahead of commit, and shortening the time from wrong action to human override. It is the least glamorous line in the deployment plan, and the first one cut when the project is sold on the strength of the demo.
The window is real. It is just not the window you think.
The urgency around agents is usually pitched as speed. Move first, deploy fast, do not be last. Gartner's number points the other way. The organizations on the safe side of 2027 will not be the ones that moved fastest. They will be the ones that scoped blast radius before they scaled, and can name, for every agent, the ceiling on its authority and the person who can shut it off.
The strategic window and the urgency window are the same window here. They just do not feel the same until one of them has already closed, quietly, in a budget review, as a program that could not answer five questions gets reclassified as a pilot and wound down. Four in ten will. The work that keeps you out of that number is available now, and it costs less than the program you would otherwise scrap.