The launch party for the vendor-inquiry agent was a plate of supermarket brownies in the Thursday standup, which is the correct size of party for a system that still has to survive. Two weeks later, the program lead taped a printout above her desk. It was not the architecture diagram and it was not the go-live announcement. It was a single sentence from a Gartner prediction published in June 2025: over 40 percent of agentic AI projects will be canceled by the end of 2027. Underneath it, in marker, she had written the three reasons Gartner gave: escalating costs, unclear business value, inadequate risk controls. And underneath that, one more line: "None of these is about the robot." This closing lesson of the chapter is about that printout: why the prediction is the most useful document in agent program management, why its three drivers are all failures you already know how to prevent, and the twelve-item checklist that turns an autopsy report into a survival plan.

The Prediction That Names Its Own Killers

Most failure statistics arrive as a number and leave you to guess the mechanism. The MIT GenAI Divide finding, 95 percent of enterprise generative AI pilots with no measurable profit-and-loss return, needed a full autopsy to explain itself. The S&P Global finding, 42 percent of companies scrapping most of their AI initiatives in 2025, up from 17 percent the year before, tells you the scale of retreat but not the cause of it. Gartner's agentic prediction is different, and its difference is a gift: it ships with its own cause-of-death list. Over 40 percent of agentic AI projects will be canceled by the end of 2027, the June 2025 research said, and the drivers are escalating costs, unclear business value, and inadequate risk controls. The same research named the market condition making everything worse: agent washing, vendors relabeling ordinary automation and chatbots as "agents," with only about 130 of the thousands of vendors claiming agentic products judged to be the real thing at the time.

Now read that driver list the way this program has taught you to read every startling number: slowly, and against your own experience. Escalating costs. Unclear business value. Inadequate risk controls. Notice what is not on the list. Not "the models were not smart enough." Not "the technology was immature." Not "agents cannot be built." Gartner is predicting that nearly half of these projects will die, and every single listed cause is a program-management failure: a budgeting failure, a measurement failure, a governance failure. These are the oldest failure modes in the transformation business wearing new clothes, and each one has a known cure. Most of those cures, you already own. That is the strange comfort of this prediction: it is a forecast of organizational malpractice, and malpractice is preventable.

The timing matters too. McKinsey's State of AI research found 62 percent of organizations experimenting with or scaling AI agents, which means the cancellation curve and the adoption curve are climbing the same hill from opposite sides, and they will meet in a lot of steering-committee rooms in 2026 and 2027. Your agent, the vendor-inquiry agent this chapter has fit-tested, overseen, specified, and tested, is now live and on that hill. This lesson is the map of the descent routes: the three ways programs slide off, dissected into their agent-specific mechanics, each answered with the discipline and the artifact that prevents it. By the end, you will hold the chapter's closing artifact, the Agent Survival Checklist: twelve items, three sections, each item naming what you maintain and how often. It is the document a transformer pins above the agent program's desk, right next to the prediction it exists to beat.

Driver One: Escalating Costs, Dissected

"Escalating costs" sounds like a single disease. In agent programs it is three distinct ones, and they respond to three distinct treatments.

The consumption surprise

Traditional software costs what the license says. Agents bill by usage, and agent usage is emergent: the system decides at runtime how many model calls, tool invocations, and retries a case deserves, and nobody signed off on that number because nobody knew it in advance. You met this in the testing lesson as the nine-lookup loop: the agent that answered one routine inquiry correctly but made nine catalog lookups along the way, a defect invisible to any accuracy metric. Multiply that loop by ten thousand cases a quarter and it stops being a curiosity and becomes a line item. Add the retry storms when an upstream API (application programming interface, the connection through which the agent calls other systems) responds slowly, the long-context calls when a case drags a large document history behind it, and the re-runs after failures, and you get the signature cost curve of an unmetered agent program: flat in the demo, gently rising in month one, and vertical the quarter volume arrives. The invoice becomes the first stakeholder to notice, and an invoice is the worst possible messenger.

The cure is not austerity; it is instrumentation you already know how to build. In the instrumentation lesson you learned to wire counters into the process before the pilot touched it. Consumption metering is a counter, and it belongs in the measurement plan from week one: cost per resolved case, computed continuously, published beside cycle time as a first-class metric, with its own rung on the escalation ladder. If cost per case drifts 25 percent above model, someone is paged, exactly as they would be if accuracy drifted. Because that is what it is: cost drift is drift. You built a circuit breaker to stop the agent when its behavior went wrong; the budget rung is the circuit breaker's economic twin, and it stops the program's spend from going wrong silently. Watch cost the way you watch accuracy, and the consumption surprise cannot happen, because there is no surprise left in it.

The integration iceberg

The second mechanism is quieter. The agent worked in the sandbox, so the business case was built on sandbox economics: license, model consumption, a bit of setup. Then production arrived with the nine tenths below the waterline: the scoped database role that took the security team three weeks, the API hardening the integration owner did not budget, the permissions provisioning, and, largest of all, the oversight staffing. Every hour a human spends reviewing the agent's escalations, sampling its resolved cases, and investigating its guardrail events is program cost, and it was estimated, if it was estimated at all, by optimism.

The cure came two levels ago. Level 1's ROI lesson (return on investment, the ratio of what an initiative earns to what it fully costs) taught the full-cost business case: every cost line enumerated, including the verification tax, the ongoing human cost of checking AI output. The agent edition simply adds the agent's line items and prices them before launch. Oversight hours come straight from the Oversight Matrix arithmetic you did in this chapter: reviews per day times minutes per review times loaded hourly cost is not a guess, it is multiplication. Add suite reruns per change (the four test suites do not run themselves for free), log storage, and log review time. None of these lines is exotic. What kills programs is not that the iceberg exists; every serious system has one. What kills programs is discovering it from the deck of the ship. Priced before launch, the iceberg is just geography.

Scope accretion

The third mechanism is the friendliest. A live agent that works attracts requests the way a working intern does: "can it also chase late shipments?" "Can it also update the vendor master file?" Each yes feels like free value, because the agent is already running. Each yes is not free. A new action type means new permissions, new tools, new rows in the failure-mode map, new test surface across all four suites, and new oversight load in the Matrix arithmetic. Say yes casually five times and you have doubled the program's cost and risk without a single decision meeting, which means the escalating-cost story is being written and nobody is the author.

The cure is the charter you wrote before the pilot ever ran. The charter's OUT list, the explicit register of what this system does not do, is not a historical document; it is a living fence, and the change process is its gate. Every "can it also" is a change request, and a change request reprices the program: the new action's cost lines, its permissions, its suite additions, its oversight hours, on one page, before anyone says yes. The SOP's re-test triggers (SOP, standard operating procedure, the written instruction set the redesigned workflow runs on) act as the cost gate: if the change triggers a suite rerun and an Oversight Matrix update, the change request says so and prices it. The answer to "can it also" is never "sure." It is "yes, and here is what it costs," delivered with a straight face and a filled-in template. Half the time, the requester withdraws the request themselves, which is the change process working exactly as designed.

Driver Two: Unclear Business Value, Dissected

The second driver is the one this program has been rehearsing you against since Level 1, and agents give it three new disguises.

The activity mirage, agent edition

Level 1 taught you the usage trap: adoption charts mistaken for business results, logins presented as value. Agents make the trap far more seductive, because agent activity does not just look like usage, it looks like work. The dashboard shows actions taken, cases touched, messages sent, lookups performed: a machine visibly doing things all day. A steering committee watching that dashboard feels productivity in its bones. But actions taken is an activity metric wearing overalls. The profit-and-loss statement does not have a line for messages sent. It has lines that respond to cost per resolved case, resolution time, and error rates, and only those.

The cure is the discipline you built in the measurement chapter, applied without mercy to the running agent. The value metrics were wired to the baseline before launch: cost per resolved case against the baseline pack's number, resolution time against the baseline distribution, quality held inside guardrails. And, this is the part most programs skip, the Delta Table discipline is applied quarterly to the live agent, not just to the pilot that earned the scale decision. A pilot proves value once; a program re-proves it on cadence, or the value quietly becomes an assumption, and assumptions age into fiction. The quarterly Delta refresh is thirty minutes of analysis that keeps the value claim current, caveated, and analyst-proof. Skip it for three quarters and you are exactly the program Gartner is describing: running, busy, and unable to say why.

The attribution fog

Agents rarely work alone. The vendor-inquiry agent resolves the routine lane; humans handle the escalations, the exceptions, and the validation-rejected cases. Eighteen months in, someone asks the reasonable question: of the improvement we claim, how much is actually the agent? If the event log cannot answer, the value claim dies in the fog, because a hostile analyst treats an unattributable delta as a zero. Hybrid flows without attribution produce numbers that belong to everyone, which means they belong to no one.

The cure was designed in the instrumentation lesson: the event log with lane attribution built in. Every case carries its resolution path: agent-resolved, agent-assisted then human-completed, human-only, escalated-and-returned. With lanes in the log, the agent's contribution is measurable per segment, the Delta Table can show agent-lane cost per case beside human-lane cost per case, and the value claim survives the analyst because the analyst can recompute it. Attribution is not something you add when the question is asked. By then the eighteen months of unlabeled events are already unlabeled forever. It is designed in, or it does not exist.

The counterfactual vacuum

The third disguise is amnesia. Eighteen months after launch, nobody in the room remembers what the vendor-inquiry queue actually cost before the agent. The people who ran the old process have moved roles. The old cycle-time reports are in a retired dashboard. When a new executive asks "what are we comparing this spend against?", the program answers with folklore, and folklore loses budget fights to spreadsheets every single time.

The cure is the cheapest one in this lesson, because you already built it: the baseline pack from Level 2, preserved and versioned. The before-photo of the process, its volumes, its cycle times, its error rates, its cost per case, kept where the program can produce it in one motion, updated with a versioned addendum whenever scope changes redraw the boundary. The baseline pack is the program's permanent title deed: the document that proves the land was worth less before you built on it. Level 2's most tedious discipline pays its longest dividend here, years after the week you spent gathering numbers nobody was asking for yet.

Driver Three: Inadequate Risk Controls, and the One New Discipline

The third driver gets the shortest dissection, for the best reason: this chapter is the cure, and you have just spent four lessons building it. Run the recap quickly. Controls bought as features instead of specified as requirements: cured by the Control Spec, your requirements document for permissions, approvals, limits, and logging, and by the seven vendor questions that expose agent washing at procurement time, before a relabeled chatbot is holding write access to your systems. Oversight that erodes under volume: cured by treating the Oversight Matrix arithmetic as a standing check, not a launch check, because the fatigue math that balanced at 60 cases a day breaks silently at 200, and volume changes are exactly when the arithmetic must be re-run. The untested assembly: cured by the four test suites with re-test triggers written into the SOP, so every model update, prompt change, tool change, and scope change re-earns trust instead of borrowing it.

But there is one item this chapter has not yet given you, and it may be the deepest survival mechanic in the lesson. Call it governance visibility: the risk controls must exist, and leadership must be able to see them working. These are two different achievements, and programs die of lacking the second while holding the first.

Think about what a cancellation actually is. It is not a technical event. No model weight ever canceled a project. A cancellation is a decision made by people, usually people two levels above the program, at a moment when their confidence ran out. And confidence is not fed by the controls existing; it is fed by legible evidence that they are working. An executive who hears about a guardrail event through a corridor rumor experiences it as a near-miss and a cover-up. The same executive who reads, in a routine monthly report, "the agent refused one hostile-shaped email; the circuit breaker tripped once on a volume spike and was reset after review" experiences it as a system doing its job. Same events, opposite conclusions, and the difference is entirely in who told the story first and in what format.

Cancellations are decisions made by people who lost confidence, and confidence is fed by legible evidence on a schedule, not by reassurance on demand.

The artifact is the monthly one-page agent report, and the discipline is that it ships every month whether the month was interesting or not. One page: actions taken and cases resolved (labeled as activity context, not as value), cost per resolved case against model, interventions and escapes from the oversight lanes, guardrail events with one-line dispositions, and the current Delta headline. Five sections, fifteen minutes to compile from the instrumentation you already run, and it answers the question "should we be worried?" before anyone has to ask it. When the program eventually needs patience from its leadership, and every program eventually does, the report is why the patience exists: eleven consecutive pages of legible evidence buy the twelfth month's benefit of the doubt. Level 4 will scale this instrument into the value scorecard and the governance committee's standing review; here, at one agent, it is a single page, and it is not optional.

Two Quarters on the Curve: A Survival Story and a Casualty

Here is what surviving the three drivers looks like in practice, told through the vendor-inquiry agent's first two quarters. All numbers are hypothetical and illustrative; the shape is the lesson.

Month 2, driver one attacks. The consumption counter flags cost per resolved case at $2.09 against a modeled $1.10: 1.9 times model, tripping the budget rung on the escalation ladder. Investigation takes a morning: a routine model update has changed the agent's lookup behavior, and the nine-lookup loop from testing is back, now live. The suite-one rerun, the single-action checks, confirms the regression; the prompt fix and re-verification take four days; cost per case returns to $1.14. Total damage: about $3,800 of excess consumption and one uncomfortable Slack thread. Without the counter, this regression runs until the quarterly invoice, costs five figures, and enters the program's story as "the costs are escalating and we do not know why." With the counter, it is a maintenance ticket. Driver 1a, survived by instrumentation.

Month 3, the friendliest attack. Procurement asks: can it also chase late shipments? The old answer is "sure, it already talks to vendors." The change process instead produces one page: two new action types, one new system permission, an estimated $30,000 in build and test-suite extension, and 2 additional oversight hours per week forever, per the Matrix arithmetic. The sponsor reads the page and declines: the late-shipment queue is too small to repay that. The decline is documented in the decision log as a win, because it is one: the OUT list held, the program's cost curve stayed flat, and procurement got a real answer instead of a slow yes that would have become a fast regret. Driver 1c, survived by the charter.

Month 4, driver two's standing exam. The quarterly Delta refresh runs against the preserved baseline pack: cost per resolved inquiry is 41 percent under baseline, attributed by lane (the agent-resolved lane carries the saving; the escalation lane costs slightly more than the old process, and the table says so out loud), with quality guardrails green across the sampled cases. Nobody had to reconstruct anything, because the event log had lanes and the baseline pack had a version history. The value claim is current, segmented, and recomputable. Driver 2, survived by standing evidence.

Month 5, driver three's moment. The monthly report carries two guardrail events: one hostile-shaped email refused by the input guardrail, one circuit-breaker trip on a volume spike, reviewed and reset within the hour. The program lead presents both to the steering committee as the system working, with the log excerpts attached. The committee's recorded takeaway is confidence. Now run the counterfactual: the same two events, unreported, surfacing six weeks later as "did you hear the AI got attacked?" and "apparently it shut itself down one Tuesday." Same facts, and the program is suddenly explaining itself from a defensive crouch. The report did not prevent the events. It prevented the rumor from being the first draft of the record. Driver 3, survived by governance visibility.

The casualty: a composite from the wrong side of the curve

Now the failure story, a compact composite of how the 40 percent actually happens. A mid-size retailer launches five agents in a burst of 2025 enthusiasm: returns, inventory queries, supplier onboarding, marketing copy, and invoice matching. No consumption metering, so month 3 delivers an invoice roughly triple the budget line, and finance opens a file. Value is reported as "tasks automated," a rising activity chart, so when the CFO's analyst goes looking for the baseline in month 7, there is none to find, and the value claim officially becomes folklore. In month 9 a guardrail incident on the supplier-onboarding agent, a bad payment-detail change that a human caught downstream, travels through the organization as rumor, because there was no report for it to travel through. In month 11 a new CFO, holding an invoice file, a folklore value claim, and a rumor, cancels all five agents in one memo.

Including the one that was working. The invoice-matching agent was, by any honest measurement, paying for itself twice over. But nobody had measured it honestly, so its evidence was indistinguishable from its siblings' hope: the same activity dashboards, the same missing baselines, the same absent reports. The good project was executed alongside the bad ones because nobody could tell them apart, and that is the cruelest arithmetic of the cancellation curve: it does not only take the projects that deserved to die. It takes the ones that could not prove they deserved to live. Level 4 will pick this up as the portfolio problem, running many initiatives with shared evidence standards so the strong ones are legible precisely when the weak ones are being culled. Here, at one agent, the lesson is simpler: your evidence is your survival, and it must be built before the CFO changes.

The Agent Survival Checklist

Here is the chapter's closing artifact: the Agent Survival Checklist, twelve items in three sections, one section per driver. Each item names the artifact that satisfies it and the cadence that keeps it alive, because a control without a cadence is a launch decoration. Score your program honestly: green, yellow, or red per item. The checklist is the Gartner autopsy inverted into a maintenance schedule.

Twelve items, and count how many are new. Items 1, 4, and 12 are the only machinery this lesson added; the other nine are the chapter and the Level 2 spine doing their jobs on a schedule. That is the synthesis: you did not need a new methodology to beat the cancellation curve. You needed the disciplines you already own, aimed at the three named killers, and kept on cadence after the launch brownies are gone.

The honest survival rule

One clarification, because without it the checklist becomes a zombie-preservation device. The Agent Survival Checklist keeps agent projects alive except the ones that should die, and those it makes die cheaply and early. The fit test kills the misfit workflow before procurement spends a dollar. The kill condition, pre-committed in the charter, kills the underperformer at week 6 on evidence, not at month 18 on exhaustion. The change process kills the scope creep before it is born. Surviving the curve does not mean zero kills; a program with zero kills is not succeeding, it is not measuring. Surviving the curve means zero zombies and zero surprises: every project either proving its value on cadence or being ended on purpose, with a memo, by its own owner, while the ending is still cheap. A documented kill is a win. That has been true since Level 1, and at agent stakes, with consumption meters running and write permissions granted, it is truer than it has ever been.

And with that, the agent is governed: fit-tested before it was chosen, overseen by designed patterns, specified into its controls, tested before production, and now wrapped in the survival disciplines that keep it funded. Chapter 3.5 widens the lens from agents to every live AI workflow you run: catching hallucinations and drift in production, checking for bias, building audit trails, writing incident playbooks, and turning all of it into continuous improvement. The next lesson starts with the failure mode that never stops mattering: the confident wrong answer, in a live workflow, on a Tuesday.

What to Do Monday Morning

This lesson becomes real when the checklist meets your actual program. The sequence takes one focused week.

1. Add cost per resolved case to your measurement plan today, with a modeled target and a budget rung on the escalation ladder (a 25 percent drift above model is a reasonable first threshold). If you cannot compute it yet, that gap is finding number one.
2. Enumerate your agent's full-cost lines against the ROI worksheet: consumption, oversight hours from the Oversight Matrix arithmetic, suite reruns per change, log storage and review time. Compare the total to the business case leadership last saw, and if the gap is material, brief it now, on your schedule, not the invoice's.
3. Schedule the two standing reviews: the quarterly Delta refresh against the versioned baseline pack, and the monthly one-page agent report, with the first report drafted this week from the instrumentation you already have.
4. Run the change-process math on the pending "can it also" request; there is one, there is always one. Price its actions, permissions, test surface, and oversight hours on one page, and let the sponsor decide with the number in view.
5. Score your program against all twelve checklist items, with honest reds. Every red names its own repair, because every item names its artifact. Pin the scored checklist above the desk, next to the prediction it is built to beat.

Key Takeaways

• Read Gartner's June 2025 prediction as a management document: over 40 percent of agentic AI projects canceled by end of 2027, driven by escalating costs, unclear business value, and inadequate risk controls, none of which is a technology failure and all of which have known cures.
• Meter consumption from week one: cost per resolved case is a first-class metric with its own escalation-ladder rung, because agent usage is emergent, cost drift is drift, and the budget rung is the circuit breaker's economic twin.
• Price the integration iceberg before launch with the full-cost ROI worksheet: oversight hours from the Oversight Matrix arithmetic, suite reruns, permissions work, and log review are line items, not surprises.
• Enforce the charter's OUT list through the change process: every "can it also" request is repriced on one page, and "yes, and here is what it costs" replaces "sure" as the only allowed answer.
• Re-prove value on cadence: quarterly Delta refreshes against the preserved, versioned baseline pack, with lane attribution designed into the event log, so the claim survives a hostile analyst eighteen months in.
• Ship the monthly one-page agent report every month, because cancellations are confidence decisions, and guardrail events presented on schedule read as the system working while the same events arriving as rumor read as cover-up.
• Score your program against the twelve-item Agent Survival Checklist with honest reds, knowing nine of the twelve items are disciplines this program already taught you, now placed on a cadence.
• Remember the honest survival rule: the checklist does not prevent kills, it prevents zombies and surprises, and a documented, cheap, early kill remains a win at agent stakes.