Why AI projects die in normal companies (it's never the model)

The typical setup: someone technical builds an agent, a team is told to use it, and ownership lands nowhere. IT thinks operations owns it. Operations thinks IT owns it. So when the output starts drifting, because a supplier changed an invoice format or a new product line confused the categorization, nobody is responsible for noticing. The agent keeps running, quietly wrong, until someone catches a bad number downstream and trust dies on the spot.

You would never hire a person, hand them real work, and assign them no manager. An agent is a worker. It needs one too.

The fix costs nothing. Before the project starts, name one person whose job now includes this agent's output. Not a committee. One name. They review its work weekly in the early months, they decide what it's allowed to touch, and they have the authority to change it or shut it off. If you can't produce that name, you're not ready to build, and no honest vendor should let you.

Every workflow has a routine middle and a weird edge. Automation eats the middle easily. The edge is where projects die. The first time an agent confidently mishandles a strange case, the team's trust doesn't drop by one case's worth. It drops to zero. And strange cases always come: the refund that spans three currencies, the customer who is also a supplier, the invoice in a language nobody expected. Then somebody says the most expensive sentence in operations: "let's just do them all manually, to be safe."

The fix is to design the escape hatch before you design anything else. The agent needs a clear definition of what it doesn't know, and a visible way to hand those cases to a human. Escalation is not failure. An agent that says "this one's unusual, over to you" keeps trust indefinitely. An agent that guesses loses it in a single afternoon.

In our own systems, the escalation rate is the dial we watch most closely. High at the start, tightening over time as we learn what the agent handles well. That trajectory, more than any accuracy score, is the health of the project.

The tool ships. An email goes out. Everyone is enthusiastic for a week, and then the calendar wins. Here's the math your team is doing, even if nobody says it out loud: the old way costs them nothing new today. The new way costs attention today to save time later. Learning it, distrusting it, checking its work. Busy people lose that trade every time, and your best people are the busiest.

Run your own numbers on this. If your team spends six hours a week on a process and the agent could cut that to one, those five hours only exist if people actually switch. Otherwise you've bought software and kept the payroll cost.

Treat adoption as its own project. Pick one team and one workflow. Run old and new in parallel for two or three weeks so people can check the agent's work and stop distrusting it. Then kill the old way on a stated date. This is the step everyone skips. Archive the spreadsheet, close the shared inbox, remove the shortcut. As long as the old path stays open, people will take it.

This one is the most expensive, because the project "succeeds." A company automates its quoting process exactly as it exists today: the double entry, the approval step that only exists because of a manager who left years ago, the field nobody reads. The agent faithfully reproduces all of it. Now the company produces the wrong thing faster, and the mess is hardened into software.

I've caught myself doing this inside my own companies. It's tempting, because mapping a process as-is feels like progress and questioning it feels like conflict.

The fix: before automating anything, walk the process end to end and ask of every step, would we design this in today, from scratch? Delete before you automate. Sometimes the walkthrough alone recovers more time than the agent does, which is a humbling outcome but a good one. Automate the process you should have, not the one you inherited.