The edge cases are the use case

A support director at a telecom was scoping an AI feature to draft replies to customer tickets. Every time the conversation drifted toward the unusual cases, the disputed charges, the multi-account households, the accounts flagged for fraud review, the sponsor waved a hand. Those are rare. Edge cases. Handle the normal ninety percent and we win.

She almost accepted that. It sounds so reasonable. Then she pulled the actual tickets and looked at where her team’s time went. The “normal” tickets were fast because they were normal. An agent answered them in under a minute without thinking. The unusual ones, the ones the sponsor kept dismissing, ate most of the day, drove most of the escalations, and produced almost all of the angry follow-ups. The edge cases were not a footnote to the work. They were the work.

The exceptions are where the value hides

Here is the thing about the easy ninety percent. If it is genuinely easy, it is cheap to handle already, which means automating it saves little. A model that flawlessly answers questions a human answers in forty seconds has not moved much. The expensive minutes, the ones where automation would actually pay, are exactly the exceptions the sponsor wants to defer. So a feature scoped to the easy cases optimizes the part of the work that was never the problem, and leaves untouched the part that was.

The value in an AI feature usually lives in the hard cases, because that is where the human cost is. If you scope those out, you have scoped out the reason to build.

The exceptions are also where the risk hides

There is a second reason not to wave the edge cases away, and it points the other direction. The hard cases are where a model does the most damage when it is wrong. The easy ticket answered wrong is a minor annoyance. The fraud-flagged account answered wrong is a real problem, a compliance exposure, a furious customer, a mess someone has to clean up. The exceptions carry both the upside and the downside. Ignoring them in scoping does not make them go away. It just means you meet them for the first time in production, unprepared, when the model confidently mishandles the one category you never planned for.

AI features generally need to be right around 85% of the time before they help rather than hurt, and the accuracy that sinks you is almost never on the easy cases. It is on the exceptions, where the model has the least clear pattern to follow and the highest cost of being wrong. Scope the exceptions in and you can measure accuracy where it counts. Scope them out and your test numbers look great on the cases that were never going to fail.

Scope the exceptions in on purpose

So when a sponsor says “just handle the normal ones,” treat that as the moment to slow down, not speed up. Pull the real distribution of cases. Ask which ones cost the most time, which ones escalate, which ones create risk when handled badly. Then make an explicit decision about each hard category. Some the model should handle, with care and testing. Some it should recognize and hand straight to a human, which is itself a valuable behavior. What it must never do is silently treat an edge case as a normal case because nobody scoped it.

A claims lead at an auto insurer put it to me plainly. Her most important design decision was not what the model did with a clean claim. It was what it did the instant a claim stopped being clean. That boundary, and the handoff across it, was the actual feature. The clean-claim path was the easy part everyone focused on and the part that mattered least.

Deciding the edge cases in the room, during scoping, is cheap. Discovering them in production, during an incident, is not.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement at $2,500, we spend real time on the cases the sponsor calls rare. We pull the actual distribution, we find where time and risk concentrate, and we make an explicit plan for each hard category before anything gets built. Nine times out of ten, that is where the feature is either won or quietly lost, and it is a lot cheaper to decide there than to find out later.

When someone waves off the weird cases as edge cases, look closer. The edge cases are usually the reason you were going to build this at all.