Why AI projects stall at the proof of concept

Most companies we talk to now have a budget line for AI. Fewer can point to what it has returned. The pattern is familiar: a pilot works in the demo, the team presents it, and then it sits. Nobody kills it. It never reaches the people it was meant for.

The usual diagnosis is technical. The model was not good enough, the data was messy, the integration was harder than expected. Sometimes that is true. More often, when we look closely, the pilot did what it was asked. What it was asked to do was speed up a process that did not work well to begin with.

We have seen this before

Robotic process automation made a similar promise. Companies bought platforms to automate their workflows, and many of those programs disappointed for a reason that had little to do with the software: they automated the process as it stood. A process with six handoffs, two of them redundant and one that exists because of a form nobody has redrawn in a decade, came out the other side as the same process, running faster.

Automation applied to a weak process returns a weak process. That is not a criticism of the tools. It is what automation does: the thing you already do, more often, with fewer people watching.

AI rhymes with this, with one difference that makes it worse. Rules-based automation tended to fail loudly, at the edges its rules did not cover. An AI step makes judgment calls inside the workflow, and it inherits each ambiguity the process never resolved. Where a person once covered a confusing step with experience, the model guesses. A flaw that took years to surface under the old automation shows up in weeks.

Redesign the workflow, then the product

So the useful question is not where AI fits in what you have. It is how this onboarding, this claim, this approval would work if you designed it today, knowing what software can now do. Some steps disappear. Some move to the customer. Some turn out to be the point of the whole thing and need more of a person’s attention, not less.

Then you design the product around that workflow. This is experience design and service design: mapping what happens across people, teams and systems, deciding what each step is for, and drawing the screens and conversations that carry it. It takes longer to start than adding a feature. It is also the version that ships.

Most organizations do not have this muscle in house, and that is no criticism of the people they do have. Their engineers can build what they are asked to build, and their product managers know the current process intimately. Knowing a process well is not the same as being free to throw it out.

The front door

A second shift makes the redesign more urgent. Interfaces are thinning out of business software. Buyers increasingly want one plain place to start, a box to ask in or a short form, with the work handled behind it by steps they never see.

That sounds like less design. It is more. When the screen shrinks, the decisions the old interface made visible move into the workflow behind it: what the front door asks, what it needs to know before it acts, when it hands off to a person, and how it shows what it did. Get those wrong and the product feels like a chat box bolted onto the old system, because that is what it is.

Designing that door, and the workflow hidden behind it, is a design problem before it is an engineering one. Engineering decides whether an agent can do a step. Design decides whether it should, and what the person on the other side sees when it does.

What this asks of a design team

• Start with the workflow, not the screen. Map what happens today, across the teams it touches, before anyone draws anything.
• Ask what each step is for. A step that exists to catch an error another step creates is a candidate to remove, not to automate.
• Design the handoffs. The moments where the system passes work to a person, or back, decide whether people trust it.
• Design what nobody sees. In an agentic flow, the rules about what the system may do on its own are design decisions, and someone has to own them.
• Leave a system behind: tokens, components and patterns your team keeps building on, so the redesign does not decay into the next retrofit.

Where we land

AI will not fix a process that was not working. It will run it faster and show you where it breaks. That is useful, if you treat it as a diagnosis rather than a delivery. We think the companies that see returns will be the ones that go back and redesign the work before they automate it, and that most of the value sits in that redesign rather than in the model.