Roadmap says agents. Build room says source of truth.
Why most 2026 AI launches slipped on translation, not technology.
The AI roadmap and the build room speak different languages, and the gap between them is where 2026 launches actually slipped.
The roadmap is written in capability terms. Deploy agents for claims triage. AI co-pilot for relationship managers. Automated underwriting for SME loans. Document intelligence across the policy lifecycle. It reads cleanly on a board paper. It binds to OKRs. It is, in the strict sense, accurate — these are the things the organisation intends to do.
The build room speaks in integration terms. There is no clean source of truth for claims; three back-office systems hold partial views and none of them agree on customer identity. The relationship manager’s pipeline lives in Salesforce, but the meeting notes that would actually condition the co-pilot live in OneDrive folders structured by individual preference. The underwriting risk model is in three Excel files, one of which is owned by someone who left in March. The document management system has two access patterns, one of which requires VPN.
Both descriptions are of the same project. Neither is wrong.
Two languages, one delivery date
This is not a culture problem. It is a structural one. The roadmap is written by people who do not sit in the build room — strategy, product, sometimes the CAIO. The build room is run by people who do not get edited into the board deck — domain architects, integration leads, data engineers. There is no role on the org chart called Translator. There is no artefact, on most org charts I have reviewed, where capability language and integration language meet on the same page and have to be reconciled before sign-off.
So the two languages run in parallel. The capability roadmap goes to the board. The integration reality stays in Jira. The model selection conversation gets weeks of senior attention. The source-of-truth conversation gets none, because nobody senior reads it. By the time these two languages collide — usually six to eight weeks into the build — the launch date has been committed externally and the integration work has not been scoped.
This is where the slip happens. Not in model selection. Not in evaluation. Not in compliance review. In the gap between what the roadmap said the agent would do and what the build room turned out to need to make it do anything at all.
The translation argument owns the date
Once you have looked at enough of these slips, the pattern is hard to unsee: whoever wins the argument about what “deploy agents for X” actually means in integration terms owns the real delivery date. This is rarely the person whose name is on the roadmap. It is often a domain architect three levels below the CAIO, who has spent a quiet week trying to explain that the agent cannot reason over claims because there is no entity called Claim in any single system — there are five overlapping representations, and reconciling them is a six-month data project that nobody has budgeted.
The roadmap does not slip because the model is slow. It slips because the integration spec was never written, or it was written but pointed at a source of truth that nobody owned, or it was written and the owner was named but the owner was three priorities deep on other commitments. The slip is in the translation, almost every time.
This is the diagnosis Nate Jones lands on in his recent piece on enterprise buying — that the build room and the roadmap are not the same conversation, and the buying process treats them as if they were. The version I keep seeing inside enterprises is narrower and, I think, more actionable: the language mismatch is concrete enough to fix.
What actually closes the gap
The fix is not a better roadmap. Better capability language does not solve a translation problem. The fix is three moves, and the order matters.
Force every capability into its integration pair. Every deploy agents for X needs a paired statement of the form the source of truth for X is Y, owned by Z, with data quality currently at status W. If the pair cannot be written, the capability is not ready for the roadmap. It is a research item. This single discipline kills more vapour than any review board.
Name a translation owner, not a steering committee. The translation owner is senior enough to push back on the roadmap when the integration reality does not support it, and embedded enough to hear the build room before the slip is announced. In practice, this is usually a domain architect or principal engineer with a remit that cuts across product and data. It is not the CIO. It is not the Head of AI. Those roles are too far from either language to translate live.
Treat the integration spec as the actual roadmap. The capability deck is downstream of the integration document, not the other way around. If the source-of-truth situation for claims is not solvable in this quarter, then the claims agent is not in this quarter’s roadmap. The capability deck reflects what the integration document permits, not what the board would like to announce. This is the harder of the three moves, because it inverts a political default. It is also the one that, when it gets done, removes most of the slip.
The translation document is the roadmap
The teams shipping AI in 2026 are not the ones with the best models or the most ambitious capability decks. They are the ones who write the translation document first and back the capability deck out of it. The capability deck describes the outcome the organisation wants. The translation document describes the integration reality the organisation has. The delivery date lives in the second one, not the first.
If you are a senior leader looking at a 2026 roadmap and wondering which of the lines on it will actually ship, ignore the model choices, ignore the use case selection, and ask one question: for each capability on this deck, can someone hand me the integration pair? If yes, the line is real. If no, the line is a hope.
Capability decks do not slip. Translation does.
Raghu writes Shipped, a practitioner-focused publication on enterprise AI in production. As CTO at Oraczen, he works with enterprises on agentic delivery in financial services, insurance and a range of other sectors.