Agents made execution cheap. The bottleneck moved to what the agent knows before it acts.
There is a conversation happening in almost every engineering organization right now. It starts in a board meeting or a budget review and lands on a VP of Platform Engineering as a question that sounds almost like an accusation: "We're paying for coding agents. Why is our end-of-life backlog still growing? Can't an agent just fix it?"
So teams try. The agent gets repository access, picks a finding, bumps a version, and opens a clean pull request with a confident description. The demo is impressive. Then someone asks what breaks, what order the prerequisites have to land in, who owns the service, and whether this is even the highest-priority issue. Nobody is sure. The PR sits for a week, then quietly dies.
Meanwhile, some platform teams are actually burning down technical debt with agents, using the same models and often the same tools. The difference is what the agent knows before it acts.
We've seen this movie before. Engineering maintenance has already failed three times.
The spreadsheet years
Maintenance lived in people's heads and in spreadsheets. The knowledge was real, but it was tribal. When the engineer who understood the Kafka upgrade path left, the upgrade path left with them.
The detection boom
Then scanners solved discovery. Every organization could suddenly produce a report showing hundreds of end-of-life components. The report went over the wall to developers with one instruction attached: fix it. Backlogs exploded, because detection improved by an order of magnitude while everything downstream stayed manual.
The glue years
So platform teams built the missing pieces themselves: policies, cron jobs, scripts stitching scanner output to inventories nobody fully trusted, dashboards layered on top. It worked until the person who built it left.
Now agents promise that execution is nearly free, and that part is mostly true. But every era broke at the same point. Between a finding and an action sits judgment, and nobody has built the layer that provides it.
Two ground rules fall out of this history.
Detection is a commodity. Interpretation is the bottleneck. Nobody needs another dashboard counting end-of-life components. The hard part isn't finding problems. It's deciding what should happen next.
An agent's judgment is capped by its context. A frontier model with no understanding of your systems is a brilliant new hire on their first day, holding production credentials. Intelligence isn't the constraint. Context is.
The maintenance context layer
Before an agent, or a human, changes anything, five questions need answers.
1. What breaks if we touch it? Breaking changes, prerequisites, upgrade sequencing. An upgrade plan is a dependency graph, which makes it something you compute, not something you want a model improvising token by token. Plans should be deterministic. Execution can be agentic.
2. What does waiting cost? Extended support fees, compliance deadlines, outage exposure. Attach money and business risk to a maintenance task and the backlog stops looking like engineering work and starts looking like a balance sheet.
3. When does it become urgent? A component reaching end-of-life next month may deserve immediate attention, while one that expired a year ago in an isolated internal tool might not. Urgency changes continuously. It should be recalculated, not remembered.
4. Who owns the change? The right fix assigned to the wrong team is indistinguishable from no fix at all. Agents actually make this worse, because an unowned pull request is even easier to ignore than an unowned ticket.
5. Did we actually eliminate the obligation? Merged isn't done. Done means the new version is running in production, the maintenance obligation is gone, and the system knows it's gone. Most tools measure activity. Engineering leaders should measure eliminated risk.
Why agents can't skip this
Without this layer, an agent is the detection boom with hands. The scanner used to throw findings over the wall; now the agent picks them up and acts on them, sometimes incorrectly, at machine speed. That's why "just let the agent fix it" keeps dying in the meeting where someone asks how it knows this is safe.
With the context layer, the conversation changes. Upgrade these now, they're safe. These require a phased migration. This one is costing real money every month. That one belongs to another team. The agent still executes. The judgment comes from the context.
Context compounds. Models don't.
The model you're using next year probably won't be the one you're using today. But every model will still need to know what breaks, what waiting costs, who owns the work, and when it becomes urgent. Those answers become part of your organization's operational knowledge, and they compound.
That's why we've spent the last two years building what we believe is the missing layer. At Draftt, we call it MaintenanceOS™: a maintenance context layer that continuously turns findings into prioritized, owned, actionable work. Scanners become inputs. Agents become safe.
.png)
