· 3 min read · Decisions
Three requests that usually mean something else
"We need AI", "we need to rewrite the backend", "we need this feature" — the request is always clear. The problem underneath it usually is not.
A client came to us saying they needed AI. Twenty minutes into the call we found what they actually needed: one process adjusted. No model, no agents, no retrieval. One process.
I hear three requests more than any others. We need AI. We need to rewrite the backend. We need this feature. Each arrives sounding precise, and each is a solution someone has already settled on before the conversation starts. That is the pattern worth noticing — people bring you the decision, not the problem. By the time it reaches an engineer it has usually been discussed internally for weeks, and somewhere in those weeks the problem stopped being described and started being assumed.
Ask what the process costs today
So the first question is never which model or which framework. It is what the process costs today — in hours, in errors, in the thing nobody does because it is too tedious. That number is usually easy to get and it settles the argument quickly. A process costing four hours a week does not justify an agent system. A process costing four hours a day, done inconsistently by three people, might.
The AI version has a specific failure
A request for AI is usually a request to remove manual steps, and manual steps are frequently a symptom of a process nobody has defined. Automating an undefined process does not fix it — it makes it faster and less inspectable, and now the errors arrive at machine speed with a model to blame. You have bought throughput on the one thing that needed judgement.
None of which means the answer is always no. On one platform the work genuinely was AI: twenty-five specialist agents drafting across an organisation's own knowledge base, because the underlying job — reading everything a company knows and producing a first version of something — is exactly what these models are good at. On another it was computer vision, because measuring rooms off a PDF plan is a measurement problem and always was. In both cases the process was well understood before a model touched it. That is the difference.
The same shape, different words
"We need to rewrite the backend" behaves identically. Sometimes it is true. More often the backend is fine and the release process is the thing hurting — and a rewrite buys eighteen months and the same deploy pain at the end of it.
What this costs to get wrong is not the engineering budget. It is the quarter. The money is spent, the system is delivered exactly as specified, and the original problem is still sitting there — now with a new system attached to it.
So when we talk, I will ask what is actually stuck before agreeing to what you asked for. If the answer turns out to be one process and no model, I will say so, even though the invoice is smaller.