The agent nobody remembers deploying

It exists

It's running. Someone depends on it. And the person who built it has changed teams, changed companies, or simply doesn't remember the details because it was eight months ago.

That isn't a sign of a badly run organization. It's the natural consequence of building agents having become easy. When the technical barrier drops, adoption happens before governance, and that's been true of every technology that has gone through this.

The problem isn't that it exists. It's that nobody knows it exists until they need to.

Four roads to that day

An orphaned agent stays invisible as long as everything works. It surfaces in one of these four ways, and none of them come with a warning.

The model is deprecated. The provider announces an end-of-life date for a model. Someone has to find out which agents use it. If there's no list, you find out when things break.

A policy changes. A new requirement, regulatory or internal, has to apply to everything in production. The question is how many agents there are, and the honest answer is that nobody knows for sure.

An integrated system changes. The API the agent consumes gets a new version and the old one is shut off. The agent starts failing silently, and since nobody monitors it specifically, the failure shows up as a customer complaint.

Someone asks. A customer, an auditor or an executive wants to know why a decision was made. At that point it isn't just the agent that's orphaned: so is the explanation.

A registry isn't a spreadsheet

The obvious answer is to make a list. And the reason lists don't work is that they're filled in after the fact, out of goodwill, and go stale within weeks.

What works is making registration a condition for being in production, not a form someone fills out when they remember. An agent without a declared owner, environment and version doesn't get deployed. Not because a bureaucratic rule says so, but because the deployment path runs through the registry.

The difference between the two is the difference between a document that describes reality and a mechanism that produces it.

The full lifecycle, and the step everyone skips

An agent has four stages, and most organizations handle two of them well.

Registration, when it starts to exist for the organization, with an owner, an environment and a version.

Deployment, when it goes to production, with the same procedure on every team, and a way back.

Operation, its life in production, monitored as an entity of its own rather than as a log line from some service.

Decommissioning, the step almost everyone skips.

Leaving production needs a date and an owner, exactly like entering it. Without that, what piles up isn't a forgotten agent: it's an agent that keeps consuming resources, keeps its access to the systems it had, and can keep making mistakes on the company's behalf, for a process that no longer exists.

An agent nobody switched off is the quietest form of operational risk a fleet produces.

What an inventory doesn't solve

It doesn't stop anyone from building outside it. A team determined to deploy around it will manage. What the registry does is make that absence visible: when the inventory is the source of truth, whatever is outside it shows up as a gap, not as business as usual.

It doesn't assess quality. Knowing there are forty agents with a declared owner and version doesn't tell you whether they do their job well. An inventory is a precondition for governance, not governance itself.

And it doesn't replace the conversation. The registry says who the owner is. It doesn't guarantee that person knows it, or has the time. A name in a field isn't an agreement. Explore Agents.