The_Add-Everything_Instinct

You start with one agent. It does one thing. Then you add a tool because you need it to cross-reference something. Then memory, because you want it to carry context between sessions. Then a routing rule, because you have three agents now and something needs to decide which one handles what. Then a special case, because one of the agents keeps doing something that makes sense in isolation but breaks the chain.

After six months, the setup looks capable. It is also harder to trust.

Not because any one piece is wrong. Each addition made sense at the time. But the harness - the workbench the agents sit inside - has accumulated all of it without a corresponding pass to examine what still belongs. What the agent reads. What it is allowed to touch. What it is supposed to bring back. The harness is not the agent. It is the structure that makes the agent's work legible and bounded. And it can become unmaintained while every individual agent inside it looks fine.

The beginner instinct is to add. The maintenance instinct is to ask what should be removed.

Agents_Break_in_Two_Directions

Here is the thing I was not prepared for when I started running a fleet seriously: an agent harness can break in two directions, and only one of them gets talked about.

World drift is the familiar one. Your process changes. A routing rule you wrote four months ago reflects a workflow that no longer exists. Documentation that was accurate in January is now misleading in June. The agent does not know any of this. It keeps working from the premises it was given, confidently and without error. Stale context does not throw an exception. It produces plausible-but-wrong output that someone has to unwind later.

The thing that makes world drift insidious is that "silently wrong" is its failure mode. Code that is broken errors out. A stale context file does not. The agent summarises, routes, drafts, and decides - all from premises that no longer map to reality - and nothing in the output announces that something is off. You have to go looking for it. Most people do not go looking until something specific breaks.

Model improvement is the direction nobody discusses. Because we are used to software breaking when the underlying components get worse, not when they get better.

When a model's capabilities increase, the harness built for the older, less capable version can become the constraint. A rule that protected you from an unreliable agent can trap a capable one. Workflows that forced structure around a model that needed hand-holding become drag when the model can handle the work itself.

A specific example from my own fleet: I had built a confirmation gate into my orchestration agent - a step that required explicit approval before any batch of tasks was dispatched. At the time this was right. The model's judgment on task scope was inconsistent and the gate caught errors regularly. When the underlying model improved significantly, the routing accuracy climbed and the gate stopped catching anything real. It was just producing delay. I spent several weeks adjusting the gate's threshold before I realised the gate itself was the problem. Removing it entirely took ten minutes. That is the maintenance question the upgrade conversation never surfaces: not "what does this agent need now?" but "what did it need before, that it no longer needs, that I have not yet removed?"

I built my fleet's permission structure - what each agent can touch, how much autonomy it is granted before routing to review - around the models I had at the time. As the models improved, some of those restrictions stopped making sense. An agent operating under narrow permissions written for a weaker version is an underused agent. But the failure runs in the other direction too: a model that is now capable enough to take twenty plausible actions in a few minutes is running inside a harness written for a slower, more supervised version of that same agent. The old harness assumed a human would review each step. The new model does not need that supervision - but nothing in the harness has registered that the situation changed.

Neither failure is loud. Both accumulate.

The two directions together define the maintenance problem. The harness has to keep up with the world changing around the agent and the model improving inside it. That is not a one-time build. That is an ongoing discipline.

What_the_Maintenance_Discipline_Actually_Looks_Like

I am a solo operator. I do not have a team to distribute this across. Every harness decision lands on one person, which changes the economics of maintenance in ways that enterprise examples do not capture. I cannot afford to let the harness accrete unexamined. I also cannot afford a maintenance process that takes longer than the work it is maintaining.

What I have landed on is five questions I run against any agent setup, on a cadence that is more honest than "scheduled review" - which in practice means whenever something starts to feel off, or when a model version changes, or when a project scope shifts enough that I know the premises have moved.

What is it reading? Are the sources current? Did the workflow change in a way the agent's context does not yet reflect? Did a document become the de facto reference for something the agent is deciding, without the agent knowing it is supposed to be looking at it?

What can it touch? A permission that was appropriately narrow for a weaker model may now be too restrictive for a stronger one - or, in the other direction, too broad. A model capable enough to act quickly on ambiguous signals needs tighter permission boundaries, not looser ones. The question is whether the current permission set matches the current capability, not whether it matched six months ago.

Is the job still right? Agent scope drifts without formal announcement. An agent that started as "summarise what you see" can quietly become "recommend next steps" through accumulated prompt changes that each seemed incremental. If the job has changed, that should be a deliberate decision. Name it on purpose. The harness should reflect the job the agent is actually doing, not the job it was originally built to do.

Does it bring proof? The agent should not just say what it found. It should show the trail: source links, named limitations, what it could not access and why. Vague confidence was one thing when the output was text for a human to read and interpret. With agents that act on their own output, or whose output feeds other agents, vague confidence is not enough. The downstream agent inheriting a summary with no sourcing is working blind.

Is it still earning its keep? Does the output actually get used? Does it save time after review, or create a new pile of review work? Has the model improved enough that the agent should be rebuilt from different premises? Has the work changed enough that the agent should be retired?

That last question is harder to ask than it sounds. Agents you have invested time in building carry a kind of sunk-cost gravity. The maintenance discipline requires being willing to answer honestly.

The_Real_Work_Starts_After_You_Ship

The public conversation about agents is almost entirely about the build: what model to pick, what tools to wire up, how to chain the steps. How to get to something that works.

Almost nothing is written about what keeping it working actually requires - and that is where the real work is. Not because the build is trivial (it is not), but because the build is a bounded task with a visible end. The maintenance is continuous, less legible, and structurally underestimated by almost everyone who gets excited about what agents can do.

What I am describing is not glamorous. There is no satisfying launch moment for "updated the routing rules to reflect the workflow change from March." There is no version number for "rewrote the permission structure because the model is now more capable than the harness assumed." But these are the decisions that determine whether a fleet compounds over time or quietly corrodes.

An agent that runs on a well-maintained harness produces consistent, trustworthy work. An agent running on a harness nobody has examined since it was built produces output that looks plausible until it doesn't. The gap between "last maintained" and "now" is where the cost of deferral lands.