Agents Degrade Quietly: Maintenance Is Where the Value Compounds

Building an agent produces a visible artifact — there was nothing, now there is a working agent — so it reads as progress. Maintaining one produces no artifact; at best, nothing happens. So effort flows to building, and the felt value inverts the real value. A well-built agent nobody maintains degrades on a schedule: its context sources go stale, its permissions drift wider than its job, its instructions calcify into a patch pile. A modestly-built agent someone reviews weekly compounds — each pass prunes a failure mode and sharpens the job. This is the oldest lesson in operations wearing a new costume: prevented loss is invisible, which is why nobody celebrates the on-call review that kept the incident from existing.

The corrective is ownership, and it decomposes into four responsibilities I now require for any agent near production work: define the job narrowly (a vague agent is an unowned agent waiting to happen); curate the diet — what it reads, which examples it learns from, including rejected outputs so it learns what not to do; manage permissions proportional to stakes — draft-only and write-access are different categories, and write access is earned inside a narrow job, not granted because a demo looked good; and run the review loop, where one-off failures get fixed at the output level but recurring failures get fixed at the system level. Team agents fail by tragedy of the commons — the pain is collective, the maintenance is nobody's job — so the owner follows the work. An agent is not a feature you ship. It is a service you operate.