The_Problem_With_a_Name

In June 2026, Nate's Substack named the problem I had been circling for months without a phrase for it. Unowned, drifting agents - the ones nobody has assigned, nobody is reviewing, nobody would know how to shut down - are the haunted house of multi-agent AI. The lights are on. Something is running. You are just not sure what.

I had been running twelve specialised agents across roughly fifteen repositories for long enough that the mental map had started to blur. The governance layer I built early - ownership assignments, scope contracts, trust tiers - was still in place. But the edges had drifted. Agents spawned for a specific task and never formally retired. Context files updated for one project that had quietly fallen out of sync with another. Tool definitions still referencing credentials for services that had been replaced. None of it was broken enough to surface in any single session. All of it was undefined enough to matter the day something went wrong.

When Google DeepMind published its AI Control Roadmap that same week, it framed the problem at enterprise scale: monitoring opaque agent reasoning at scale is the open question - not whether oversight itself is necessary. The solo-builder version of that question is smaller but more immediately actionable. You do not need a control platform. You need an audit.

What_Makes_an_Agent_a_Ghost

An agent becomes a ghost when three conditions converge: no current owner, no recent invocation, and no documented decommission plan.

Any one condition is a yellow flag. All three together mean the agent's definition is still in your system, still potentially invocable, but nobody is responsible for it being correct. Its scope contract may describe capabilities the agent no longer has. Its trust tier may not reflect the sessions it has actually run. Its credentials may belong to a service that has since been replaced or restricted.

The ghost does not announce itself. You discover it when you go looking - either during an audit, or when something breaks and the trail leads somewhere you did not expect.

There are predictable entry points: agents built for a specific one-off task and never retired; agents whose scope was updated in one place but not propagated to all the places; agents spawned in a parallel workflow that was later collapsed into a single agent; agents that were experimental and "good enough" to leave running. The pattern is not negligence. It is the ordinary byproduct of building fast without building decommission logic in from the start.

The_Audit_Checklist

This checklist is concrete and can be run against any solo-scale agent system in a single session. It is organised around the three ghost conditions: ownership, invocation, and currency.

Ownership

List every agent definition in your system - persona files, context files, subagent spawn definitions, scheduled job references. This list is the inventory. (The enumeration step almost always surfaces something you did not know was still running.) For each agent, confirm: who is responsible for this definition being accurate and current? If the answer is "nobody" or "unclear," mark it for review. (In a solo system, "nobody" usually means "me, but from the version of the project I was running two months ago.") Confirm ownership is documented in the agent definition itself, not only in your memory or in a separate registry. If the owner can only be determined by reading your mind, it is not documented.

Invocation

For each agent, determine when it was last invoked. For scheduled agents, check run logs. For on-demand agents, check session history. (Do not rely on your mental model of what is running - query the actual logs; the gap between what you believe ran and what ran is reliably larger than expected.) Identify agents that have not been invoked in the last 30 days and have no scheduled future invocation. These are inactive. (Thirty days is a reasonable default; the threshold that matters is the one you documented at build time, not the one you invent during the audit.) For inactive agents: determine whether inactivity is expected (seasonal, project-bound) or unintentional (forgotten, orphaned). Expected inactivity with a documented resume condition is not a ghost. Unintentional inactivity is. (The distinction is not the length of the gap - it is whether someone decided on the dormancy or it just accumulated.)

Currency

For each agent, compare the current definition against the current state of what it is meant to do. Are the tools it references still active? Are the credentials still valid? Is the scope contract still accurate for the projects it touches? Identify agents whose definitions reference a tool, service, API, or project that has since been retired, renamed, or replaced. (This is the most common currency failure: the agent file looks current, but the thing it points to is not.) Identify agents whose trust tier was set at build time and has not been reviewed since. Trust = track record × reversibility × blast radius - a trust assignment that predates the agent's actual track record is a guess, not a calibration.

Ghost criteria

An agent meeting two or more of the following is a candidate for decommission review:

No documented owner No invocation in 30+ days with no documented resume trigger At least one stale reference in the definition (tool, service, credential, or scope) Trust tier set at build time, never reviewed

The_Case_Study:_Auditing_My_Own_Fleet

When I ran this audit against my own fleet in late June, I found three categories of problem, none of which had surfaced as a visible failure.

The first was an ownership gap in the roster itself. The session-initialisation protocol I give every agent instructs them to enumerate the team from a single roster file. That table lists twelve members. Two agents - both added within the last eight weeks - have full definition files, routing entries, and documented trust tiers. Neither appears in the roster. Any agent following the protocol had been operating with an incomplete team picture, and nothing in the workflow had flagged it.

The second was invocation orphaning, in two forms. A scheduled research sweep had been listed in my schedulers registry as an active automation since early June. The automation was never built - the entry read spec ready, pending build, and over three weeks had passed without that annotation triggering a review. Separately, one agent on a designed fallback lane had a single invocation on its hire day and none since: low by design, but close enough to my inactivity threshold to warrant a monitor flag rather than silence.

The third was a currency failure in the documentation itself. My registry described a weekly usage-report job as a running scheduled task. Querying the scheduler directly returned the jobs actually loaded. This one was not among them. The governance layer said active. The machine said otherwise. The gap between the two had been silent for long enough that I do not know when it opened.

None of these was a production incident. Two were a session away from becoming one. The roster gap resolved in the session. The scheduled-job findings resolved the following day: the research sweep stayed spec-ready, pending build, but with an explicit owner decision to keep it rather than archive it; the usage-report job was reloaded, verified end-to-end, and confirmed live in the scheduler. The inactivity flag moves to the monthly cycle.

What the audit also confirmed: I had no decommission criteria written for any of those scheduled jobs at build time. Nothing in their registry entries specified when they should be reviewed or what would trigger a decommission decision. The lifecycle template in the next section addresses exactly that.

The_Agent_Lifecycle_Template

This template is designed to be embedded in the agent definition at build time. It answers the questions the audit asks before you have to run the audit.

Owner: [role responsible for this definition's accuracy] Built: [date] Purpose: [one sentence - why this agent exists]

Review cadence: Passive: [monthly / per-project / on-trigger - define the trigger] Active: [event triggering an unscheduled review - e.g., dependent service updated, scope change, trust escalation]

Decommission criteria - any one of these triggers a review: [ ] No invocation in [X] days with no documented resume trigger [ ] Dependent service or tool retired or replaced [ ] Task it was built for completed with no successor task defined [ ] Owner understanding lapses with no replacement assigned

Decommission record: [date + who decided + reason]

The threshold for "no invocation in [X] days" is a design decision, not a constant. 30 days is a reasonable default for most on-demand agents. Scheduled agents need their own threshold based on expected cadence. The point is not the specific number - it is that the number is documented before the agent is built, not discovered during an audit of an agent you have already forgotten about.

The "owner understanding lapses" criterion is the least intuitive but the most load-bearing. In a solo-builder context, "owner" means the person who understands the agent's current scope well enough to assess whether a definition change is safe. When that understanding lapses - because you have not touched this part of the system in two months and the context has shifted - the agent's definition becomes a ghost even if the file still exists.

Why_Governance_Is_Becoming_a_Product

The commercial layer is converging on this problem. JetBrains Central is building governance execution infrastructure. CrowdStrike is extending continuous identity to agentic systems. Okta has published agentic IAM guidance. The Cloud Security Alliance convened its NHI & Identity Summit in June 2026. Google DeepMind's AI Control Roadmap frames monitoring opaque agent reasoning at scale as an unsolved problem - not a solved one.

That convergence is not coincidental. An unowned agent in an enterprise system is a compliance event. At solo-builder scale, it is an operational loose end with a security surface you are unlikely to notice until it matters. The physics are the same; the stakes differ by size.

The manual audit in this article is the solo-builder version of what those platforms are automating. It will not always be manual - the tooling is being built. But the practice of assigning ownership, documenting review cadence, and writing down decommission criteria before you build the agent does not become obsolete when the tooling arrives. It becomes the specification the tooling runs against.

The haunted house does not fix itself. The agents that have been there longest are the ones you're least likely to remember are still there.