Every AI deployment produces wrong answers. The ones that survive are the ones where something was already positioned to catch them.
AI use case selection comes down to two people. The product leader deciding what goes into the next release, and the application leader deciding what gets funded next year. Neither is stuck on whether to bet on AI. Both are stuck on which bet, out of a list longer than the money.
I have sat in both chairs. On the provider side I held a backlog against a release schedule that would not fit it, and what sorted the list was what got measured: revenue, retention, NPS. We kept no score for whether a shipped feature was being used broadly.
On the customer side the business units owned prioritization inside their own budgets, and the list was never centrally held. Both chairs had numbers, and the numbers were about something else.
Every one of those lists now has agents on it, and almost no evidence about agents exists. Roughly one enterprise in six has deployed an agent, and few have run long enough to show whether they stick.
Which leaves the AI deployments that did stick. The useful thing to do with them is not to copy them. It is to work out what made them stick, because that is the only evidence AI use case selection currently has.
Something Has to Catch the Wrong Answers
Three things can do it, and a fourth appears once AI starts acting
Every AI deployment produces some amount of wrong output, and something has to catch it. Better models reduce the amount. They do not remove the need for somewhere to put what is left.
Call that thing the absorber: whatever is already positioned to catch what AI gets wrong. It is why deployments that look nothing alike survive for the same reason.
Two things the absorber is not. It is not an argument that accuracy is irrelevant, because a workflow with an absorber still fails if the error rate swamps it. And it is not a one-time hurdle. Acceptance is a one-time hurdle and training clears it. This one gets paid per use.
Here are the three.
A reviewer. Detection is assigned to somebody. A clinical note gets signed. Generated code goes through review and a test suite. The variance arrives in front of somebody whose job is to catch it, and that person was staffed and budgeted before AI showed up.
A bounded answer space. Variability is constrained before detection is needed. Support on a documented product. Routing against a fixed taxonomy. Extraction against a known schema. The set of correct answers is small enough to enumerate, so a narrow domain does not need a reviewer because it does not generate much to review.
Cheap wrongness. Detection can be external or delayed, and both the consequence and the correction cost are low. Cheap does not mean harmless. Some assistant answers work this way: the customer notices, nothing was committed, the answer is discarded. An answer about a refund, a contract term, or a medication is not cheap wrongness at all, and a wrong posting to the general ledger is neither noticed nor cheap.
One clarification, because the rule is easy to misread. This is not an argument for preserving manual review, which is sometimes exactly the waste worth removing. The instruction is to find what currently absorbs the error before deciding what to do about it. Two things do not work. Removing it without noticing it was there, and failing to build one that will clearly be needed.
Which gives a ranking rather than a rule. Best, deploy where an absorber already exists. Acceptable, deploy where the prize justifies building one, deliberately and with a budget. Bad, deploy without noticing one has to exist. Most stalled AI deployments are that last one, and almost none were scoped that way on purpose.
The three absorbers are not equals either, and manufacturing worked this out long ago. Advising manufacturers, the phrase was that you cannot inspect quality in, you have to build it in. A reviewer inspects. A reconciliation sweep inspects later. Only the bounded answer space builds it in, by constraining the process so there is less to inspect.
Four Positions, Not Three
What the output is, and when wrongness gets caught
What has stuck falls into three clusters with nothing obvious in common. Document extraction and clinical notes, where somebody was already reading the output. Customer service assistants, where nobody reads what they produce. Payment matching and journal entries, where the work runs straight through and a reconciliation sweep catches what went wrong.
All three work. They are three positions on the same two questions.
What is the output? Language is advisory. Somebody can read it, ignore it, throw it away. Action is a change to a system of record, and it has already happened by the time anybody looks.
When does wrongness get caught? Before it takes effect, or after.
| Caught before | Caught after | |
| Language | The reviewed | The unreviewed |
| Action | The gated | The audited |
The reviewed is language caught before it counts, read by somebody whose job already included reading it. The largest cluster in production and the least discussed, because nothing about it looks like a breakthrough.
The unreviewed is language with detection deferred to the recipient. That works only because the domain is narrow and a wrong answer costs little enough that escalating is cheaper than being annoyed. The organization has not built an absorber here. It has outsourced detection to somebody who is not a reliable inspector.
The audited is action caught after, and it needs three things rather than one. Logged, surfaced in reconciliation, and reversible. Logging alone is not an absorber. An irreversible action with a perfect audit trail is still irreversible, and all the log does is tell you precisely what you cannot take back.
That last requirement is not on the list of three, and it should be. The absorbers were built from the language side, where the recipient detects and there is nothing to undo. In action, a log detects and the undo has to exist. Reversibility is a fourth absorber that only appears once output stops being advisory.
The gated is action caught before. The agent prepares and a person commits. It is the shape behind the clearest early agent successes, and it is where manufacturing puts inspection when a process is not fully capable: at the last operation before the part ships.
It is also the position nobody is discussing. Not in the vendor pitches, which sell autonomy. Not in the governance advice, which sells controls. As agents move from language to action, the two action positions become the ones that matter, and the market has no word for either.
Agents Attack the Absorbers
Why this gets harder rather than easier
The obvious objection is that this is a snapshot. Agents are coming, autonomy increases, and the absorber question fades as systems get good enough to trust.
The shift is real. OpenAI’s enterprise reporting has corporate usage moving toward delegated execution, with the majority of its corporate output now running through an agentic product rather than a conversational one. But increasing autonomy puts pressure on all of them at once.
Step-level review becomes economically difficult. Inspecting every operation in a twenty-seven step process is a second process that costs more than the one it watches. So review moves to the outcome, which catches a wrong result rather than a wrong path.
The bounded answer space is what agents are sold as escaping. An agent that can rebook a flight, process a return, update an account, and post a transaction has an action space that is combinatorial rather than enumerable. Unboundedness is the pitch.
Reversibility inverts. An assistant produces words a customer can discard. An agent writes to a system of record. The refund is issued, the record updated, the message sent. Cheap wrongness was carrying most of the load in customer service, and executing rather than answering removes it.
So the absorber problem sharpens as autonomy increases, and the market is moving toward the configuration where every absorber is weakest. Seventeen percent of enterprises have deployed an agent, and Gartner projects more than forty percent of agentic projects cancelled by 2027.
The Inversion
Why AI use case selection keeps picking the wrong first target
Product teams and buyers both look for the process with the most manual effort, because that is where the savings math is largest. Highest headcount, most repetitive work, biggest number on the slide.
That process is frequently the one with no absorber. High manual effort often means the work is carried entirely by a person, with no second pair of eyes and no fixed answer set. Which is the exact profile of a deployment that pilots well and stalls.
The better first target is the process with the most existing review, because the adoption cost is already paid there. Smaller number on the slide, much higher probability of surviving contact with the organization. Left to the savings math, AI use case selection picks the trap every time.
The deployment data fits. Code generation carries the reviewer twice over: a person reads it and a test suite runs it. Customer service resolution runs on a bounded answer space and cheap wrongness, with no reviewer anywhere. Document extraction has all three of the language absorbers. The most deployed use cases are not the ones running the best models. They are the ones where something was already positioned to absorb the variance.
Controls Are Not a Target
Governing a deployment and picking one are different jobs
Buyers are getting better at governing agents. They are getting better at choosing them far more slowly.
Audit logs, permission boundaries, kill switches, and human review are the right controls, and they answer the wrong question if nobody has asked whether the workflow has somewhere for wrongness to go. A buyer can have all four in the contract, put the system somewhere with no absorber, and stall anyway. Controls make a bad target survivable. They do not make it a good target.
There is a third thing underneath, and it becomes urgent exactly when neither a gate nor an undo is present. An action taken with no gate and no undo is a decision, and somebody owns it whether or not anybody has said so.
Where to Put the Money
AI use case selection from either chair, and the test that sorts it
Two rules fall out of the four positions.
For language, find where the reading already happens. Any of the first three will do, and all of them are available.
For action, find where the undo already exists. That is the fourth absorber, and it is the only one you may have to build. Discrete, contained, and repetitive is the right shape, and the reason is mechanical rather than aesthetic: those properties are what keep an action space enumerable and a step reversible.
Availability is what differs. Scoping for language is a search. Scoping for action is frequently construction, which makes it a requirement rather than a preference, and a question to ask a vendor before signing rather than a property to discover afterward.
Same test, two instruments. From the client chair: where does the variance land, and was that place already there? If it was not, work has been moved rather than removed, and the person it moved to decides whether the deployment survives. From the provider chair: ship into workflows where an absorber already exists, and know which one. A feature that depends on a customer quietly creating a job nobody approved is a feature with a good demo and a bad renewal.
The buyer is protecting a budget. The provider is protecting a roadmap. Neither usually knows the other is asking the same question, and when it fails neither finds out why. A project that stalled because the variance landed on somebody who never agreed to catch it gets cancelled in a budget review, for cost, by somebody who was not in the room when it was scoped. The failure and the recorded cause are different things, and the next scoping decision gets made the same way.
Most AI use case selection frameworks sort by category, and the categories are real. That is not the question. The question is where the wrong answer goes, because every deployment produces some. Where nothing is positioned to catch it, it lands on whoever is closest, and that is a cost nobody wrote down.
If you cannot say where wrongness goes, you do not have a deployment target. You have a demo.
So sort the list that way. Not by where the most work is, which is the obvious answer and the one the savings math keeps producing. By where somebody already knows what to do when the machine is wrong. That is AI use case selection with the variance priced in.
Brian Zrimsek has occupied all four seats in enterprise software: advisor at Big Six consultancies, analyst at Gartner, client at Irvine Company, and provider at MRI Software. He is the Enterprise Software and Commercial Real Estate Specialist for Lumerai Advisors and the founder of The Four Seats (thefourseats.net).
