There is a pattern to failed AI projects, and it is remarkably consistent. A company buys or builds a general-purpose assistant. It is introduced with enthusiasm. It has no access to real data, no owner, and no definition of success. Three months later it is quietly switched off, and the organisation concludes that "AI isn't ready".
The technology was almost never the problem. The project had no edges.
Start with a workflow, not a capability
The useful question is not "what could AI do for us". It is "which specific, repetitive, high-volume piece of work is consuming capacity we need elsewhere".
Three properties make a workflow a good candidate:
Volume. It happens often enough that improving it matters. Automating something that occurs twice a month will not repay the effort of building it, however satisfying it is to automate.
Repetitiveness. The same decision, applied to different inputs. If every instance requires genuinely novel judgement, you are looking at expertise, not throughput, and AI will disappoint you.
Tolerable cost of error. Not zero — tolerable. This is the property teams get wrong most often. A workflow where a mistake is caught downstream by an existing check is a far better first candidate than one where a mistake reaches a customer or a ledger.
There is a fourth property that is easy to miss: the process must be stable. If the workflow is about to be redesigned, automating it now is money spent twice.
Draw the boundary before you build
Every agent needs three categories, written down before implementation:
- What it may decide alone. Classification, extraction, drafting, routing — actions that are reversible and observable.
- What it must propose for approval. Anything with financial, contractual or legal consequence. The agent prepares; a person commits.
- What it must never touch. Deletion, irreversible external actions, anything covered by a policy that predates the project.
Write this as a document, not a conversation. It becomes the specification, the test plan and the answer to the question your risk function will inevitably ask.
The boundary is not a limitation on the system's usefulness. It is the thing that makes deploying it possible at all.
Ground everything, and let it refuse
An agent that answers from your documented knowledge and cites its sources is auditable. An agent that answers from a model's general knowledge is a liability wearing your logo.
This has a corollary that teams resist: the agent must be allowed to say it does not know. A refusal is a correct answer when the sources do not cover the question. Systems tuned to always produce something will produce confident, plausible, wrong answers — and those cost far more than the silence they replaced.
In practice, a first deployment that says "I don't have a documented answer for this, ask Maria" is more valuable than one that answers everything at 80% accuracy, because the first one can be trusted and the second one cannot.
Assist before you replace
The most reliable rollout sequence we have found:
Phase one — drafting. The agent prepares a response; a person reviews and sends. Nothing reaches a customer unreviewed. This builds trust, and more importantly it generates the correction data that tells you where the system is actually weak.
Phase two — narrow autonomy. Categories where the agent's measured accuracy is high and the cost of error is low move to automatic. Everything else stays in review.
Phase three — expansion by evidence. Categories move to autonomy when the numbers say they should, not when the roadmap says so.
Teams that skip phase one to save time almost always end up back at it after an incident, having spent the intervening period losing credibility internally.
Decide how you will know
Agree the measure before you build, and make it a comparison against the current process on the same cases:
- What proportion was handled without escalation?
- What proportion was wrong, and how wrong?
- How long did each take, end to end, including the review step?
- What did it cost to run, per case?
That last one matters more than people expect. A system that works beautifully and costs more per case than the person it replaced is a research project, not an improvement.
If you cannot define this measure for a workflow, that is a strong signal not to automate it yet — not because measurement is bureaucracy, but because an inability to define success usually means the process itself is not well understood.
What this looks like when it works
The unglamorous version: a specific queue that used to grow linearly with customer count now grows much more slowly. A person still handles the hard cases, and now has time to handle them properly. Every automated action is logged with its reasoning, so when someone asks "why did this happen", there is an answer.
No transformation narrative. One process, working better, with a person still in charge of the decisions that matter.
That is what a successful AI project looks like, and it is available to almost any company willing to pick one workflow and finish it.