Moving Beyond AI Pilots Into Everyday Operating Processes

Pilots are how organizations avoid deciding. A pilot is reversible by design: nobody’s job changes, no process gets retired, and when the quarter ends the deck says “promising results” while the actual work continues exactly as before.

If you are on your third pilot of the same use case, you don’t have an experimentation culture. You have a stall.

Why do most AI pilots never become everyday processes?

Because pilots are built to prove a tool works, not to change how work gets done — and those are different projects. MIT’s GenAI Divide study, as reported by Fortune, found that roughly 95% of enterprise generative AI pilots deliver no measurable P&L impact. The researchers named the root cause a learning gap: generic tools don’t adapt to the workflow they land in, so the workflow quietly rejects them.

The adoption numbers make the gap look worse, not better. Per McKinsey’s State of AI research, 88% of organizations now use AI somewhere — but only 39% report EBIT impact at the enterprise level. Nearly nine in ten companies adopted. Fewer than four in ten can point to the money. And what closes that gap, per the same research, is not better technology. It is workflow redesign and senior leadership commitment.

TechRadar’s reporting puts the market’s current state in one headline: AI adoption is no longer the challenge. Execution is.

What separates an operating process from a pilot?

An operating process has a named owner, a production system, and a number someone gets asked about every week. A pilot has a champion, a sandbox, and a readout.

Four tests tell you which one you’re looking at:

1. The default path. Is the AI workflow how the work happens, or an optional detour people can skip? If the old way still exists and still works, the old way wins.
2. The owner. Is there one person on the org chart whose outcome depends on this workflow running? Not a steering committee. A name.
3. The data. Does it run on live systems with real permissions and real failure handling — or on a CSV someone exported in March?
4. The metric. Is there a number, reviewed on a cadence, that the owner defends? License counts don’t qualify. Seat access is a receipt, not adoption.

Fail any one of these and you have a pilot wearing a production costume. The org chart lies; the workflow doesn’t.

What does the market get wrong about scaling AI pilots?

Our position: you don’t scale a pilot. You retire it and rebuild the workflow underneath it.

The standard advice says run a portfolio of pilots, fail fast, scale the winners. We think a portfolio of pilots is a portfolio of decisions deferred. “Scaling” a sandbox gets you a bigger sandbox — the pilot’s whole architecture was chosen for reversibility, which is exactly the property an operating process cannot have. Bolt AI onto how you already work and you buy a quarter. Rebuild the operating layer underneath and you buy the decade.

This is an argument, and reasonable people push back: pilots de-risk spend, they build internal buy-in, they surface edge cases. All true — for the first one. By the third pilot on the same use case, the risk you’re managing is no longer technical. It’s the risk of committing. Tenex cofounder Alex Lieberman makes the leadership version of this case in his talk on why you need a 2026 AI strategy: the companies pulling ahead decided, then built. Most AI strategies are decks. Ours are bets.

How do we actually move a pilot into production?

The same way we run every AI transformation engagement: embed, ship, train, hand off. Four moves. The last one is leaving.

Embed. Builders sit inside the team that owns the workflow and trace how the work actually flows — not the org-chart version, the real one, with its exception handling and its unofficial spreadsheet. This is where most pilots lose from day one: they automate the process as described, not the process as practiced. The people we send are the 0.16% — 50 builders hired from 32,100 applicants, every one through a paid build trial. If you’re still deciding which workflow deserves this treatment, start with which workflows to automate first.

Ship. First production system by week four, median. Not a demo — production: evals gating the outputs, permissions wired to your identity provider, data plumbing into the systems of record. We do the glamorous work and the garbage work, because the garbage work is usually why the pilot stalled. If the data pipeline doesn’t exist, we build the data pipeline.

Train. Pairing, not presentations. Operators run the system with us watching, then without us. The bar for what operator-grade instruction looks like is a full walkthrough a non-technical person can execute alone — the kind JJ Englert publishes, like his step-by-step Claude Cowork setup for non-developers. Training that doesn’t survive contact with a real Tuesday isn’t training. We wrote up how to make AI training produce real adoption instead of performative adoption separately.

Hand off. Repos, evals, agents, and dashboards transfer to your team — and our access gets revoked. The number we hold ourselves to at that moment: 90%+ operator adoption, defined as weekly active use at handoff (a figure we publish as illustrative until our launch audit). Tracked, not hoped.

Where does the pilot-to-production move break?

It breaks when the prerequisite work — ownership, data, training — gets skipped in the rush to ship. The failure modes repeat across companies:

No named owner. If moving the pilot to production changes nobody’s Monday, it will not survive its first bad week. The workflow needs one person whose goals depend on it.

The data plumbing was never built. Pilots run on exports and screenshots. Processes run on live systems. If the pilot’s success depended on a human ferrying data between tools, you tested the human, not the AI.

Training theater. If your AI rollout is a license count and a lunch-and-learn, that’s not training — that’s hoping. Operators need reps on their own work, with someone beside them, until the new way is faster than the old way.

Automating the broken thing. Production hardens whatever you ship. If the underlying workflow is bad, AI makes it bad at scale. Redesign first, then automate.

And the honest disqualifiers. Don’t move a pilot to production if leadership won’t name an owner and commit to a weekly metric — kill it instead, cleanly, and spend the money elsewhere. And don’t build internally out of pride: the MIT study found externally purchased, specialized tools succeed about 67% of the time, while internal builds succeed roughly a third as often. If a vendor tool does the job, buy it. We’d be wasting your money building it for you — and we’ll say so.

How do we know the shift actually happened?

When the old way is gone and the numbers hold after the builders leave. Three checks:

1. The pilot is decommissioned. Not paused. Gone. There is no fallback path quietly kept warm.
2. Usage holds without us. Weekly active use, measured after handoff, by the operators who own the outcome. Dependency is a design flaw — if the process needs its consultants to keep running, it isn’t an operating process; it’s staff augmentation with extra steps.
3. The metric moved. Cycle time, throughput, error rate — whatever the owner committed to. The workflow either carries the number or it doesn’t.

That is the whole distance between a pilot and a process: ownership, production, proof. We break down one tactical move like this every Tuesday in ultrathink, our free weekly newsletter.

Bring us your longest-running pilot. In one working session we’ll tell you whether it can carry production weight — and if it can’t, we’ll say so. Get started.