Is Your AI Project Really an AI Project?
Read the verbs before anybody prices the architecture.
It can sometimes feel as though the world of IT projects has lost its mind a bit.
We all know AI is in a full-on hype cycle in 2026, but the washing has become excessive. Ordinary automation is being described as agentic. Several different pieces of work are bundled together and called an AI programme. In some cases, the label is going to survive just long enough for the chickens to come home to roost.
How Question Zero came about
For almost two years now, I’ve had a front-row seat to how these projects begin inside organisations of all shapes and sizes.
Someone writes down what they need. Somebody else types “AI agent” on the cover because that is the language the board is funding this year. The label sticks (sincerely, but often wrongly) and three months later everybody is pricing an architecture for something they haven’t properly named.
That is what led me to encode the way I assess AI projects. I wanted to capture what I had learned as a practitioner so that I wasn’t starting again every time somebody put a new requirements document or tender in front of me.
I used to assess projects primarily in terms of readiness. What is the distance between the current and target state? What will it take, in terms of organisational and technical change, to deliver the project successfully?
About nine months ago, I realised that was the wrong way of looking at it.
Once you’ve examined enough of these projects, the same patterns keep returning. The verbs in the requirements usually tell you more than the nouns on the cover. The same architecture questions appear, followed by the same questions about risk, people and cost.
There was already a rubric developing in the way I worked, whether I had formally written it down or not. Question Zero came from making that rubric explicit.
It is the first instrument in the method, and it starts with a fairly straightforward question: is this actually an AI project?
Then comes the more useful part: if it is an AI project, what kind of AI project is it?
That matters because many of the things presented as a single AI project are actually several different jobs packaged together. There may be some ordinary automation, some information retrieval, a decision that needs to remain with a person and perhaps one part that genuinely benefits from a model. Giving all of it the same label makes the architecture harder to reason about.
I can now give my own AI assistant (usually Claude or Codex) a requirements document, a tender or even a fairly loose project description. It works through the questions I would normally ask, examines the available evidence and produces the working documents I need afterwards.
The judgement is still mine. I check the analysis, challenge its assumptions and change anything that has become more certain than the evidence allows. The time saving comes from no longer having to reconstruct the assessment process for every new project.
What I have tried to encode is my way of understanding the composition of an AI project.
People still tend to imagine that an AI project is primarily about building something with models. The model may be part of it, but that is rarely where most of the project lives.
The work also includes the architecture surrounding the model, the data it can reach, the decisions it is allowed to make, the risks attached to those decisions, the people affected by it and what the entire thing will cost once it is operating.
That is what I mean by composition.
Question Zero gives me a repeatable way to work through it and understand what is actually being proposed before everybody disappears into implementation.
What Brno was actually buying
I recently ran Question Zero against a real public tender from the City of Brno in the Czech Republic. I wasn’t working for Brno, and this wasn’t client work. I took the published tender and analysed it in the same way I would analyse something placed in front of me by a client.
Brno was looking for a platform to manage AI agents and automated workflows. The tender included public chatbots, an internal “AI porter,” a voicebot and other automated processes.
The interesting result from Question Zero was that this wasn’t one project. Underneath the platform label were three different kinds of system.
Some of the work was fairly obviously automation rather than AI. Some of it looked like retrieval with a language interface over the top. Other parts might have involved agents, but the tender did not provide enough information about the decisions those agents would be allowed to make.
That was a much more useful answer than trying to decide whether the tender as a whole was an AI project.
(The notice is in Czech; the translations here are mine. TED publishes an official English version, so you can check them against the source rather than taking my word for it.)
The cost question hidden in the tender
The other interesting thing about Brno was that the city appeared to be heading immediately towards its own hosted capability, with the models and hardware running on its premises.
I can understand why.
There are sovereignty and privacy considerations for a city. Language matters too, particularly when the system has to work properly in Czech rather than producing something that is excellent in English and merely passable for the people who actually have to use it.
But that does not automatically make hosting the capability yourself the correct economic decision.
Metered API access to frontier models can sometimes be considerably more cost-effective than running the capability yourself. Hosting brings infrastructure, energy, maintenance, staffing, upgrades, availability and capacity-planning costs. Those do not disappear simply because the hardware has been purchased.
The tender wanted enough hardware to operate for at least three years without further expansion. What it did not appear to contain was a clear volume of work for that hardware.
How many interactions are expected? How much information will be pulled into each one? How frequently will the systems run? What happens when usage is higher than expected?
This is where the lifecycle cost model becomes valuable. A buyer (or somebody considering bidding for the project) could compare the available delivery routes and understand relatively quickly whether the proposed approach made economic sense.
It might turn out that on-premise is the right answer. It might not. The important thing is that the decision is made after comparing the whole lifecycle, rather than because “hosted on our premises” sounded like the safest line to put into the tender.
Agent, or just automation?
The Brno tender also exposed another distinction that appears repeatedly in Question Zero. It used agents and automated workflows as parts of the same proposed platform, but those are not necessarily the same kind of system.
For me, the key difference is whether the system follows a route that has already been defined or selects its next action at runtime based on what it has observed.
An agent does something, examines the result and decides what should happen next within the authority it has been given.
That decision might be to speak to a person. It might be to take an action somewhere else. It might be to ask for more information or stop because the situation has moved beyond what it is allowed to handle.
Automation follows a mechanistic flow defined in advance. The route may be complicated, and individual steps may even use a language model, but the sequence and decision logic have already been determined.
An agent selects where it goes next.
That is also why the risk is different.
In high-stakes work, autonomous action may not be appropriate. The fact that a system can make a decision does not mean it should be allowed to make that decision on its own.
You have to understand what it is deciding, how serious the consequences are when that decision is wrong and where a person needs to remain involved.
This is why the verbs in the requirements are useful.
If the system is being asked to extract something, move it, validate it or route it according to a fixed rule, you are probably looking at automation—even if a model is used somewhere inside the flow.
If it is being asked to choose what happens next, select another action or escalate based on what it has found, you may be looking at an agent.
What the answer changes
The distinction affects much more than the label.
It affects the architecture. It affects the vendors you bring in. It affects the resources you need and the way you structure the project team. It affects the controls, evidence and oversight required before anybody should be comfortable putting the system into operation.
If you are responsible for one of these projects, you need to understand which kind of thing you are actually dealing with.
That does not necessarily mean walking into the next meeting and announcing that everybody has got it wrong and that this isn’t an AI project. That probably won’t help you very much.
You can say something more useful:
Based on the requirements, this is the footprint of the team we need. This part is automation. This part requires model capability. This part selects what happens next, so it needs a different level of design, control and scrutiny.
That is just as valuable as putting the brakes on. In some cases, it is the practical way of slowing the project down without turning the whole conversation into an argument about terminology.
Take the requirements and look at the verbs. Then ask what the system does after it has completed the first task.
Does it return an answer for somebody else to act on?
Does it follow a route that has already been decided?
Or does it select what happens next?
Once you know that, you have a much better idea of what you are actually building, and who you need in the room to build it.
Until next time,
Chris
P.S. — If you’d like to learn more about assessing AI projects, How AI Projects Die is my free, twenty-page field book: ten real engagements, the five doors where every AI project lives or dies. Get it free here.





Why does something need to be an “AI project” or not? I still don’t know why we aren’t building around the business problem. If there is some LLM in the architecture, great. If not, who cares? This is not a knock at you by the way, because I think you are seeing the same thing and I’m sure someone is hiring you saying “we need AI here.” Just something I’m also wrestling with myself.
Beyond honesty in your work, does the AI/not-AI distinction really matter? If the AI hype gets businesses (and cities) thinking seriously about automation, that's a win. My worry is practical: pitch an honest non-AI solution and you may lose to the vendor who shoves AI in the middle for no reason. I spend a lot of my time telling my clients that they don't need an AI solution but can use AI to build the automation.