Target AI at the Reviews, Not the Work
This is about placing better bets. It is written for the two people who have to place them. The product leader deciding what goes into the next release. The application leader deciding what gets funded next year.
I have sat in both chairs, and neither had a reliable way to tell a good bet from a bad one before making it.
On the provider side I held a backlog against a release schedule that would not fit it. Something came off every time, and what sorted the list was what got measured: revenue, retention, NPS. We did not keep a score for whether a shipped feature was being used broadly. Every one went in for a good reason and we never went back to see.
On the customer side the business units owned prioritization on their own terms, inside their own budgets. The list did not get sorted centrally because it was never centrally held.
Which of these do we build, and which of these do we fund, is the same question asked with different money. Both chairs had numbers, and the numbers were about something else.
Neither was ever stuck on whether to bet. Both were stuck on which bet, out of a list longer than the money. Telling somebody to adopt AI and telling them to be careful both make that list longer rather than shorter.
JLL put a number on that list in its 2025 Global Real Estate Technology Survey, across more than fifteen hundred senior decision-makers in sixteen markets. Fifty-six AI use cases identified across the value chain. An average of five pilots running at once.
Fifty-six candidates, five slots. The problem was never a shortage of things to try.
Every one of those lists now has agents on it, and almost no evidence about agents exists. Few have run long enough to show whether they stuck.
Which leaves the AI deployments that did stick, and the useful thing to do with them is not to copy them. It is to work out what made them stick.
What stuck falls into three clusters with nothing obvious in common.
The reviewed. Document extraction. Clinical notes. Code assistance. Contract review. Somebody was already reading the output before AI arrived.
The unreviewed. Customer service assistants, at higher absolute volume than almost anything in the first group. Nobody reads what they produce. The answer goes to a customer and that is the end of it.
The audited. Payment matching. Inventory adjustment. Automated journal entries. The work runs straight through, nobody reads each one, and a reconciliation sweep afterward catches what went wrong. Every action is logged and reversible, and the reversal matters as much as the log. Worth separating from a workflow where a clerk approves the exceptions before anything posts, which is a different arrangement and most accounts payable is closer to that one.
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, or 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.
Put those together and there are four positions. The three clusters occupy three of them.
Caught before | Caught after | |
Language | The reviewed | The unreviewed |
Action | The gated | The audited |
The reviewed is language caught before. A draft, a note, a suggestion, read by somebody before it counts.
The audited is action caught after, and it needs three things rather than one. The change is logged, wrongness surfaces in reconciliation rather than in the moment, and the action can be reversed. Logging on its own catches nothing. 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.
The gated is action caught before. The agent prepares and a person commits. That is the accounts payable arrangement above, and it is the shape behind some of the clearest early agent successes. It is also 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. Not in the case studies, which describe what shipped rather than what shape it took.
Three of the four positions are where things already run. As agents move from producing language to taking action, the two action positions become the ones that matter, and the market has no word for either.
Two rules fall out of the four.
For language, the question is who reads it.
For action, the question is what gets logged and what can be undone.
Language has two positions, the reviewed and the unreviewed.
Action has two, the gated and the audited.
The difference is where they are found. Reading happens all over an organization, so the language positions are usually already there. Approval gates and reconciliation sweeps cluster where money moves, and outside finance and a few regulated functions somebody has to build them. That is why the second rule is harder to satisfy than the first.
Both Sides of the Trough, at Once
Why there is no single moment to be early or late to
The Hype Cycle has a detail almost nobody uses. The phases apply to individual technologies rather than to a market, and the technologies are not in the same place.
Generative AI is in the Trough of Disillusionment. Agentic AI is at the Peak of Inflated Expectations, per the first standalone Hype Cycle for Agentic AI published in April 2026.
So an organization can be defending a generative AI deployment that is not delivering while funding an agent pilot that has not been tested, in the same quarter, in the same budget cycle. Both sides of the trough, running at once, in one building. Which makes whether AI is working the wrong question, and timing the wrong instrument.
And the more interesting thing rising from the trough is not a use case. It is the operating model. What is emerging with proven value attached is data readiness, engineering discipline and governance, which matches what the failure data says about causes. The winners and the cancelled are not running different models.
A trough is the distance between what a thing was sold as and what turned out to be attainable, discovered one deployment at a time by people paying for the discovery. That descent is conducted at cost. S&P Global Market Intelligence found 42 percent of companies abandoning most of their AI initiatives in 2025, up from 17 percent the year before, and the average organization scrapping close to half its proofs of concept before production.
The other side of that ledger is rarely reported. Deployments that reach production show measurable value at rates the headline failure numbers give no hint of.
The bet was never the risk. Reaching production was. Most of the mortality happens before the line, which makes the question that sorts a list not which category to invest in but which of these will survive the descent.
Three Absorbers, and a Fourth When AI Acts
What has to already be true, and what changes when output becomes action
Here is where the assistants resolve the contradiction. Nobody reads what they produce, and they work anyway.
Every AI deployment produces some amount of output variability, and somebody or something has to absorb it. Better models reduce the amount. They do not remove the need for somewhere to put what is left.
That cost lands somewhere. Call it the absorber: whatever is already positioned to catch the variability AI leaves behind. There are three to start with, they substitute for each other, and that is why deployments which look nothing alike survive for the same reason.
None of which says accuracy is irrelevant. A workflow with an absorber can still fail if the error rate is high enough to swamp it. The claim is narrower: accuracy is one part of deployment viability, and the workflow has to know what to do with whatever error is left.
Absorbing that remainder is not a one-time hurdle. Acceptance is a one-time hurdle and training clears it. This gets paid per use, because the same input can produce different output and a person has to keep deciding whether to believe it.
Here are the three.
A reviewer. Detection is assigned to somebody. Document extraction feeds a person who checks the extraction. 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. Intake and 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 and it costs nothing to put right. Plenty do not, and an answer about a refund, a contract term or a medication is not cheap wrongness at all. A wrong posting to the general ledger is neither noticed nor cheap: there is no recipient to escalate, and putting it right means a reversing entry and an explanation.
In language, the recipient detects and there is nothing to undo.
In action, a log detects and the undo has to exist.
Which means there is a fourth, and it belongs on the list. The three above were built from the language side, where nothing has happened yet and the worst case is a wasted answer. Reversibility only becomes an absorber once output stops being advisory, and it is the one an organization usually has to build rather than find.
One clarification, because the rule is easy to misread. This is not an argument for preserving manual review. Existing review is sometimes exactly the waste worth removing. The instruction is to find what currently absorbs the error before deciding what to do about it, and then work out whether AI can replace that absorption, reduce it, relocate it or mechanize it. Two things do not work. Removing it without noticing it was there, and failing to build one that will clearly be needed.
Deploy where at least one is already present, and know which one. Where none is present, the variance lands on somebody whose job does not include catching it. Such a deployment pilots well and quietly stops.
Which gives a ranking rather than a rule. Best, deploy where an absorber already exists. Acceptable, deploy where the prize is large enough to justify building one, deliberately and with a budget. Bad, deploy without noticing that one has to exist. Most stalled AI deployments are that last one, and almost none of them were scoped that way on purpose.
The absorbers are not equals either, and manufacturing worked this out a long time 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.
Which makes the preference order plain. Take the bounded domain where it is available, because it is the only absorber that does not charge you every time it runs. Use the others where it is not.
Agents Attack the Absorbers
Why this gets harder rather than easier, in the direction the market is moving
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 and it is measurable. OpenAI's own enterprise reporting has corporate usage moving away from question answering and toward delegated execution, with agentic use now accounting for the majority of output tokens among its enterprise customers. So the second rule is the more important of the two rather than the speculative one.
What follows from that shift is a design problem rather than a measurement. Increasing autonomy puts pressure on all of them at once, and each of the ones below is a consequence of how agents are built rather than an observed failure rate.
Step-level review becomes economically difficult, and this is the failure manufacturing already learned about. Inspecting every operation in a twenty-seven step process is not quality assurance. It is a second process that costs more than the one it watches. So review moves to the outcome, where it catches a wrong result rather than a wrong path. The documented failure mode is cascading errors, where each step is defensible on its own and wrong given the one before it. An outcome reviewer cannot tell which step went wrong without retracing all of them.
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, and every integration widens it. Unboundedness is the pitch.
And 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.
Which leaves the two positions on the action side, and both are narrower than the market is behaving.
Gated. Preserves the reviewer at the one step that matters, and it describes the clearest early agent successes.
Audited. Actions individually logged and individually reversible, with wrongness surfacing in reconciliation. A build decision rather than a category, which makes it a question to ask a vendor rather than a property to assume.
The absorber problem does not ease as autonomy increases. It sharpens, and the market is moving toward the configuration where every absorber is weakest.
Which is why the third cluster matters more than the market is treating it. Gartner's April 2026 Hype Cycle puts agent deployment at seventeen percent of organizations, and its June 2025 forecast has more than forty percent of agentic projects cancelled by the end of 2027. Both are true, and the distance between those numbers is what has not resolved.
So the second rule is not a description of what agents have proven. It is a test to apply before they prove anything, built from what the two clusters already showed. The reviewed cluster works because somebody reads. The unreviewed cluster works because the answer space is narrow and the cost of being wrong is a keystroke. An agent that writes to a system of record has neither by default, and the question is whether it was built to have one.
The Deployment Data Makes More Sense Through This Lens
Why the fastest AI deployment paybacks are all the same shape
Code generation sits near the top of most deployment surveys. The reviewer, twice over: a person reads it and a test suite runs it.
Customer service resolution appears near the top of most deployment lists. A bounded answer space and cheap wrongness, and no inline reviewer.
Document extraction appears on most lists of what actually reaches production. All three of the language absorbers at once.
The faster paybacks reported in recent deployment data share a shape rather than a category. Bounded, repeatable, high volume, and every one landing in front of something already going to catch it: qualifying inbound leads against stated criteria, drafting first-response replies somebody sends, reconciling invoices against a ledger.
The months vary by survey. The shape does not.
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.
Read that as a pattern rather than a proof. Nobody publishes cancellations broken down by use case type, so the failure data cannot confirm it. The deployment concentration points toward it and does not establish it.
One recent analysis reaches the edge of this. Document processing, predictive maintenance and customer service dominate published case studies because they have a visible baseline and an existing review process, rather than because the models are unusually accurate. That is the reviewer absorber, correctly identified. It cannot account for the assistants, and the assistants are half the market.
The Inversion
Why the process with the most manual effort is 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, no fixed answer set, and real consequences for being wrong. Which is the exact profile of the deployment that 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.
Those are frequently not the same process. The first one is the trap, and the business case selects for it.
The Two Rules, Earned
What each one actually asks for
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. Call that the fourth absorber, and the only one that often has to be built. 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.
The absorbers do not change between the two. Their availability does, and so does the work involved.
Scoping for language is a search: find the place where the absorber already sits.
Scoping for action is frequently construction: if the undo does not exist, somebody has to build it, and that is a requirement rather than a preference. Ask a vendor about it before signing rather than discovering it afterward.
In one market the choice is being removed on a timetable. The EU AI Act's high-risk obligations, which include human oversight and logging, will apply to standalone systems starting December 2, 2027.
The absorber is a design constraint, then, rather than a governance preference. Anything scoped now for a high-risk use in that market will need an absorber by then, and retrofitting one into a deployment that was never shaped for it is a rebuild rather than a control.
Everywhere else it stays a choice, and it stays a choice few are making deliberately.
There is a third thing underneath, and it becomes urgent exactly when neither 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. That is a different argument and it has its own piece.
Controls Are Not a Target
What the market is already asking for, and the question it does not answer
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 for high-impact actions are the right controls, and enterprise agent conversations now routinely include them before anything touches production. They still answer the wrong question if nobody has asked whether the workflow has somewhere for wrongness to go.
A control list is not a targeting test. It answers how to deploy safely once a workflow has been chosen and says nothing about which workflow to choose.
A buyer can have all four written into the contract and still put the system somewhere with no absorber, and that deployment will pass every control review and stall anyway. The controls make a bad target survivable. They do not make it a good target.
Which is the difference between governing a deployment and picking one.
The Same Test From Two Chairs
What a buyer asks and what a provider targets
Bring that back to the two chairs from the start. One observation, two instruments, depending on which side of the table it is used from.
From the client chair. Where does the variance land, and was that place already there? If it was, this is an input improvement and it can be measured against the old input. 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 you are relying on. 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.
What This Costs to Ignore
The failure and the recorded cause are different things
A project that quietly failed at adoption, because the variance landed on somebody who never agreed to catch it, does not get cancelled for that. It gets cancelled in a budget review, for cost, by somebody who was not in the room when it was scoped.
Cost is a real reason and it is also the reason available at the moment of cancellation. So the failure and the recorded cause are different things, the organization learns the wrong lesson, and the next scoping decision gets made the same way.
Where to Put the Money
The test, stated once
There is no shortage of AI deployment frameworks. Most of them sort by category, and the categories are real and every one of them works somewhere. That is not the question. The question is where the wrong answer goes.
Every deployment produces some, and the ones that survive are the ones where it already has a place to land. A person who was going to read it anyway. A domain narrow enough that there is not much to be wrong about. A log that catches it in reconciliation. A gate that holds it before it commits.
Where none of those exists, the wrong answer lands on whoever is closest. That is a cost nobody wrote down, carried by somebody who will not be asked before the budget review and will not be named as the reason when it ends.
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 the bet worth funding, and it is rarely the one getting the most attention.
There are four seats in the name. The fifth one is yours.
Comments