AI Build Order: How to Sequence Your AI Roadmap for Compounding Returns

The most common AI roadmap looks like this: AI summarization (Q1), AI search (Q2), AI assistant (Q3), AI agents (Q4). Each item is shipped by a different team with different infrastructure. By Q4 the team has four features but no shared retrieval stack, no shared evaluation harness, no shared observability. Each feature degrades independently and the team has to debug each one separately. Productivity in year two collapses because each new feature requires rebuilding work that other teams already did.

Tradeoff: Avoiding the flat roadmap requires upfront investment in shared infrastructure that does not produce a user facing feature in the first quarter. Executives who measure quarterly velocity will pressure the team to skip the foundational work. Defend the foundational quarter by showing the year two velocity gain in a forecasting model executives can read.

Teams under pressure to demonstrate AI progress ship a flashy generation or agent feature first because it makes a great demo. The feature works in demo conditions but degrades in production because the team did not build retrieval, evaluation, or grounding underneath it. Six months later the team is debugging hallucinations and walking back claims rather than shipping the next feature. This is what happened to most enterprise AI assistants launched in 2023 and 2024.

Tradeoff: Shipping a flashy feature first sometimes makes sense for fundraising or executive buy in, but treat it as a marketing investment with a finite lifetime. Plan to refactor or replace it in year two once the foundational layers exist. If you treat the flashy feature as durable, you will keep patching it instead of building correctly.

Some teams try to build all layers in parallel: retrieval team, evaluation team, generation team, agent team all spinning up at once. The teams have nothing to deliver to each other for the first six months because the dependencies are not yet ready, so they each build their own version of what they need. The result is four parallel stacks that never merge. Klarna avoided this by sequencing strictly: ticket classification first, retrieval second, generation only after classification was production stable.

Tradeoff: Strict sequencing means some teams have less to do in the first quarter than others. The fix is to staff conservatively in the early quarters and expand staffing as later layers come online. This is uncomfortable for HR planning but necessary; staffing all layers from day one guarantees the parallel everything failure.

A team builds an excellent retrieval capability for one product surface. No other surface uses it because the surface owners did not know it existed or did not trust the SLAs. Within a year the capability is unmaintained because the original team moved on. The next team needing retrieval rebuilds. This is the inverse of compounding: investment is made but never reused. Glean built a business on this dysfunction inside enterprise customers who had multiple unused retrieval implementations.

Tradeoff: Preventing orphaning requires explicit cross team ownership of capabilities, which most product orgs resist because it slows individual team velocity. The fix is to make capability adoption a shared metric: the capability owner is measured on how many surfaces use the capability, not just on whether the capability exists.

Clean data pipelines, embeddings, vector store, retrieval and reranking. Without this layer, every higher layer hallucinates because it has nothing to ground on. Notion built this layer for six months before shipping any user facing AI feature. The layer should support hybrid retrieval (keyword plus semantic), filtering by permissions, and reranking based on signal beyond similarity. Test it in production with a single internal use case before promoting to user surfaces.

Tradeoff: Six months of retrieval work produces no user facing feature. Executives will press for an earlier ship. The defense is that without this layer every later feature will be unreliable and you will spend the same six months later debugging hallucinations. Pay the cost upfront.

An evaluation harness that runs offline tests on every model and prompt change, plus production observability that tracks quality, latency, and cost per user request. Without this layer, you cannot tell whether a change improves the product or breaks it. Build the evaluation set with at least 200 examples covering the main user intents, and build production observability that lets you slice quality metrics by user segment, model, and time. Anthropic, Salesforce Einstein, and Klarna all rebuilt this layer multiple times in the first year because the first version is always wrong.

Tradeoff: Evaluation infrastructure does not produce a feature, and engineers often resist working on it. The fix is to staff a dedicated evaluation engineer (see the AI Talent Strategy article) and to make production quality dashboards visible to the entire org. Once executives see the dashboards they fund the next layer with more confidence.

Classifiers that route user requests to the right downstream system, prioritize incoming work, or tag content. This layer is high value and low risk because classification errors are easier to detect and recover from than generation errors. Klarna built ticket classification before generation; Intercom built intent classification before Fin. Classification is also the layer that produces the most reliable internal data: misclassifications are easier to label than hallucinations are to evaluate.

Tradeoff: Classification is less exciting than generation and gets less internal champion energy. The fix is to frame classification work in terms of the operational savings it produces (support cost reduction, sales prioritization improvement) rather than as a step toward generation. The operational savings stand on their own and justify the investment.

Generation features (writing, summarization, Q and A) that retrieve grounding context from layer one, are evaluated against layer two, and are routed by layer three. Build this layer only after the previous three are stable in production. Notion AI Q and A, Atlassian Rovo, and Microsoft Copilot all sit at this layer and depend on the lower layers being correct. Generation features built without the lower layers hallucinate at rates that destroy user trust within weeks.

Tradeoff: Generation is the layer executives want first. Sequencing it fourth requires you to defend the order with executives. The defense is that generation features without the lower layers fail predictably and damage the brand. Show executives the failure mode of skipping ahead, then commit to a generation feature in quarter four with the lower layers as prerequisites.

Agents that plan multi step actions, orchestrate tools, and execute on the user behalf. This is the highest leverage layer and the most fragile. Agents amplify the failures of every lower layer: a bad retrieval becomes a wrong action, a bad classification becomes the wrong tool call, a bad generation becomes a wrong response that affects the world. Build agents only after the lower layers are well understood and well monitored. Devin, Cursor agents, and Salesforce Agentforce sit at this layer and depend on the lower layers being mature.

Tradeoff: Agents are the most exciting category and the area with the most competitive pressure. The temptation to skip ahead is strong. The fix is to ship a constrained agent (one tool, one workflow) on top of mature lower layers rather than shipping a general agent on immature foundations. The constrained agent ships sooner, fails less, and teaches you what the next agent needs.