Sequencing AI Adoption Without a Moonshot

The hardest part of an AI programme is not the model. It is deciding what gets funded in which order, with what reversibility, and who is accountable when a step underdelivers. If you own both the platform and the budget, that sequencing decision is yours and it is not delegable to a vendor roadmap.

Why does the moonshot keep getting proposed?

Because a single large project is easier to approve than a sequence. It has a name, a sponsor, an executive narrative and a line in a plan. A sequence of smaller commitments has none of those things — it looks like indecision to anyone reading the slide rather than the system.

The problem is where a moonshot puts the risk. It concentrates spend in the part of the stack you understand least, on the longest feedback loop, with the fewest exit points. You find out whether the grounding data was adequate at the end, after the integration work, after the change management, after the budget is committed. A sequence inverts that: you find out the cheap things first.

What are you actually funding when you fund AI work?

Three separable things, and conflating them is the most common sequencing error.

The first is a retrieval surface — the content the system reasons over, in a form something can query. Retrieval-augmented generation grounds a model’s output in supplied documents, which means the corpus sets the ceiling. If your policy documents live across four systems with no canonical version, no model choice rescues that.

The second is an inference dependency — a hosted model behind an API, whether that is Azure AI Foundry, Claude, or something you run yourself. This is the most substitutable layer and therefore the least deserving of early architectural commitment.

The third is a process change — somebody stops doing a thing by hand, or starts reviewing output instead of producing it. This is the only layer where value is realised, and it is the one with the longest lead time, because it involves people.

Funding all three as one project means the slowest component sets the pace for the whole thing. Funding them as a sequence means the retrieval surface can be useful on its own, before any model touches it.

What goes first?

The precondition work, which is rarely exciting and almost always underfunded.

If the eventual use case is answering questions over internal content, the first funded item is the corpus: where it lives, which version is authoritative, who owns a retraction, and how a document gets in and out. If the eventual use case sits on operational data, the first item is the pipeline that makes that data queryable on a known cadence with a known late-arrival behaviour.

This is the step that gets skipped because it looks like it predates AI, which it does. That is the point. It is also the step whose output is useful even if you cancel everything downstream — a governed, queryable corpus has value with no model attached. Precondition work that only pays off conditional on the next three steps landing is not precondition work; it is the moonshot wearing a smaller hat.

Where does build versus buy actually bite here?

Build-versus-buy turns on whether the capability is a differentiator or a commodity — that part is settled. What is less obvious is that the timing of the decision matters as much as the decision itself.

Early on, you do not know the boundary of the capability well enough to build it. Buying gives you a working reference and a fast answer to whether the use case holds at all. The cost of that speed is a dependency you may later want out of, so the thing to negotiate early is not price but exit: where does your content sit, what format does it come back in, and what breaks if you switch.

Later, once the boundary is known and the workflow has stabilised, building becomes defensible — but only for the parts that are specific to how your organisation works. The retrieval logic over your document taxonomy might be yours. The vector store underneath it almost certainly is not.

What team shape does the first phase need?

Not the one in the job ads. The first phase is dominated by data engineering, interface design and negotiation with process owners — not model work. A platform engineer who can land a reliable pipeline and a semantic layer will unblock more than a specialist who tunes retrieval parameters against a corpus nobody has curated.

The second question is whether you need a permanent lead at all yet. Owning platform and budget means you need someone who can hold architecture, vendor and delivery decisions together — but that is a decision-density problem, not a headcount problem, and the decision density in phase one is lumpy.

What is safe to defer?

Almost all of the architecture that assumes scale you do not yet have.

A model gateway is worth building when you have more than one model in production and a real routing decision. A central AI platform team is worth standing up when there are enough consuming teams to justify the coordination cost. Fine-tuning is worth considering once you can demonstrate that retrieval and prompt structure have hit a ceiling, which requires a corpus and an evaluation surface you do not have on day one.

Multi-agent orchestration is the most expensive thing to adopt early, because it multiplies the surface over which you need to reason about failure before you have learned how a single-step system fails in your own context.

How do you keep the output honest without vanity metrics?

Count of pilots is the canonical vanity metric, because it rises whether or not anything reaches production. Model-level scores are not much better on their own; they tell you about a component, not an outcome.

The measures worth putting in front of a board are the ones tied to a named process: how many manual steps were retired, how long the process takes end to end, what proportion of generated output is accepted without edit by the person accountable for it. Each of those requires you to name the process and the owner before you start, which is itself a useful filter — a use case that cannot name either is not ready to be funded.

Structured outputs help here in a way that is easy to miss. Constraining a model’s response to a supplied schema does not just make downstream integration tractable; it makes the output checkable, because you can assert properties about a shape you defined.

type Extraction = {
documentId: string;
effectiveFrom: string;   // ISO date from the source document
obligations: { clause: string; owner: string }[];
sourceSpans: { start: number; end: number }[];
};

// Cheap, deterministic gates run before anyone reviews content.
function admissible(x: Extraction, corpusIds: Set<string>) {
return (
  corpusIds.has(x.documentId) &&
  x.obligations.length === x.sourceSpans.length &&
  x.obligations.every((o) => o.owner.trim().length > 0)
);
}

What does this cost you to get wrong?

A deferred capability is cheap to reinstate. A premature platform commitment is not — it acquires consumers, conventions and a migration cost before it has earned any of them. The asymmetry runs one way, and it is the main argument for sequencing conservatively even when the technology is genuinely capable.

The discipline is not scepticism about AI. It is refusing to let the narrative convenience of a single large project override the fact that you can learn most of what you need from a much smaller one, and still keep the option to go further.