Another Word For Technical Debt is Maintenance
Or What Companies Who 'Roll Their Own Agents' Need to Remember
Agents wear out.
It happens in a variety of ways. And the closer your work is to agentic engineering, the more complex those ways become.
Sidequest:
This diagram is how Google currently imagines the necessary components of agentic architecture (white paper, audio summary). They say, “Model = LLM (10%) + Harness (90%).” They mean that the integrated pieces of agentic design include:
Specification
Instruction
Evaluation
Testing
Guardrails
Orchestration
Deployment
Scaling
Governance
Security
Memory
It’s where all of the development work lives. In the image, the LLM is in the center. Everything else is the harness.
This is a large and complex rabbit hole. At the frontier, agentic engineering is remarkably sophisticated, and getting more so. As it evolves, it looks less and less like hobbyist tinkering and more like a form of enterprise software development. Just because you can build using natural language doesn’t mean that you’ve figured out how to control the LLM.
Each of those eleven components also ages on its own clock, which is exactly why this gets complicated.
Back to the Mainquest:
Work, with the possible exception of high-volume, repetitive tasks, is an emergent phenomenon. As time passes and the world changes, so do processes, methods, tools, and outcomes. Even though organizational structure, team composition, and job titles remain somewhat fixed, the content of the work changes with circumstance. This is part of the reason that job descriptions and jobs so rarely match up.
It gets worse with agents. The harness drifts naturally while the underlying model gets better. Harnesses are partly built to compensate for a model’s specific blind spots and failure modes; when the model improves, those blind spots shift, and the guardrails, prompts, and evaluations built around the old ones quietly stop matching what’s actually in front of them. Each of the layers of the harness decays at different speeds. Sooner or later, the agent needs to be recalibrated, updated, repaired, or replaced.
This is in addition to the natural drift of the job itself.
Recalibration means re-running the evaluation suite against the new model to see which guardrails still catch real problems and which are now just ceremony. It means rewriting instructions and prompts that were quietly compensating for a weakness the model no longer has. It means reexamining and revising the fundamental specification. And it means deciding, layer by layer, whether to patch, replace, or retire, because not every part of the harness breaks for the same reason or on the same schedule.
That sounds like a job description.
Organizations already employ people whose entire function is to notice this kind of drift in software systems and correct for it: site reliability engineers (SRE) exist because infrastructure and demand evolve at different rates, and someone has to keep them aligned. Agents have the same problem on a faster clock with more dimensions, since the model underneath can change on a vendor’s release schedule rather than a depreciation schedule. Does that make “agent reliability engineer” a coming job title, the same way SRE became one for infrastructure?
Maintenance, in the end, is the process of keeping purpose and function aligned. For an agent, purpose changes faster than function does, which means maintenance isn’t a one-time setup cost. It’s the what you have to do for the agents you build. It’s the job.
Photo by John Cardamone on Unsplash