Nestor G Pestelos Jr · Writing · Print

Half of Your Agent Infrastructure Is a Depreciating Asset

Published August 2, 2026. Revised September 2, 2026.

This is the September 2, 2026 version. The current article is at half-agent-infrastructure-depreciating-asset.

TL;DR

AI agent "organization" advice conflates two things: substrate that rots on your own clock and outlives model upgrades, and scaffolding that compensates for today's model weaknesses and mostly depreciates on someone else's release schedule.

The August 2, 2026 version is at half-agent-infrastructure-depreciating-asset-20260802.

There is a piece of advice circulating wherever people build with AI agents: organization matters more than ever. Write the docs. Structure the context. Build the harness. It is half right, and the wrong half is expensive, because two different things are being called organization, and one of them is a depreciating asset.

The craft consensus in software was stated by James Hague, in a passage John D. Cook made famous: the most important skill is not algorithmic wizardry but "how to keep a tangle of features from collapsing under the weight of its own complexity." "To a great extent," Hague wrote, "the act of coding is one of organization. Refactoring. Simplifying. Figuring out how to remove extraneous manipulations here and there." That is an opinion from experienced practitioners, not a measured finding, but it has held up as consensus for a decade. John Ousterhout's design philosophy pulls a different lever on the same problem, how little anyone has to hold: arrange systems so that nobody faces more than a small fraction of the total complexity at once.

Agents appear to raise the premium on all of this. The same model's results depend on the environment it lands in. A smaller toolset means less context to wade through and fewer wrong choices available, and Vercel's team reported exactly that after deleting 80% of their agent's tools, per secondhand practitioner accounts. LangChain, in the same secondhand stack, reported large benchmark gains from changing only the infrastructure around an unchanged model. The two interventions differ, one removed tools and one rebuilt the surrounding infrastructure, and what they share is that neither touched the model. I run a small fleet of agent sessions against one git-tracked knowledge repo, and I see both the harness premium and the environment sensitivity daily. The tempting conclusion is to invest in the harness, since the premium on organization looks compounding.

That conclusion conflates two things that age differently. Some of what gets built around a model is scaffolding: structure that compensates for what today's model cannot do. Task decomposition, elaborate tool routing, attention management, the choreography that keeps a weaker model on rails. Richard Sutton's bitter lesson (general methods that use more computation beat built-in human structure, demonstrated across chess, Go, speech, and vision) was an argument. The one well-documented agent-era case lands on its side: the engineer behind Anthropic's long-running-app harness dropped its sprint decomposition after a model upgrade, the newer model ran coherently for hours without the structure the older one had needed, and the team's stated principle is that "every component in a harness encodes an assumption about what the model can't do on its own." They stress-test those assumptions by removing components one at a time. Most of the assumptions expire on someone else's release schedule; the ones tracking architectural limits (finite context, say) last longer, but even those keep moving. That is the honest evidentiary floor: one well-documented deletion and a thirty-year pattern argued rather than proven.

The rest is substrate: the clean data layer, the real specification, the comprehensible codebase, the documented conventions, the private domain context no model learns from scale. It is Hague and Ousterhout's organization extended into the agent stack, and the part agents raise the premium on, for a reason with measured consequences.

Language models do not use context uniformly. Performance follows a U-shape by position, in the "Lost in the Middle" study: what sits in the middle of a long context is used worse than what sits at the edges. Length is the other axis. Accuracy degrades as input grows, across the eighteen models in Chroma's context-rot report, well before the advertised window is full. Where information is placed and how much surrounds it are organizational decisions with measured consequences.

Luke Pierce adds a different kind of evidence, about sequence rather than context: the construction order that holds up in the field puts the data layer, intake, and routing before any intelligence, because an agent on top of a dirty foundation amplifies the dirt. My own addition is smaller: without specs and documentation, agents guess. I have watched mine do it. I argued in "Cheap Code, Expensive Context" that when code gets cheap, value moves to whoever holds the context.

The lazy cost argument (disorganization burns tokens, tokens cost money) has a short shelf life. Inference prices for fixed capability are collapsing: Epoch AI measures the fall at 9x to 900x per year depending on the benchmark; a16z's earlier estimate, 10x a year, sits at the conservative end of that range. My inference from those curves is that any argument denominated in absolute token dollars depreciates faster than your scaffolding. Your time and the ratio do not deflate. A disorganized system burns more than an organized one at any price level (unstable context collapses cache hit rates, missing specs send agents into guess-and-retry loops), and the hours you spend re-reviewing output that transferred its ambiguity to you are billed at a rate no price curve touches. An agent-written pull request that saves one person ten minutes and costs someone else an hour is, in Hiten Shah's words, debt with a diff attached.

Organizational skill, before agents and after, is subtractive. Hague's advice was to remove, and at Anthropic removal is now routine maintenance. Ask of every piece of structure in your system whether it encodes your problem or this month's model's weaknesses. The first kind, the data model, the spec, the conventions, the documented why, is worth real investment. The second kind you build reluctantly and plan to delete.

The test takes practice, because plenty of pieces are honestly both. My own agent memory is the ambiguous case I know best: the facts it holds (what is true about my system, which conventions bind, what was decided and why) are substrate, and they have outlived every model this year. The elaborate rules around when to compact it and what survives a context reset are scaffolding: they compensate for context limits that keep growing, and I expect to delete them without ceremony. Same file, two clocks. Substrate rots too, of course, but on your clock: a spec drifts when your problem drifts, and you can see that coming. Scaffolding goes when someone else ships a model, on a schedule you neither see nor control.

I hold both kinds, and the substrate pieces of my own setup (git-tracked agent memory, pre-commit guards that stop parallel sessions from contaminating each other's work, conventions files that tell any agent where things live and why) have survived every model upgrade this year, because none of them are built around what a model can't do. They describe what my system is. The scaffolding pieces I try to hold loosely, on the assumption that the next release obsoletes some of them. Whether agents will eventually absorb the substrate work too, writing the specs and owning the data model, is an open question.

Cook's second observation was that organizational skill is barely teachable: you acquire it only by owning a mess you care about, because "you can't appreciate a feat of organization until you experience the disorganization." If agents absorb the day-to-day mess, where does the next person learn? The classroom moves. The mess you now own is the system itself, the agents, the context they see, the conventions they follow, and it degrades visibly when you organize it badly. Anyone running agents seriously has already felt it: the session that burned an afternoon because the context was stale, the output that had to be re-reviewed because the spec lived in someone's head. The skill is still learned the way Cook said. The tangle just moved up a level.

Sources

Back to top