Which agents are running, who signed off on each, and what rolling one back involves: usually the answer is a file somebody edits by hand. It is true until it isn't.
Ask which agents are deployed right now, what each contains, whose sign-off put it there, and what a rollback involves — in most places the honest answer is: open the file. Somebody maintains it by hand. It is accurate as of the last time that person remembered, which is fine until the day it isn't.
The request arrived as an escalation rather than a feature ask: an enterprise-level way to track engine deployments, registry images, the source pull requests and issues behind them, approvals and rollback detail — explicitly in place of a file in a repository. That is the client's framing of the gap, not one a delivery team invented for it.
On one stage environment the deployed engine count had reached 86. Nobody set out to accumulate 86 of anything: every one was a reasonable thing to build on the day it was built, and nothing in the process obliged anyone to update the registry or delete a predecessor once a newer build replaced it. Deploying is easy, listing is nobody's job, and the two diverge quietly. Read that as one stage environment, not a figure typical of anything.
Sprawl is the visible half. The half that hurt was a deployment that went out without passing through the record-keeping step and had to be reconciled afterwards: a later change named the engine to roll back to and put the deployment record straight. Afterwards it was accurate again. In between, what was written down and what was running were two different answers, with nothing outside to tell you which you were reading. An inventory only has to be wrong once, briefly, at the moment somebody needs it.
The retention rule and its pruning script are half the fix, and how the script refuses to run matters more than what it deletes: it runs dry by default, and applying it for real takes both an explicit flag and an explicit name-prefix scope. Fourteen stale engines were deleted on that environment, taking 86 to 72. When the count was taken, eighteen more qualified under the same rule — they belonged to a different agent, under a different engineer. That is why the scope is mandatory: pruning one agent's stale engines must not reach into another engineer's, and structurally cannot.
The other half of discoverability is not which agents exist but what any one of them can touch, and that half is answerable independent of the count. On the agents running over live ERP data, nothing reaches the warehouse directly: every call goes through one shared governed tool service exposing nineteen fixed tools over curated views. The SQL is parameterised and the agent never writes it. Four boundaries stand independently of one another — identity, tool definitions, engine configuration, IAM — each verified live rather than assumed. Reach is a function of that tool list, not of whichever engine revision is live, so even at 86 engines there was a bounded answer. Pruning fixes how many copies exist; the boundary fixes what a copy can do.
A structural answer to the same gap showed up on a self-service platform for a regulated enterprise: pushing to git carries an app through a build, into a registry, and out to a deploy, with production held behind a human approval. Anyone can deploy to a development environment; only privileged users promote. Six pilot apps went out that way, over three pipeline templates built for reuse. Because every deployment travels the path, the record of what shipped and who approved it is a by-product of shipping rather than a second artefact someone must remember to update — the property a hand-maintained file cannot have.
Rollback targets go in order of blast radius, least dangerous first: the stateless service and tool layer, then the agent or model layer, then data views. A rollback passes the same validation as a forward change; moving backwards is not evidence of safety. If a second component changed in lockstep, reverting one alone is unclean, so the record names the matched set rather than a single identifier. And either the rollback record gets written as the promotion happens or it never gets written; where it and the running system disagree, re-verify what is actually running and correct the file.
Look again at what the escalation asked for: deployment records; registry images; the pull requests and issues behind them; approvals; rollback detail. Pruning on a retention rule touches the first of those, on a single environment. The eighteen engines still qualifying when the count was taken say the rest out loud: this is a cadence, not a fix, and sprawl builds back up by the same route that got it to 86. Pruning also does nothing about the reconciliation failure mode — removing engines that should not exist does not stop a deployment going around the record-keeping step. The distance between a smaller environment and being able to say, at any moment, which agent is running and how to roll it back is the gap the escalation named, and it is still open.
Get in touch
Tell us what system the answer lives in and who needs it. We'll reply with a view on whether it's a two-week assessment, a five-week pilot, or something else.