The hidden technical debt of agentic engineering
Autonomous Engineering
SubscribeSign in
The hidden technical debt of agentic engineering<br>Agents are easy to build but hard to run. At Port, we mapped seven blocks of hidden infrastructure debt with AI agents in enterprise systems.
Zohar Einy<br>Apr 03, 2026
Share
Anyone today can build an agent locally with minimal effort. With some LLM calls, a prompt, and a few tool definitions, that agent will be doing real work for them within minutes. But what happens when that agent needs to get into production and be used by the entire engineering department, with real data and real consequences?
Thanks for reading Autonomous Engineering! Subscribe for free to receive new posts and support my work.
Subscribe
In 2015, Google published “Hidden Technical Debt in Machine Learning Systems.” That paper turned on the light for machine learning engineers and named all the problems they were experiencing. The diagram they shared also became iconic: a tiny box labeled “ML Code” surrounded by massive infrastructure blocks.
We’re seeing the same pattern for agents. Agents are a small part of the picture, and we want to name all the infrastructure around them.<br>Agentic engineering systems are especially good at piling up technical debt. They carry all the maintenance problems of traditional software, plus an additional set of agent-specific issues. New agents are being created daily by nearly every employee. Soon you’ll have far more agents than employees.<br>We define an agent as any process with dynamic decision-making capabilities that can autonomously determine tool usage and execution paths through reasoning and reflection. Decision-making, reasoning, and reflection require all the supporting infrastructure.<br>Building an agent is easy. But in production, the agent code is the smallest part of the system. Everything around it is where the actual complexity lives.
Over the past few months, through conversations with engineering leaders and our own experience, we’ve mapped out seven infrastructure blocks that surround the agent. Each one is a category of work that no one plans for when building their demo.<br>Some of these blocks will look familiar if you’ve done traditional engineering: observability, integrations, and governance. Others are unique to agents, such as human-in-the-loop, evals for non-deterministic systems, and the agent registry.
Let’s walk through each one.<br>1. Integrations
Agents need to reach your actual systems: CI/CD, cloud providers, incident tools, observability platforms, code repos, secret managers, and more.<br>Without centralized integrations, every team wires up its own connections to agents.<br>Picture an engineering org with 200 engineers on 30 teams, each with multiple agents. Each engineer generates their own GitLab PAT for coding agents, Snowflake credentials for data agents, Kubernetes service accounts for deployment agents, and monitoring tokens for incident agents.<br>That’s hundreds of integration points, each one configured individually, debugged individually, and expiring on its own schedule.<br>When every developer wires their own credentials, each agent sees different data depending on whose token it uses. One developer’s GitLab PAT has access to all repos. Others are scoped to their team. Same agent type, but each has a completely different view of the org.<br>Or, what happens when GitLab ships a breaking change to their API? Every team that wired its own connection independently debugs the same issue (or submits a ticket to the platform team). Three teams figure it out on Monday. Two more by Wednesday. One team doesn’t notice for a week because their agent only runs during incidents.<br>What also matters is what comes through those integrations. When three teams connect to the same data source through different paths, their agents can get different answers to the same question. If one team’s integration pulls a 30-day history of deployments, and another team’s integration shows everything from the last 3 years, their outputs will differ.<br>Right now, MCP is how most teams connect agents to their tools. But let’s not confuse MCPs with integrations. MCP gives agents a standard way to call a tool. It doesn’t manage the credentials for that call, the scope of the data that comes back, or what happens when the API on the other end changes.<br>Hidden tech debt in integrations looks like:<br>An integration auth token expires on a Friday night, and an incident agent silently stops working. Nobody notices until Monday.
Five teams each maintain their own GitLab connection with different permissions and scopes, unaware that the others exist.
When an integration updates its API, and every team debugs its connection separately.
2. Context lake
Agents are only as good as the context they can reference and use. They need two kinds of context.<br>Runtime context: How do you deliver accurate context to agents during their execution?<br>The runtime context is the live data that...