The Agent that doesn't need a rewrite

Every stalled agent project I have looked at contains a version of the same sentence: "we need to modernize the platform first."

The agent was approved in January. By March it is a replatforming project with an agent attached. By budget review there is a half-finished service extraction, no agent, and an executive asking what the money bought. I wrote earlier this year about why agent projects get canceled. This is one of the quieter ways: the agent never ships because it got in line behind a rewrite.

Underneath is a premise that agents are a new kind of software deserving a new kind of architecture. Mostly they are not. The agent that survives its first year in production is usually a thin layer over the system you already have. Your ten-year-old codebase is not the obstacle. It is the asset.

Why the rewrite instinct fires

The reasons are human, and they deserve naming rather than mockery.

Every agent framework demo starts from an empty repository, so the imagination starts there too. Vendor decks sell platforms, because platforms are what vendors price by. And somewhere on the team is an engineer who has wanted to replace that legacy service for years. The agent is the first budget line that might pay for it.

That last reason is the dangerous one, because nobody says it out loud. The rewrite arrives dressed as a prerequisite.

What an agent actually needs from your system

Strip the vocabulary and ask what an agent requires. It needs named operations it can call, with typed inputs and typed results. It needs those operations to check permissions and record what happened.

That is a tool schema. You already have one. It is called your service layer.

The controller that has validated form submissions for eight years can validate an agent call. The authorization check, the audit log, the rate limit: all of it transfers. In this story that code is not technical debt. It is precisely the hardening an agent needs, and precisely what a rewrite throws away and then rebuilds under deadline pressure, minus the eight years of production traffic that made it trustworthy.

So the integration most teams actually need is unglamorous. A thin schema that maps tool names onto existing endpoints, with descriptions written well enough that a model can choose between them. Days of work. Weeks at the outside.

The two things you do have to build

Two things do not transfer, and they are where the real engineering lives.

The first is idempotency. Agents retry. For a human, submitting twice was an edge case worth a confirmation dialog. For an agent, retrying is how it recovers from ambiguity, which makes it the default path, not the exception. An operation that creates an invoice must be safe to call twice with the same key and still produce one invoice. If your write paths do not accept an idempotency key, that is the first change worth making. Notice that it makes the system better whether or not the agent ever ships.

The second is bounds. A person gives up after the third failure. An agent will keep trying until the rate limiter or the finance team stops it. Every agent-callable write needs a budget: attempts, spend, blast radius. When the budget is exhausted, the correct behavior is boring. Stop, record what happened, hand the case to a person. The teams that skip this learn it from an invoice, and the lesson costs more than the engineering would have.

Reads and writes deserve different generosity here. Give the agent broad read access and let it be wrong in drafts. Gate every write behind the narrow, keyed, bounded path above. Most of an agent's usefulness lives in reads anyway.

I keep relearning this with my own agents. The setup I run coding agents in is not a platform. It is a set of plain files describing what already exists: which commands are safe, what each one assumes, where the boundaries are. Every meaningful improvement in the past months came from making those descriptions truer, not from new infrastructure. The system was never the problem. The description of the system was.

When the rewrite is real

Sometimes there is no seam to attach to. The logic lives in stored procedures, or the codebase has no service layer at all, and the tool schema has nothing to map onto.

Even then the sequencing holds. Carve the one seam the agent needs. Do not build the platform you wish you had. A rewrite justified by an agent is still a rewrite, and it carries every rewrite risk at agent-project speed, reviewed monthly by people who were promised an agent. The narrow carve is reversible. The replatform is not.

The test

If the agent project were canceled tomorrow, would the work be worth keeping?

Idempotency keys on your write paths: yes. Operations described precisely enough for a model to use them, which is to say documented: yes. Bounded, audited, permission-checked mutations: yes. A half-finished replatform: no.

Build the things that are worth keeping either way. That is not a compromise position. It is what making an existing system agent-ready actually means, and it is weeks of work, not quarters.

brimtech works with engineering teams running AI inside systems they intend to keep. If your agent project has quietly become a rewrite project, the Agent Production Audit is where we usually start: two weeks, your real system, a measured baseline, and a ranked fix list. Essays like this one go to the list first, along with the production-readiness checklist.