AI Pod for non-AI organisations: a 12-week reset
How traditional businesses get production AI without rebuilding the org chart.
Most AI Pod engagements are with companies whose product is not AI. They are insurance carriers, hospital networks, law firms, FMCG brands, manufacturers, professional services firms. The leadership has decided that AI capability is non-negotiable for the next five years, but the org chart, the talent profile, and the operating cadence weren’t built to ship AI. Hiring a 6-person ML team into that environment usually fails — not because the people are bad, but because the surrounding org doesn’t know how to use them.
The AI Pod model exists for this gap. This post is what the 12-week reset actually looks like.
The starting state
A typical non-AI organisation engaging us looks like this:
- 200–5,000 employees, $50M–$2B revenue.
- IT function exists, capable, mostly focused on operational systems (ERP, CRM, custom internal tools).
- “AI strategy” is a deck owned by the CIO or COO with 3–5 initiatives listed.
- Vendors have pitched. Some pilots have been run. Nothing has shipped to production.
- Board has expressed appetite for AI investment. Magnitude unclear.
The blockers are usually not technical. They are: no team that knows how to ship production AI, no operational pattern for AI in the company’s release cycle, no budget framework for AI infrastructure, and no clear answer to “how does this scale beyond the first pilot?”
The 12-week reset
A first AI Pod engagement is structured around shipping one production-grade AI capability, end-to-end, while building the operational pattern that the next five capabilities will follow.
| Weeks | Phase | Output |
|---|---|---|
| 1–2 | Diagnostic | Selection of the first ship-able use case from the strategy deck; written scope; success criteria |
| 3–6 | Build | Production-grade implementation of the use case, deployed to client cloud, with eval harness and observability |
| 7–9 | Integration | Connection to the production workflow, with human-in-the-loop where required, and per-user rollout |
| 10–11 | Operationalisation | Runbooks, monitoring dashboards, on-call procedure, change-management documentation |
| 12 | Handover + roadmap | Operational handover to the client team; written roadmap for the next 2–4 use cases |
The deliverable is not just the AI capability. It is the operational pattern: how AI gets shipped here, who reviews changes, how performance is monitored, what happens when an output is wrong, who owns the budget. This pattern is reusable; the AI capability is one instance of it.
Use case selection — where most engagements get this wrong
The hardest part of the 12-week reset is week 1: selecting the first use case. The wrong selection wastes 11 weeks. Three rules we apply:
- The use case has to ship to production in the engagement. A pilot that doesn’t reach production teaches the organisation nothing about operating AI in production. The use case must be production-feasible in 12 weeks, end-to-end.
- The use case has to have a measurable outcome. “Improve customer experience” is not measurable. “Reduce average handle time on tier-1 support tickets by 30%” is. If the outcome can’t be measured, the success criterion can’t be defined, and the organisation can’t decide if it worked.
- The use case should be operationally adjacent to the client’s existing workflow. Brand-new workflows that depend entirely on the AI are higher-risk first ships. Adjacent workflows (AI assists an existing process) are lower-risk and produce faster organisational learning.
Many “AI strategy” decks list use cases that fail at least one of these rules. Part of week 1 is filtering.
What changes in the organisation
By week 12, the organisation has:
- One production AI capability shipped, with measured impact.
- A working operational pattern (documented, repeatable) for AI development and deployment.
- Trained internal staff who can operate (not necessarily build) the AI capability.
- A roadmap for the next 2–4 use cases with rough effort estimates.
- A clearer view of what an internal AI team would look like in 12–24 months, if and when the workload warrants it.
The first engagement often informs the eventual hiring decision: how many FTEs, what specialisations, what reporting line. The AI Pod runs alongside the build-out for 6–18 months while the FTE team ramps.
Where the model doesn’t fit
Three cases:
- AI is core to the product. If the differentiator is the AI itself, the team needs to be in-house from the start. AI Pod can bridge the recruiting gap but isn’t the long-term answer.
- The organisation isn’t ready to operationalise. Some clients want AI strategy decks, not AI shipped to production. The Pod model only works if there’s executive commitment to ship.
- The use case backlog is empty. “We want to do AI” with no defined use cases is a Strategy engagement, not a Pod engagement. We start with the brief, not the build.
Outside these cases, the AI Pod is the cheapest and lowest-risk path for non-AI organisations to build operational AI capability. The 12-week reset is the typical first engagement; renewals follow naturally as the use case backlog develops.
Read more: /ai-pod/ · /strategy/ · /case-studies/
Run the matching free calculator
Each one runs in 3 minutes and emails you an 8-page memo.