Every intake conversation in 2026 opens with AI. Some of the best work we shipped this year had no model in it at all and in two cases removing the model was the fix.
Every intake conversation now starts in the same place. The client has a budget line for AI, a board that has asked what they're doing about it and a feature in mind. By the time we're in the room, the solution has usually been chosen and what's being scoped is the implementation.
Sometimes that's right. Often the described problem and the proposed solution have very little to do with each other and saying so is uncomfortable, because it sounds like the vendor talking themselves out of the interesting half of the work.
This is not an anti-AI post. We've shipped a lot of it and most of the last year of writing here is about it. It's a post about diagnosis, because the failure we now see most often isn't a badly built model integration - it's a well-built model integration sitting on top of a problem that a model was never going to solve.
The clearest example this year: a client wanted an AI assistant to answer "where is my order". Support volume was high, the questions were repetitive and the case for deflection was easy to write.
We asked to see the questions before scoping the assistant. The pattern in them wasn't that customers couldn't find the status - it was that the status was wrong. Three systems held order state, none of them agreed and the status page rendered whichever one answered first. Customers weren't asking because they couldn't find the information. They were asking because they'd found it and didn't believe it.
An assistant on top of that data would have answered confidently and been wrong at the same rate as the status page, with better grammar. The work we actually did was a reconciliation job and a single source of truth for order state. Support volume on that category dropped by most of itself. There is no model in the delivered system.
The general shape: when users are asking a system the same question repeatedly, the interesting question is whether the answer is hard to find or hard to trust. Only the first one is a retrieval problem.
The second pattern is scope. Agents are the right tool when the path through a task can't be enumerated in advance. A meaningful share of enterprise workflows can be enumerated in advance - that's what makes them enterprise workflows. They have compliance requirements, defined approval chains and auditors who need to know why a given decision was made in March.
We were asked to build an agent for a document approval flow: read the submission, decide the route, chase the approver, escalate on timeout. It sounds agentic. It has five states, three of which are waiting. We drew it on a whiteboard in twenty minutes and there was no branch in it that required judgement - only branches that required data, which is a different thing.
Built as a state machine, it's deterministic, replayable and an auditor can read the transition log. Built as an agent, every one of those properties becomes something you have to engineer back in and the eval suite becomes a permanent maintenance obligation for a workflow whose correct behaviour you could have written down completely on day one.
The heuristic we use now: if you can draw the diagram, build the diagram.
Can you enumerate every correct outcome?
─────────────────────────────────────────
Yes ──► state machine / rules
(deterministic, auditable, cheap)
No ──► is the input unbounded language?
Yes ──► model
No ──► you have a data problem
─────────────────────────────────────────
The build cost of a model integration is visible and gets estimated. The costs that follow it usually don't.
You take on non-determinism in a system that may need to be reproducible. You take on an eval suite that has to be maintained for as long as the feature exists and re-run every time the model version changes underneath you. You take on a latency floor set by someone else's infrastructure. You take on a support burden where "it gave a weird answer" is a valid ticket with no stack trace.
For a feature where the model is doing genuine work, all of that is worth paying. For a feature where the model is formatting a lookup result into a sentence, it is an enormous amount of permanent operational surface bought in exchange for tone.
Being fair about the other side, because the diagnosis only has value if it can come out either way.
The workloads where the model was clearly right shared one property: the input was unbounded natural language or unstructured documents and no amount of schema work would change that. Free-text incident reports where the taxonomy genuinely couldn't be enumerated. Contract clauses where the phrasing varies infinitely and the meaning doesn't. Customer emails that had to be understood before they could be routed.
In each case we had tried and failed to write the rules first. That failure is the qualifying evidence. Reaching for a model before you've attempted the deterministic version means you never learn whether you needed one.
The most valuable thing a delivery partner can do in 2026 is occasionally tell a client that the thing they've budgeted for isn't the thing that will fix their problem. Three questions do most of the diagnostic work: can you enumerate the correct behaviour, is the input unbounded language and are users struggling to find the answer or to trust it. If the answers point at a schema fix, a reconciliation job, or a state machine, that's the better project - shorter, cheaper and it stays fixed.
We'd rather ship the boring version that works than the impressive version that becomes someone's maintenance problem next year. That has cost us scope on a couple of proposals. It has also produced most of the systems we're proudest of.