The Agent Worked Fine Until It Did Not
A document processing agent in a lending operation handled thousands of loan packages without incident for six weeks. Then a borrower submitted a package where the legal entity name on the tax transcript differed from the entity name on the application by a single word, a common abbreviation that humans recognize instantly as the same company. The agent flagged it as a mismatch, escalated it, and the underwriter cleared it in thirty seconds. That part was fine. The problem was that the agent logged the case as a failed verification and the downstream reporting system counted it as a compliance exception. Nobody caught this for eleven days. By then the exception log had inflated to a number that triggered a manual audit.
That is not a model failure in any dramatic sense. The model did what it was built to do. It is an edge case failure, and it is exactly the kind that kills trust in a production agent faster than any headline about hallucination.
Why the Five Percent Matters More Than the Ninety Five
When you demo an agent to an operations team, you are showing them the ninety five percent. The clean inputs, the standard formats, the cases that look like the training distribution. They nod. They approve the pilot. Then the agent hits production and within two weeks someone finds a case that breaks the expected behavior, and that one case gets shared in the team chat, and suddenly the agent has a reputation.
The five percent is not a rounding error. In any real operational environment it is where the actual complexity lives. In manufacturing it is the work order with a non-standard unit of measure because a supplier changed their labeling. In distribution it is the shipment where two orders were consolidated by a carrier without notification. In field operations it is the inspection report submitted with photos taken in the wrong sequence because the technician was working in a confined space. These are not exotic scenarios. They happen every week. Your agent will see them.
The question is not whether your agent handles them perfectly. No agent does, and anyone who tells you otherwise is selling you something. The question is whether your agent fails in a way that is visible, recoverable and honest, or whether it fails silently and confidently, which is the worst possible outcome in any operational context.
How Edge Cases Get Missed Before Launch
The standard approach to agent testing is to build a golden dataset of representative examples, run the agent against it, measure accuracy, and ship when the number looks good. This approach has a structural blind spot. A golden dataset reflects the cases you already know about. Edge cases are definitionally the cases you did not think to include.
I have seen three patterns that cause teams to miss edge cases before launch.
- Testing on cleaned data. The data used to build the golden set has been preprocessed, normalized and deduplicated. Production data has not. The agent sees raw inputs with encoding errors, truncated fields, duplicate records submitted by two different systems, and timestamps in four different formats.
- Sampling from the recent past only. If you pull your test cases from the last six months of transactions, you miss the seasonal or cyclical cases that appear once a year. A freight audit agent tested in summer will not have seen the holiday carrier surcharge codes that appear in November.
- Ignoring the human workarounds. Every operations team has informal workarounds for the cases their systems do not handle well. When you automate the process, those workarounds disappear, and the cases they were handling suddenly arrive at the agent unmediated. You have to interview the people who actually do the work, not just read the process documentation.
Practical Methods for Surfacing Edge Cases Before Users Do
The most reliable method I have found is what I call adversarial shadowing. Before you go live, you run the agent in parallel with the human process for long enough to capture a full operational cycle. You do not just measure agreement rate. You build a log of every case where the agent and the human diverged, and you manually review every single one. Some of those divergences will be the agent being right and the human being inconsistent. Those are interesting but not urgent. The ones you want are where the agent was confidently wrong on a case that a human would handle without hesitation.
A second method is to deliberately inject malformed inputs. In a receivables reconciliation agent I worked on, we spent two days generating synthetic edge cases by taking real transactions and corrupting them in ways that mirrored known data quality issues from the source systems. Duplicate invoice numbers with different amounts. Currency fields with the symbol in the wrong position. Vendor names with extra whitespace that caused string matching to fail. We found six failure modes before go-live that would have caused silent errors in production.
A third method is to talk to the people who handle exceptions in the current process. In every operation I have worked in, there is someone whose informal job title is the person who fixes the weird stuff. That person knows every edge case the official process documentation does not mention. Sit with them for a day. Record what they do. That is your edge case library.
What Good Failure Looks Like in Production
You will not catch every edge case before launch. Accept that now. The goal is not zero edge case failures. The goal is that when your agent fails on an edge case, it fails in a way that is immediately visible, that routes to a human who can resolve it, and that generates a record you can use to improve the agent.
In a quality control workflow I built for a manufacturing client, we instrumented the agent to emit a confidence signal on every decision. When that signal dropped below a threshold, the case did not proceed automatically. It went to a review queue with a plain language explanation of why the agent was uncertain. The operations team could see exactly what the agent was unsure about. Over three months, the review queue became the single best source of training data for improving the agent, because every case in it was a genuine edge case that the agent had correctly identified as being outside its confident range.
This matters for trust as much as it matters for accuracy. When an operations team sees that an agent knows what it does not know, they trust it more, not less. The agents that destroy trust are the ones that produce a confident wrong answer on an edge case with no indication that anything unusual happened. That is the failure mode you are designing against.
The Organizational Side Nobody Talks About
Edge case management is not just a technical problem. It is an organizational one, and the organizational side is where most production agents actually fail.
When an agent hits an edge case in production and routes it to a human, that human needs to know what to do with it. In practice, many operations teams have not thought through the escalation path. The agent flags something unusual, the case lands in a queue, nobody owns the queue, the case sits for three days, and the downstream process breaks. The agent gets blamed.
Before you launch, you need a named owner for the exception queue. You need a defined SLA for how long a flagged case can sit before it escalates further. You need a feedback mechanism so that when a human resolves an edge case, that resolution gets back to the team maintaining the agent. And you need someone whose job includes reviewing the exception log on a regular cadence and deciding which edge cases are common enough to warrant updating the agent.
In distribution operations I have seen this done well and done badly. Done well, the exception queue becomes a continuous improvement loop and the agent gets measurably better every quarter. Done badly, the exception queue becomes a dumping ground that nobody trusts, the humans start bypassing the agent entirely, and the project gets quietly shelved.
The Practical Takeaway
Before your agent goes live, do three things.
- Run a full operational cycle in shadow mode and manually review every divergence between the agent and the human process. Do not sample. Review all of them.
- Inject synthetic edge cases based on known data quality issues in your source systems. If you do not know what those issues are, ask the people who currently handle exceptions.
- Design your failure mode before you design your success mode. Decide how the agent will signal uncertainty, where flagged cases will go, who owns them, and how resolutions will feed back into agent improvement.
The agents that earn lasting trust in production are not the ones that perform best on the demo. They are the ones that handle the five percent with enough visibility and honesty that operations teams feel in control even when the agent is uncertain. That is a design decision, not a model capability. You make it before you ship.