Your AI pilot isn't blocked by the model
By Anthony Odole · September 3, 2026 · 10 min read
Two numbers, from different surveys, describing the same wall.
Technical debt affects ninety-three percent of CTOs. And eighty-six percent of CFOs say technical debt is a moderate or significant barrier to enterprise AI.
The second number is the interesting one, because CFOs are not usually the people describing technical debt. When finance starts naming your architecture as the thing blocking the strategy, the conversation has changed. It's no longer an engineering hygiene issue that gets deferred each quarter. It's the line item standing between the company and its largest planned investment.
But "technical debt is blocking AI" is too vague to act on, and vague diagnoses produce vague remediation programmes that consume two years and change nothing. The mechanism is more specific than that, and once you see it the sequencing becomes obvious.
The mechanism: autonomy requires a map
Here is the whole argument in one sentence.
Automation only requires that a system works. Autonomy requires that someone can describe how it works.
A script that runs at 3am doesn't need anybody to understand the estate. It does one thing, on a schedule, and when it breaks a human reads the error and fixes it. The understanding lives in the human, and it's summoned only on failure.
An agent granted authority to act is different in kind. To decide what it may do, you have to know what it can reach. To know whether it acted correctly, you have to know what correct looks like in a system whose current state you can describe. To recover when it acts wrongly, you have to know what it touched. Every one of those requires an accurate current-state model of the estate — and that is precisely what technical debt destroys.
Technical debt is usually described in terms of cost: slower delivery, more incidents, harder hiring. All true. But the property that matters for AI is different. Technical debt is accumulated undocumented decisions. Each one made sensibly, under pressure, by someone who has since moved teams. The interest you pay isn't just time — it's the steady erosion of anyone's ability to state how the system actually behaves.
You cannot delegate authority over a system you cannot describe. Not to a contractor, not to a new hire, and not to an agent.
The three models that have to be reconciled
When I run an architectural review, the finding that comes up most often isn't a specific misconfiguration. It's that three models of the same system exist and none of them match:
- The CTO's mental model
- The engineering team's mental model
- The actual configuration
Nobody has reconciled them, usually because nobody has ever produced all three in one place at one time. Most engineering organisations have never written down their current state as it actually exists — the hosts, the networks, the daemons, the registries, the cache substrates, the environment variable scoping, the timing patterns. They have architecture diagrams describing an intended state, some of which was built, some of which was built differently, and some of which was quietly replaced in 2023.
For human operators, this divergence is survivable. Humans handle ambiguity by asking someone. The tribal knowledge in the team fills the gap between the diagram and the truth, invisibly, dozens of times a week.
Agents cannot do that. An agent operates on the model it was given. If the model is wrong, the agent is confidently wrong at machine speed, and it will not stop to ask the one person who knows.
What this looks like when it bites
Two examples from my own platform, both cheap to describe and both the kind of thing that no diagram would have shown.
Two stores, one of them load-bearing. Conversation history existed in two places: a durable database that the user interface displayed, and a fast cache that the agent's next turn was actually assembled from. Both were correct. Both were maintained. But only one of them determined agent behaviour, and that fact lived in nobody's diagram.
The failure mode is exquisite. Write a message into the database and a human sees it on screen and the agent behaves as though it was never said. Everything looks broken except the thing that's broken. Any human operator handed the same architecture would have asked "wait, which one does it read?" within an hour. The agent has no such instinct — it reads what it reads.
Capability that was true ten minutes ago. Agents' integration grants were cached, and for a period several code paths wrote grants directly to the database without invalidating that cache. The database was correct. The running system was stale. So the honest answer to "what can this agent do right now?" was something between what it could do ten minutes ago and what the database says, and no single component knew which.
That's not a bug in the ordinary sense — every individual write was correct. It's a gap between the recorded state and the operating state, and it's exactly the gap technical debt widens. When we finally traced it, six of the seven historical write paths had the same flaw, which tells you it wasn't carelessness. It was a missing invariant nobody had ever been in a position to state, because nobody had the whole picture.
Which debt actually blocks agents — and which doesn't
Here is the part that makes this tractable, and it's the part most remediation programmes get backwards.
Not all technical debt is agent-blocking. A great deal of what gets called technical debt is aesthetic, or economic, or a productivity tax — real, worth fixing, and entirely irrelevant to whether you can safely delegate authority to a machine. Meanwhile some of the debt that blocks agents hardest doesn't look like debt at all, because the system is running perfectly.
The distinguishing question is not is this code bad? It's does this reduce anyone's ability to state, accurately, what the system does and what may touch it?
By that test, four categories block agents.
Undocumented divergence. Anywhere the recorded state and the operating state differ, and no mechanism reconciles them. Configuration that drifted. An environment variable set on the host and never written down. A cache whose invalidation is best-effort. Every one of these is survivable for humans, who reconcile by asking, and lethal for agents, who cannot.
Ambiguous system of record. Two places hold the same fact and only one of them drives behaviour. This is the two-stores problem from earlier, and it is astonishingly common in systems that have grown — a durable store, a fast store, and no document saying which one the logic reads. An agent reading the wrong one will be confidently, silently wrong.
Implicit coupling. Where changing A breaks B and nothing declares the relationship. Humans learn the couplings through incidents and carry them as tribal knowledge. That knowledge is precisely what does not transfer to an agent, and it's the reason "the agent did something reasonable that broke something else" is the second most common production complaint I hear.
Unmappable permissions. Where the honest answer to "what can this component reach?" is nobody has ever computed that. Shared credentials, wildcard grants, service accounts accumulated over years. You cannot bound an agent's blast radius inside a permission model you can't enumerate.
And three categories that get called blockers and mostly aren't:
Ugly code. An agent doesn't read your code. It calls interfaces. A well-documented interface over an embarrassing implementation is fine; a beautiful implementation behind an undocumented interface is not.
Old versions. A five-year-old framework that is stable, understood, and documented is a smaller obstacle than last month's service that one engineer stood up and nobody else can describe. Currency is not the same as legibility.
Missing tests. A real problem for change velocity, largely orthogonal to this one. Tests tell you whether behaviour changed. They rarely tell you what the system is or what it can reach.
The practical consequence is that the remediation you need is much narrower than the remediation your backlog describes. Most organisations facing this conclude they need a modernisation programme. What they usually need is a survey — and those are measured in weeks.
What the survey actually produces
When I run a current-state review, the deliverable that changes the most conversations is unglamorous: a written and visual map of the system as it actually exists. Not the intended architecture. The real one — hosts, networks, daemons, registries, cache substrates, environment variable scoping, deploy timing patterns.
Most engineering organisations have never produced this in one place, and producing it resolves the divergence I described earlier almost mechanically. You cannot hold three incompatible mental models in a room once one document has all three of their contents written down side by side.
For agent readiness specifically, the map needs three things the classical version doesn't emphasise:
Reachability, not topology. Not just what connects to what, but what each actor is permitted to reach. Topology tells you the shape. Reachability tells you the blast radius, and blast radius is the unit of agent risk.
Named systems of record. For every fact the agent will act on, one authoritative location, written down. Where two stores hold the same fact, name which one is load-bearing and what the divergence window is.
Divergence mechanisms. Every place the recorded state and the operating state can disagree, with the window. Caches, eventual consistency, manual steps, anything asynchronous. This is the section that doesn't exist in most architecture documentation and is the one an agent will find first.
Scope it to what the agent will touch and this is a matter of weeks, not a modernisation programme. Scope it to the whole estate and you have accidentally commissioned the two-year project that was never going to be approved.
Why this reframes the AI budget conversation
Most organisations are currently running two conversations that never meet.
One is about AI: a large planned investment, a set of pilots, a strategy deck, executive sponsorship. The other is about technical debt: an unglamorous remediation ask that has been deferred for three planning cycles because it doesn't show up as a feature.
They are the same conversation. The AI budget is blocked by the item that keeps losing to the AI budget.
Eighty-six percent of enterprise leaders report their organisations are not ready to integrate AI into daily operations, while naming AI as their single largest investment priority for the year. That is not a contradiction. That is an organisation attempting to buy its way past a precondition — and the reason the money isn't working is that the precondition isn't purchasable.
I've written elsewhere about how to count what deploy infrastructure debt actually costs, because CTOs consistently know the cost is real and lack the methodology to express it in the language their executive team operates in. This is the same problem with higher stakes. The remediation that was hard to justify as maintenance becomes straightforward to justify as the prerequisite for the strategy the board has already approved.
That is a better argument than the one most CTOs are currently making, and it happens to be true.
The order of work
If the diagnosis is right, the sequencing follows, and it's less painful than a full remediation programme.
You do not need to eliminate technical debt before doing AI. That framing produces a two-year project and no agents. It's also wrong: plenty of debt is irrelevant to the agent's blast radius.
You need to be able to describe the part of the estate an agent will touch. Bound the scope by the agent's reach, then make that bounded region legible. That's a survey, not a rebuild, and it can be measured in weeks.
Four questions, per intended agent:
What can it reach? Not what it's for — what it can touch, resolved by the running system rather than asserted by a design document. If you can't generate that list on demand, stop here; the rest is unanswerable.
What is the state of the things it can reach? Documented, current, matching reality. Where the recorded state and the operating state can diverge, name the mechanism and the window.
What does correct look like? Stated in advance, measurable by something other than the agent itself. (That's the subject of a separate piece, and it's where more organisations come unstuck than any other single point.)
What happens when it's wrong? Not "we'll notice" — what mechanism notices, and what does it do. Absence of work produces no error, so this has to be built deliberately.
An estate that can answer those four questions for a given agent is ready for that agent, whatever else is broken elsewhere. An estate that can't isn't, no matter how good the model is.
The part that isn't about AI at all
Strip the agents out and this article is about something older: the difference between a system that runs and a system that can be reasoned about.
Enterprise architecture has always been the discipline of maintaining the second property while the first one accumulates changes. It's unfashionable work. It produces no features. It is, reliably, the first thing cut when delivery pressure arrives, and the cut is invisible for years because the system keeps running.
AI has made the bill arrive. Every organisation that let its current-state model rot is discovering that the rot is the thing standing between it and the technology it has already budgeted for — and that no amount of model spend substitutes for knowing how your own systems work.
That's not an AI problem. It's the oldest problem in the discipline, presenting with a new symptom.
Architecture first. Technology second.
If you can't currently answer those four questions for the part of the estate an agent would touch, that gap is the work — and it's weeks, not a modernisation programme.
Book an Enterprise AI Strategy Briefing →
— Anthony Odole · ex-IBM Senior Managing Consultant · 18 years in enterprise architecture · now building and running a multi-agent platform