AI theater part 3: From ‘AI Theater’ to shipping, a 90-day way out

AI Theater Blog Series 3/3

Remember the weekly steering committee? The deck that grew from ten slides to twenty, the color-coded use-case matrix, the RAG demo that three people use?

Imagine the same room 90 days later.  The same people, the same chairs and that same dreadful office coffee. One thing has changed. There’s an additional slide: something running in production, the people who use it every day, and the number it moved.

It’s the smallest slide in the deck. It’s also the only one nobody needs to defend.

This is the last post in the series. In the first, we named AI Theater. In the second, we opened up the mechanism behind it and found that most of it comes from good decisions made in the wrong order. If the problem is order, the way out is order too. This post is about what the right order looks like.

The clock is a design tool

Most teams hear “90 days” and think pressure. We think of it the way an engineer thinks of a latency budget: a constraint that shapes the design. A tight clock does one very useful thing. It forces the decisions that open-ended programs are allowed to postpone forever: which use case, who owns it, and what number counts as done.

Postponed decisions are exactly where AI Theater lives. When RAND’s researchers asked experienced data scientists and engineers why AI projects fail, the most common answer wasn’t the model or the compute. It was misunderstanding and miscommunication about the intent and purpose of the project.(1) Nobody had agreed on what “working” meant, so nobody could tell when they had gotten there.

Three decisions before day one

Before any engineer opens a terminal, three things get decided on one day:

One use case. Not the most impressive one. The most boring one that has a real user, real data, and a problem someone is already losing sleep over. The lead author of MIT’s 2025 enterprise AI study described the teams that get real results as the ones that “pick one pain point, execute well, and partner smartly.”(2)

One owner. A named person with the authority to say yes and the accountability for the result. Not a committee, not a working group. Someone whose name sits next to the outcome.

One number. Agreed on day zero, in the business’s own words. Not “improve productivity.” Something like median time to first response on a support ticket. If it doesn’t fit on a sticky note, it isn’t a number yet.

These are the cheapest decisions in the whole project, and the ones most often skipped. They are also the ones that make everything after them easier.

SHIP: four steps, in order

Nebul’s method for this is called SHIP, the approach behind our Adoption Acceleration Service. Four steps, and the order matters more than the names.

Select. You don’t start from a blank page. You start from a pattern that another company has already put into production, and you adapt it. The blank page is where the Platform Trap hides: six months of architecture review for a problem someone else has already solved. A proven pattern walks around all of that.

Shape. Now the pattern meets your world: your data, your workflows, your constraints, your vocabulary. This is the step where a generic tool becomes your system, and it’s the practical answer to “features are rented, systems are owned” from the last post. In practice that can mean preparing your data, generating privacy-safe synthetic data where the real thing is too sensitive to use, fine-tuning a model on your domain, and running it privately.

ps. For related blog posts on how to fine-tune yourself step-by-step, check out our other blog posts.

Implement. Forward deployed engineers sit with your team and build it alongside them. Not consultants who hand over a deck and leave, but engineers who make the thing run. The goal is simple: on day 91, your team operates it without us, which means they had to build it, not receive it. The research leans the same way. In MIT’s data, projects built through partnerships succeeded about 3x as often as purely internal builds.(2)

Prove. Before use case two, use case one has to move the number you agreed on at the start. Both sides are accountable for that number, which keeps everyone honest about what the technology did and what adoption did. Then, and only then, the next one. No boiling the ocean.

What 90 days actually looks like

A caveat first: what follows is an illustrative composite based on how we run these engagements, not a specific customer. The company and the person are fictional.

Imagine Mira, head of support at a mid-sized software company. She has the usual list: nine AI requests from nine teams.

Day 0. In one meeting, they decide. The use case is ticket triage and first-draft replies for one product line. Mira owns it. The number is median time to first useful response, with a quality check so speed doesn’t buy sloppiness. The other eight requests go on the “next” list. It feels slightly uncomfortable. It’s also the first time in months the program has a shape.

Days 1 to 30. Select and Shape. The engineers start from a proven support-triage pattern instead of a blank page, then fit it to Mira’s reality: her ticket categories, her knowledge base, her escalation rules, the way her team actually writes. Tickets contain customer data, so the model runs privately on European infrastructure. What comes out of this stretch isn’t a demo. It’s a working workflow that connects her helpdesk, her knowledge base and that model. Around day 30 there’s a first honest check of the trajectory against the agreed number. If something is off, this is the cheap moment to find out.

Days 30 to 75. Implement. Real tickets flow through. Mira’s agents use it daily and argue with it, which is the point, because every correction is information. The system gets a little better each week instead of staying frozen at launch.

Day 75. An interim review with Mira: what’s built, what’s left, what the early numbers say. Somebody mentions use case two. Nobody starts it yet.

Day 90. A short, honest write-up: the number, what was built, what the team learned, what each side contributed. A support team that can run the system without us. And something nobody planned: the shared components, the evaluation set, the runbook, the data connections. The platform that nobody designed up front has emerged from one working use case. Platform comes from shipping.

Where POST fits

If SHIP is how, POST is what it’s built on. Every use case shipped this way runs on four principles.

• Portable: your workloads can move.
• Owned: open models, your data, your fine-tunes.
• Sovereign: your jurisdiction, your rules.
• Tailored: built for your business, not a generic one. POST is the architecture. SHIP is how we build it, together.

A fair question at this point: doesn’t this sound like the Platform Trap again? Forrester’s 2026 read on agentic AI argues that the companies pulling ahead aren’t the ones with the most agents, but “the ones laying the track the train will run on.”(3) We agree with that. The trap from the last post was laying all the track before the first train.

A factory isn’t the problem either. Building your own, from scratch, before you know what it will make, is. That’s why SHIP starts on a foundation that already exists. Nebul’s AI Factory brings the guardrails, observability, tailoring pipeline and private European infrastructure that a first use case needs, so the 90 days go into the use case, not the stack.

The way out is to lay the track under the first train, one use case at a time, on rails you own.

Exiting the theater

None of this takes a bigger budget or a braver strategy. It takes a smaller first step, taken in the right order. Ship one thing. Prove it moved a real number. Then ship the next.

The steering committee can keep meeting. It just gets a better question to ask: not “how many pilots do we have?” but “what shipped, and what did it move?”

If you recognized your own company somewhere in this series, the most useful next step is a conversation about your first use case. Talk to Nebul.

Missed the earlier posts? Start with Part 1, Busy, Performative, and Going Nowhere: The Anatomy of AI Theater, then Part 2, Four reasons your AI initiative looks busy but ships nothing.

*Sources

(1) James Ryseff, Brandon De Bruhl and Sydne J. Newberry, “The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed,” RAND Corporation, August 2024.

(2) Sheryl Estrada, “MIT report: 95% of generative AI pilots at companies are failing,” Fortune, August 18, 2025 (includes an interview with Aditya Challapally, lead author of “The GenAI Divide: State of AI in Business 2025,” MIT NANDA).

(3) Forrester, “The State Of Agentic AI In 2026: Companies Are Chasing, Few Are Catching,” Forrester blog, June 2026.