A year ago, the strategic question for European organisations deploying AI was "which model?" Today, that question has become almost beside the point. GPT-4o, Claude Sonnet, Gemini 1.5 Pro — the leading foundation models are broadly comparable for most enterprise tasks. The real differentiator has shifted. It is no longer what your AI thinks with. It is what your AI lives on.
A detailed technical analysis published in April 2026 by Han Lee — extending the landmark 2015 Google research paper on hidden technical debt in machine learning systems — makes the case clearly: the agent runtime is the emerging frontier of AI technical debt, and most businesses are accumulating it without realising.
Just as the original Google paper showed that model code is a tiny fraction of a production machine learning system, the same pattern is repeating in agentic AI. The AI model is a small component. The infrastructure surrounding it — what this analysis calls the "agent runtime" — is where complexity, cost, and risk concentrate. Teams that treat the runtime as an afterthought will spend 12–18 months paying the debt back.
What Is the Agent Runtime — In Plain English
Think of it this way. The AI model is the brain. The agent runtime is everything else — the environment the brain operates in, the tools available to it, the files it can access, the memory it can draw on, and the rules governing what it can and cannot do.
Technically, the runtime has six components. In business terms:
| Runtime Component | What It Is | Business Analogy |
|---|---|---|
| Compute substrate | Where the agent actually executes its work | The laptop or workstation the employee uses |
| Filesystem | What data and files the agent can read and write | The employee's file access permissions |
| Tools | APIs, browsers, code executors the agent can call | The applications installed on the employee's machine |
| Network boundary | Which external systems the agent can reach | Which websites and services the employee can access |
| State model | What the agent remembers across tasks and sessions | The employee's notebook and working memory |
| Lifecycle controller | How the agent starts, pauses, resumes, and shuts down | HR: onboarding, shift management, termination |
Each of these components is a decision. Most organisations deploying AI agents today make those decisions informally — in a sprint, as part of a prototype, without considering production implications. That is precisely how technical debt originates.
Why Containment Is Not Optional
AI agents — unlike traditional software — take actions. They browse the web, execute code, write to databases, send emails, call APIs. This is their value. It is also their risk. The research identifies four reasons why proper isolation of agent environments is a business-critical requirement, not an engineering nicety.
1. Mistake Containment
AI agents make mistakes. They hallucinate commands, misinterpret instructions, and occasionally execute destructive operations — deleting files, overwriting records, sending premature communications. In an isolated environment, a mistake affects only that agent's contained workspace. Without isolation, a single agent error can cascade into your production database, your customer records, or another user's session. The principle is the same as financial controls: limit the blast radius of any single failure.
2. Protection Against Manipulation
AI agents that read emails, browse websites, or process documents are vulnerable to a class of attack called prompt injection — instructions hidden inside external content designed to hijack the agent's behaviour. A malicious instruction buried in a customer email could, in an unprotected system, tell your agent to forward data, ignore its guardrails, or take unauthorised actions. Proper isolation limits what a successfully manipulated agent can actually reach — containing the damage to the isolated environment rather than your live systems.
3. Reliable AI Training
If your organisation is training AI agents — rather than simply purchasing pre-trained ones — each training run requires complete isolation from every other. Without it, one failed training step contaminates the entire training process, and you cannot reliably reproduce results. At the scale serious AI training requires, this is the difference between weeks of recoverable experimentation and months of corrupted data.
4. Reproducibility When Things Go Wrong
When an AI agent fails partway through a four-hour task, the question is: can you replay exactly what happened? Properly snapshotted, isolated environments turn production failures into reproducible test cases. Without them, debugging is guesswork. You know the agent failed. You cannot know why.
Standard containers are not sufficient. The common assumption — that containerising an agent is adequate isolation — is mistaken. Containers share the underlying host infrastructure with other workloads. A sophisticated exploit or misconfiguration can affect all containers on the same host simultaneously. Proper agent isolation requires separate execution environments entirely, not partitioned sections of a shared one.
The Silent Quality Destroyer: Training-to-Production Mismatch
This is the finding that most businesses miss entirely — and the most consequential one.
AI agents are not just run in production; they learn during training. During training, the agent's behaviour becomes finely calibrated to its environment: the tools available, the response times it expects, the error formats it encounters, the way its filesystem is laid out. That calibration becomes part of how the agent behaves.
When the training environment differs from the production environment — even subtly — the agent performs worse in production than in testing. Not dramatically worse. Subtly worse. Mysteriously worse. The kind of worse that generates months of debugging, prompt engineering attempts, and escalating support tickets before anyone identifies the real cause.
An agent that achieves 92% accuracy in your test environment may deliver 76% in production — not because the model changed, not because the data changed, but because the environment changed. No amount of prompt engineering fixes a runtime mismatch. You are tuning the wrong variable.
The analogy: imagine training a new employee entirely on version 1.0 of your internal systems, then on their first day deploying them to version 2.3. The menus are slightly different. The response times are different. The error messages are different. They will make more mistakes and take longer — not because they are less capable, but because their mental model of the environment no longer matches reality. The AI version of this problem is silent, invisible to standard testing, and compounds over time.
The research outlines three ways to address this — in plain business terms:
- Use the same infrastructure for training and production. This is the most straightforward solution and the one that provides the cleanest result. The trade-off is vendor dependency.
- Define a strict environment contract. Specify precisely what the agent can rely on — tool response formats, latency ranges, error structures — and enforce that specification consistently across training and production environments.
- Build robustness deliberately during training. Introduce controlled variation — slightly different response times, occasional simulated failures — so the agent learns to handle environmental inconsistency rather than depending on a specific configuration. Research on this approach (Step-DeepResearch) reports meaningful accuracy gains from introducing 5–10% error variation during training.
The worst outcome — and the one most teams fall into — is choosing production infrastructure independently of training infrastructure, then spending quarters chasing unexplained agent inconsistency without ever identifying the root cause.
What This Means for Your Business Today
Whether you are buying AI agents from vendors or building them internally, the runtime question is one you need to be asking. Here is how it translates into practical decisions.
If You Are Purchasing AI Agents
Most vendor conversations focus on model capability, accuracy benchmarks, and integration options. Add these questions to that list:
- What does this agent run on in production? If the vendor cannot answer clearly, that is a red flag about the maturity of their deployment.
- Does the production environment match the training environment? If the answer is "we don't know" or "approximately," you have a runtime shift risk in your contract.
- If the agent makes a mistake, what can it actually affect? Understand the blast radius. An agent with broad system access and no isolation is a different risk profile than one running in a contained workspace.
- How long does it take for an agent session to start? Agent productivity is bounded by infrastructure startup time as much as by model speed. A 30-second cold start on a task the agent handles 10,000 times a day is a measurable operational cost.
If You Are Building AI Agents Internally
The infrastructure decision is a strategic one, not a DevOps detail. The research cites Ramp — the US financial technology company — as a reference point: their engineering team built coding agents that now author more than half of all merged pull requests. They achieved this not by finding a better model, but by engineering the runtime — optimising session startup time, state persistence, and tool availability. The agent's productivity was bounded by how fast the infrastructure could initialise, not by how fast the model could generate tokens.
The critical implication for teams building internally: your choice of sandbox infrastructure is a decision with a multi-year cost horizon. Switching runtime environments after 12 months of production use is typically a 6-month engineering project. The agent's behaviour has become entangled with the specific characteristics of its current environment — tool latencies, file system layout, error formats — in ways that are difficult to untangle cleanly.
Make the runtime decision jointly with the training decision. The two cannot be made independently. If your data science team selects a training environment and your platform team independently selects a production environment, you have created a runtime mismatch before your first deployment.
The Broader Pattern: This Is Technical Debt You Cannot See
The original 2015 Google paper — "Hidden Technical Debt in Machine Learning Systems" by Sculley et al. — established that the model code in a production machine learning system represents a small fraction of the overall system. The surrounding infrastructure — data pipelines, serving systems, monitoring, configuration management — is where complexity accumulates and where most engineering effort is actually spent.
Han Lee's 2026 analysis applies the same lens to agentic AI and draws the same conclusion: the model is not the system. The runtime is a substantial, often underestimated component of the system — and it is where the next decade of AI technical debt will be generated.
The pattern is consistent. Teams choose a runtime environment during a prototype sprint. The prototype works. Production is deployed on nominally similar but subtly different infrastructure. Issues emerge — inconsistency, unexpected failures, quality degradation. The team adds retries, increases timeouts, adjusts prompts. The agent's behaviour becomes entangled with its runtime quirks. Over time, switching becomes prohibitively expensive. Nobody planned for this. It accumulated naturally, one pragmatic shortcut at a time.
Runtime debt is not visible in quarterly reviews, model accuracy reports, or user satisfaction scores — until it is severe enough to cause a major incident or a re-architecture project. The organisations that will have a structural advantage in enterprise AI over the next three years are those making deliberate runtime decisions today, not those optimising model selection.
The Question Has Changed
For European business leaders evaluating or scaling AI agents in 2026, the strategic question is no longer "which model should we use?" The foundation models are good enough. The question is: "what infrastructure will our AI agents live on — and have we made that decision consciously?"
The organisations that answer that question deliberately — choosing runtime infrastructure with the same rigour they apply to model selection, ensuring training and production environments are aligned, understanding the containment properties of their agents — are the ones that will build reliable, scalable agentic AI. The ones that leave the runtime as an implementation detail will be debugging mysterious inconsistency for years.
This is not a warning about a future risk. It is a description of what is already happening in organisations that deployed AI agents without asking the question.
This article draws on analysis by Han Lee (2026): "Hidden Technical Debt of AI Systems: Agent Runtime" — an extension of the landmark Sculley et al. (2015) paper "Hidden Technical Debt in Machine Learning Systems" (Google, NeurIPS 2015).
Read the original technical analysis