There's a company shape that has become extremely common over the last two years. Two or three technical founders, a seed round, a model API, an interface, and a plan to automate a profession. Claims processing, investment research, regulatory filings, book closing, clinical coding, underwriting. Pick any function where the work is document heavy and the people doing it are expensive, and there are now somewhere between five and forty startups pointed at it.
The founders usually know the model extremely well. Very few of them have ever done the job. Nobody in the room has run a claims department, or sat through a quarter end close, or had a regulator ask why a particular decision was made in March. They've watched the work from outside, or interviewed six people who do it, or read a report about it, and concluded that the hard part is the intelligence. The hard part is almost never the intelligence.
Every enterprise process that looks stupid from the outside is carrying history. Some of that history is genuine waste and should be deleted tomorrow. A lot of it is scar tissue. The extra approval step exists because of an incident in 2019. The field everyone fills in with the same value exists because an auditor asked for it once and nobody since has been willing to take responsibility for removing it. The analyst who reads the file before it goes out is the reason a particular class of error stopped happening, and there is no document anywhere that records this, because she just started doing it one day and it worked.
Somebody who has done the work can look at a process and separate the scar tissue from the waste. Somebody who hasn't cannot, and there's no substitute available for that. Not model quality, not a discovery workshop, not a very good product manager with a Miro board. So what gets built is an automation of the process as described, which is a different thing from the process as performed. It handles the happy path beautifully, which is unsurprising since the happy path is what the demo used, and then it meets the real distribution of work: the broker who sends everything as photographs of paper, the subsidiary whose ledger runs in a different currency and a different chart of accounts, and the client whose contract was negotiated in 2011 with bespoke terms no template anticipates.
Those aren't edge cases, and calling them edge cases is where the trouble starts. In most of the processes I've looked at they're somewhere between 20 and 40% of volume and they consume the large majority of the department's time, because the clean cases were already fast. A system that handles the tidy 60% and escalates the rest has automated the part that was never expensive.
The reason this keeps happening is that the exceptions are invisible from outside and nobody writes them down. Ask a claims handler to describe her job and you'll get the documented process. Sit next to her for a week and you'll see the real one, which involves knowing that a particular hospital always bills the anaesthetist separately, and that a certain policy wording means the case needs a second opinion, and that when a file arrives from one specific broker it's worth checking the dates because they get transposed. None of that is in the process documentation. It's in her head, it took eleven years to get there, and it is the entire difference between a system that works and a demo that impresses.
The venture funded version of this has a particular flavour, which is that the incentives run against ever fixing it. A company that deeply understands one insurer's claims process has built something specific, and specific doesn't raise a Series B. So the pressure runs constantly towards the generic product, the horizontal platform, the version that works adequately for forty customers rather than properly for one. That's a sensible strategy for the startup and a bad deal for the customer, and the customer is usually the one funding the discovery that makes the generic version possible.
I'm not arguing that every AI vendor is hollow, and I'd rather not be read that way. Some of them have earned their domain knowledge the hard way, usually because a founder spent a decade inside the industry before starting the company, and those are worth your time. The filter is straightforward and you can apply it in a first meeting: ask them to describe the three exception types that eat the most time in the process they're proposing to automate, and how they handle each one. Not "how does the system handle exceptions", which just gets you an answer about human in the loop workflows. The actual exceptions, named, in your language. Somebody who has done the work will answer immediately and will probably tell you about a fourth one you'd forgotten about. Somebody who hasn't will start talking about the roadmap.
That question has saved me more time than any amount of technical due diligence, and it costs nothing to ask.
That's the fourth pattern.