Why AI Pilots Stall at Step Three

In a typical AI pilot, the first two steps are relatively easy. Step one is the proof of concept: someone with technical access calls an AI API, gets a compelling output, and shows it to a decision-maker. Step two is the prototype: a slightly more structured version of the same thing, maybe with a UI, maybe with a few more prompts, enough to demonstrate that the capability is real.

Step three is where the prototype has to become a process. This is the step where the AI output has to be reviewed by someone who did not build the system. Where the result has to be approved before it goes anywhere. Where the workflow has to run without the engineer who built it sitting next to the person using it. Where access has to be granted to people who were not in the room for the demo.

This is the step where most pilots stall. Not because the AI stopped working, but because the organisational infrastructure to run an AI-assisted process does not yet exist. The team built a capability but not a system. And building a system requires answering questions that a proof of concept never had to answer: Who reviews the output? Who approves it? Who can change the workflow? Who can see the results? Who is responsible when something goes wrong?

These are not technology questions. They are operational questions. And the teams that answer them before they start building step three are the ones that make it to production.

When an AI pilot stalls at step three, the cause is almost always one of three structural gaps, or a combination of all three.

Gap 1: No human review structure. The proof of concept showed that the AI could produce a useful output. What it did not show is what happens to that output next. In a production process, AI outputs need to be reviewed, approved, or acted on by a person before they have any effect. If there is no structure for that review, the output sits in a queue that nobody owns, or it goes directly into a downstream system without any human check, which is a risk that most organisations are not willing to accept once they think it through. The pilot stalls because nobody has designed the review step, and nobody has been given the job of doing it.

Gap 2: No access structure. The proof of concept was built by one or two people with full access to everything. In production, different people need different levels of access. The person who runs the workflow should not necessarily be the person who can change it. The person who reviews outputs should not necessarily be the person who can see the audit log. The person who manages the budget should not necessarily have access to the workflow configuration. When these distinctions have not been made, the team either gives everyone full access (which is a governance problem) or nobody gets access (which is an adoption problem). Either way, the pilot stalls.

Gap 3: No ownership structure. In a proof of concept, one person owns everything: the model, the prompt, the output, the next step. In production, ownership has to be distributed. Someone owns the AI configuration. Someone else owns the process design. Someone else owns the operational execution. Someone else owns the oversight. When these ownership lines have not been drawn, every decision requires a conversation, every change requires consensus, and the pilot moves at the speed of the slowest stakeholder. It stalls not because of disagreement but because of ambiguity.

The way out of a step-three stall is not to build more technology. It is to build the operational structure that the technology needs to run inside. And the fastest way to build that structure is to follow the dependency chain that any serious AI workflow platform enforces.

In DAVE, the dependency chain runs in a fixed direction: Providers, then Agents, then Workflows, then Instances, then Tasks, then Reports. Each element depends on the one before it. A provider must exist before an agent can function. An agent must exist before a workflow can use it. A workflow must be saved before an instance can run. An instance must run before a task can be generated. A task must be completed before the workflow can advance.

This chain is not just a technical architecture. It is an operational map. Each link in the chain corresponds to a distinct ownership question:

• Who owns the provider? This is the Admin function. Someone needs to configure the connection to the AI service, manage the API key, and maintain the model catalog. This is a platform governance responsibility, not a day-to-day operational one.

• Who owns the agent? This is the Create function. Someone needs to own the system prompt, the model selection, and the behaviour parameters that determine what the AI actually does. This is a technical responsibility that requires judgment about AI quality, not just access to an API.

• Who owns the workflow? This is the Curate function. Someone needs to design the sequence of steps, the routing logic, and the human review gates that turn an AI capability into a business process. This is a process design responsibility that requires understanding both the business need and the AI capability.

• Who owns the execution? This is the Use function. Everyone who runs instances and completes tasks needs this ownership. This is the operational layer: the people who do the actual work with the AI workflow every day.

• Who owns the oversight? This is the Reporting function. Someone needs to monitor what the platform is doing, review the audit trail, and flag when something is not working as expected. This is a governance responsibility that is distinct from the operational one.

When a pilot stalls at step three, it is almost always because one or more of these ownership questions has not been answered. The dependency chain makes the questions visible. Answering them is what turns a prototype into a production system.

A pilot that is ready to move to production has answered five questions before the first production instance runs.

1. Is there at least one configured provider? Navigate to Admin, then API Management, then Providers. At least one provider record must exist with a valid API key and a populated model catalog. If this is not in place, no agent can function and no workflow can produce an AI output. This is the most common technical blocker at step three: the team built the workflow but never configured the provider in the production environment.

2. Does every person who needs access have a role? Navigate to Admin, then Settings, then Users and Roles. Every team member who will interact with the workflow needs at least one role assigned. A user with no roles sees an empty dashboard and cannot do anything. The role assignment conversation is the access structure conversation: it forces the team to decide who does what before the workflow goes live, rather than after the first incident.

3. Has the workflow been tested end to end? An untested workflow that fails mid-execution leaves an instance in a failed or waiting state that requires manual intervention. A complete end-to-end test, from launching an instance through completing every task to confirming the instance reaches completed status, is the minimum bar for production readiness. The test also confirms that the human review steps work: that the right people can see their tasks, complete them, and advance the workflow.

4. Is there a human review step? A workflow with no Human Review or User Interaction node runs entirely on AI output with no human check. For most operational use cases, this is not acceptable. The review step is not a limitation of the technology: it is the governance mechanism that makes AI output trustworthy enough to act on. Building it in from the start is easier than retrofitting it after the first quality incident.

5. Is there someone assigned to monitor the reports? The Reports dashboard shows run volume, failure rates, latency, and SLA metrics. Someone needs to look at it regularly. If nobody has the Reporting role and nobody has been given the job of monitoring workflow performance, the pilot will run in production without any visibility into whether it is working. Problems will be discovered by the people affected by them, not by the people who can fix them.

A pilot that can answer yes to all five questions is not guaranteed to succeed in production. But a pilot that cannot answer yes to all five is guaranteed to have a difficult first week.

The teams that move AI pilots to production fastest are not the ones with the best models or the most sophisticated prompts. They are the ones that treat the operational structure as a first-class deliverable, not an afterthought.

The proof of concept answers the question: can the AI do this? The production system answers a different question: can our team run this reliably, review the outputs, maintain the configuration, and improve it over time? The second question requires a different kind of work. It requires role clarity, access structure, process design, and oversight. It requires the team to think about what happens when the AI gets something wrong, not just when it gets something right.

DAVE is built around this insight. The platform enforces the dependency chain because the dependency chain is the operational structure. The six default roles (Admin, Create, Curate, Use, Reporting, and Financial) exist because the distinct functions in an AI workflow operation are real and need to be owned by specific people. The human review nodes exist because AI output without human oversight is not a production-grade process for most operational use cases. The audit log exists because accountability requires a record.

None of this is complexity for its own sake. It is the structure that turns a step-three stall into a production launch. The teams that understand this before they start building step three are the ones that finish it.