Agents Earn Their Keep in the Exception Lane, Not the Happy Path
Photo by Shubham Dhage on Unsplash
Look closely at the agentic AI pilots running inside large enterprises right now and a pattern emerges: almost all of them target the happy path. Order intake. Standard invoice matching. Tier-one ticket triage. These are precisely the flows that workflow engines, RPA, and rules already handle at near-zero marginal cost. Pointing a non-deterministic, token-metered agent at them replaces something cheap and predictable with something expensive and probabilistic, then asks the business to applaud. That is the quickest explanation for why Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. The projects did not fail technically. They were aimed at the wrong part of the process.
The cost of a process lives in its tail
Any operations leader can tell you where the money goes. In accounts payable, 85% of invoices flow straight through and the remaining 15% — short shipments, price variances, missing POs, duplicate vendor records — absorb the majority of the handling cost and nearly all of the cycle-time variance. The same shape appears in returns processing, claims adjudication, master data onboarding, and B2B order management. Deterministic automation cannot touch that tail, because the tail is defined by the absence of a stable rule. Every attempt to encode it produces another branch in a rules engine that nobody dares refactor.
This is exactly the shape of work agents are good at: bounded, high-variance, judgement-adjacent, with a verifiable outcome. The agent does not need to be right the first time. It needs to gather context across four systems, propose a resolution, and show its reasoning to a human who can approve in five seconds instead of investigating for twenty minutes. That is a real economic delta, and it is measurable per case.
What a value-bearing agent workflow actually looks like
The McKinsey 2025 State of AI survey found roughly 23% of organisations scaling agentic systems in at least one function while a much larger group remains stuck in experimentation. The ones who cross that gap tend to design around a few non-negotiables:
- A named exception class, not a department. "Automate procurement" is not a scope. "Resolve three-way match failures under $5,000 where the variance is quantity-related" is.
- A verifiable end state. The agent's output must be something a system can accept or reject — a posted document, a corrected record, a credit memo — not a paragraph of advice.
- An explicit escalation contract. Define upfront what the agent must hand back: value thresholds, low-confidence cases, anything touching a regulated field. Escalation is a feature, not a failure mode.
- Unit economics per resolved case. Track inference and orchestration cost against fully loaded handling cost for the same exception class. Agents that cost more per case than the analyst should be killed early and without ceremony.
- A reversible action surface. Prefer agents that stage changes for approval over agents that write directly to systems of record. Reversibility is what makes broader autonomy politically survivable.
Why this changes the architecture conversation
Targeting the tail forces a different integration posture. Happy-path automation needs one clean API. Exception handling needs breadth — access to the ERP document, the carrier feed, the email thread, the contract PDF, the prior three resolutions of the same vendor dispute. In SAP landscapes especially, that means treating extension points, event streams, and side-by-side services as first-class design work rather than afterthoughts. Our SAP services teams consistently find that the constraint is not model capability but the absence of a retrieval path to the evidence a human would have used.
Start where the variance is
The honest test for any proposed agent is simple: if you removed the agent tomorrow, would anyone notice? If the answer is no because a rules engine would quietly absorb the work, you have built a demo. If the answer is yes because a queue would start growing, you have built something worth scaling.
Over the next eighteen months, the differentiation will not come from which model an enterprise picked. It will come from how precisely it mapped its own exception taxonomy and how disciplined it was about retiring agents that failed their unit economics. That is unglamorous portfolio work — and it is where the compounding returns sit. Our advisory and engineering teams typically start with a two-week exception-mapping exercise before a single agent is designed.
Frequently Asked Questions
How do we identify which exception classes are worth automating first?
Pull six to twelve months of case data from the workflow or ticketing system and cluster by reason code, then rank by volume multiplied by average handling time. The best first candidates are high-frequency, medium-complexity exceptions with a clear verifiable end state and low regulatory sensitivity.
Should agents write directly to the ERP or stage changes for human approval?
Start with staged changes and human approval for anything that touches a system of record. Once you have several months of accuracy data per exception class, you can selectively raise autonomy thresholds — usually by value band first, then by case type.
What metrics prove an agent workflow is actually creating value?
Track cost per resolved case including inference and orchestration, resolution rate without escalation, and cycle-time variance for the targeted exception class. Compare against the fully loaded human handling cost for the same cases before deployment, and retire agents that do not close the gap within a defined review window.

Comments (0)
No comments yet. Be the first to comment!