Menu
Plenty of AI "pilots" end on time.
They also end without anything the team can run next week.
There was a kickoff. There were meetings. There may even be a deck with screenshots and a recommendation to "explore further." What there isn't: a deliverable someone can use, a definition of done that survived contact with real work, or a path the team could repeat without the pilot crew in the room.
That isn't mostly a model failure. It's a pilot without a bar: activity framed as exploration, with no agreement that the end state had to be usable and working.
Buyers who have been through this start defining the pilot differently. They want a working engagement with a deliverable. They want something they can repeat if they need to repeat it.
A serious pilot answers three questions before it starts:
If any of those three is fuzzy, you don't have a pilot bar. You have a time box and a hope.
Slides can document learning. They are not the deliverable unless the job was to produce a slide. For operating work, the deliverable is the path and the output the path produces.
We keep seeing the same picture without needing a named account to make the point.
A buyer reframes "projects" as pilots on purpose: working engagements with deliverables so they actually become projects. The end state they name is not a recommendation memo. It is usable, working, and something the team could repeat if they needed to. Elsewhere, the same companies already learned that agents need documented workflows first. The pilot bar sits after that lesson, not instead of it.
That is one problem, not a tooling shortage. You don't need a longer exploration first. You need done-when written in plain language before the clock starts.
Write done-when as outcomes on work, not as attendance or model choice.
Useful done-when language looks like:
If done-when is "we learned a lot," you will always be able to declare victory. Learning can be real and still leave operations unchanged.
Long enough to hit the bar. Short enough that scope can't hide.
For a first pilot on one everyday workflow, teams usually need a tight window measured in weeks, not an open quarter with floating goals. Exact length depends on the job's cycle time: a weekly report can prove repeatability faster than a quarterly planning path.
What matters more than a magic number of days:
Endless pilots are usually unclear bars wearing a project name.
The pilot ends when the deliverable works. Capability continues only if ownership continues.
Before closeout, name:
If those answers wait until the celebration meeting, the working deliverable becomes a souvenir. The team will ask for another pilot instead of running the one they already have.
A pilot that ends with something that actually works is not the finish line for the organization. It is the first time the work has a keepable shape. Treat that as the start of repetition, not the end of attention.
What should "done" mean for an AI pilot?
A named workflow, a working path on real materials, keepables the team owns, a second-operator test, and explicit non-goals. "We learned a lot" is not done. Done means usable, working, and repeatable on the job the pilot claimed to improve.
How long should a first pilot run?
Long enough to prove the bar on one everyday workflow, short enough that scope can't hide. Weeks with a fixed end date beat an open quarter. Match length to the job's cycle time, and put a mid-point check against done-when on the calendar.
How does the team keep running it after the pilot ends?
Name the post-pilot owner, where keepables live, what escalates when something breaks, and when the first unaided run happens on the next real cycle. Without those, a working deliverable becomes a souvenir and the org books another pilot.
If the pattern on this page sounds familiar, start with the free AI Operations Reality Check. One everyday workflow. No pitch deck.
If you want a bounded diagnostic and a written next-step memo, the AI Operations Review is the paid step after that ($997, not an open-ended contract).
Scot Westwater is the CSO and Co-Founder of Pragmatic Digital. He is an architect of practical AI operating systems that help operations and marketing teams move from robotic output to governed, brand-safe workflows. With over 25 years of building digital platforms for Fortune 500 brands, Scot focuses on turning AI experimentation into repeatable, measurable processes that drive real business impact. He is a co-author of Voice Strategy and Voice Marketing.
Weekly insights on AI adoption, workflow, and what's actually working in mid-market organizations.