Running an AI assistant project: the decision grid
Most assistant projects do not fail on technology. They stall because nobody wrote down what was expected, nor decided who would maintain the content once the demo was over.
The six questions before starting
Which precise question must it handle?
A vague answer produces a vague project. Three real examples beat an ambition.
Where does the answer live today?
If it is written nowhere, the work starts by writing it, not by tooling.
Who decides when two documents contradict each other?
Without a named arbiter, the corpus decays within months.
What happens when it does not know?
That answer determines how much trust it can be given.
Who updates it, and how often?
An assistant is living content, not a deliverable.
How will we know it works?
Two figures decided in advance beat a full dashboard looked at once.
Why most projects stall at the pilot
A pilot always impresses. It covers a chosen scope, with content prepared for the occasion and a friendly audience. None of that exists in production.
Three gaps explain most abandonments: content was not maintained and nobody planned to maintain it, real questions were not the pilot's, and no owner was named once the project team dissolved.
What makes an answer good
Four things, in order. The source: the answer comes from an identifiable, dated, approved document. The scope: a small, maintained corpus. Admitting ignorance: it says when it does not know. The handoff: it steps aside cleanly, with context.
The real cost over twelve months
The initial quote tells part of the story. Over a year, the project is content clean-up, build, connections to existing systems, then the recurring time of the people who validate and update. That last item decides success and is the one nobody budgets.
The three ways to fail
Trying to cover everything. A broad, neglected corpus answers worse than a small, maintained one.
Forbidding handoff. Minimising human transfer amounts to asking the system to invent when it does not know.
Confusing the tool with the knowledge. An assistant creates no information. It makes existing knowledge reachable, and missing knowledge visible.
When not to build one at all
When the knowledge does not exist. If nobody knows how to handle the cases, no tool will. Writing the procedures is the real work, and it has value in itself.
When the path is fixed. A form-triggered, always-identical journey is plain automation, for far less money.
When volume is low. Three questions a week do not justify a project. A well-written page handles them better.
When nobody wants to own it. The most reliable signal of all. An assistant without an owner becomes wrong within months, and a wrong tool costs more than no tool.
Frequently asked questions
Building is rarely the longest part. Content clean-up and naming owners set the real calendar, and both belong to the organisation.
When knowledge is written nowhere, when the path is fixed and belongs to plain automation, when question volume is low, or when nobody accepts ownership of the content over time.
Let's run your project through the grid
Six questions, one hour, and you will know whether the project stands up or what it needs to.