Building an MVP Intelligence Layer in 90 Days

If you have been reading this publication for the past eleven weeks, you have most of the conceptual scaffolding to design an intelligence layer. The question is whether you can build a real one inside a real organization, in the timeframe your board will actually fund.

This is the playbook.

An MVP intelligence layer is the smallest version of the four core components (semantic foundation, agent orchestration, trust and evaluation, operating model) that can be deployed against a single real use case in 90 days. Its purpose is not to scale immediately. Its purpose is to inform every architectural decision you make over the following two years by giving you ground truth. The companies that build the MVP early outpace the companies that spend a year strategizing it.

The reason 90 days matters is that it fits inside a single corporate planning cycle. Anything longer requires a strategic argument to extend funding past one budget review. Anything shorter doesn't produce enough operational learning to be worth doing. Ninety days is the unit that matches how established businesses actually fund things.

The first month is not a building month. The temptation to skip this step and start writing code is the most common reason MVP intelligence layer projects fail.

Pick one use case. Exactly one. The criteria: it should be something an agent could plausibly do well, where the humans currently doing it would welcome the help, where the data needed already exists in your warehouse, and where a wrong answer is recoverable rather than catastrophic. Customer support summarization is a classic candidate. Finance variance commentary is another. Sales-call note synthesis is a third. The wrong choice is anything that touches regulated data, anything where errors are expensive, or anything where the current process is contested politically.

Inventory the data the use case needs. Specifically, the metrics, dimensions, and edge cases that the agent has to know. If your semantic foundation doesn't define these clearly, that's the first work to do in the build phase. This is also where you find out which parts of your data are easily agent-ready and which are not. That information alone is worth the month.

Document the human process the agent will assist. The MVP intelligence layer isn't replacing humans. It's augmenting one specific human workflow. Map that workflow before you change it.

The build month is the part that looks like engineering work. It is. It is also the part where most teams over-engineer.

The semantic foundation gets built first. For your one use case, write the machine-readable definitions the agent needs. Include the exclusions, the edge cases, and the disambiguation rules. This is not a complete semantic layer. It is a complete one for this use case.

Pick the smallest orchestration that works. A single agent calling two or three tools is usually enough. Multi-agent swarms are usually wrong at this stage. Complexity is a cost.

Build a minimum eval harness. Twenty golden examples with known-correct outputs. Pass-rate dashboard. Manual review weekly. This is the trust backbone, and it cannot be deferred to a later phase.

Establish governance for this use case specifically. Who can use the agent. What it can access. What gets logged. The MVP version of these policies is fine. The full enterprise version comes later.

The third month is the one most teams skip. The system is working, the urge is to declare victory and move on. Don't.

Operate the system with the actual users. Daily standups for the first two weeks to surface failures fast. Weekly thereafter. Document every failure mode you see. The failure modes are the data that informs the next two years of architecture decisions.

Identify the owner. The MVP intelligence layer needs a permanent owner before the 90 days end. Not a steering committee. One person whose name appears on the system. Without an owner, the MVP decays.

Make the explicit go/no-go decision. Three possible outcomes: The MVP works well enough to extend to a second use case (scale). It works for this use case but won't generalize (limit). It doesn't work well enough (stop and learn). All three are legitimate. The wrong answer is not deciding.

A recent BCG study on enterprise AI deployment found that the gap between companies generating value from AI and companies generating none is widening, and the difference is concentrated in operational discipline. The companies winning are the ones that ran small, scoped pilots with real instrumentation and made the explicit go/no-go decision at the end. The companies losing are the ones still building strategy decks.

Ninety days is short enough to fit inside your funding cycle and long enough to produce real operational learning. The data leaders who run this playbook in 2026 will be the ones with concrete data informing their 2027 architectural decisions. The ones who don't will still be holding strategy meetings.

If you are scoping one of these and a conversation would be useful, my inbox is open.

If this resonates, subscribe.

— Kyle