Operator continuity
Every agent is anchored to accountable human operators. Continuity is the guarantee that an operator’s departure never silently orphans a critical workflow: co-owned agents keep running through a promotion, and solo-owned agents suspend behind a time-boxed admin decision instead of dying quietly.
The anchor model
An agent holds one primary operator (the operator of record) and, where your organization allows it, additional co-owners — each a verified operator with a live credential. There is always exactly one live primary. Co-owners hold full operator authority over the agent’s lifecycle surfaces (JIT windows, role assignment, exception requests) but never inherit another operator’s personal authority: entitlement delegations and operator-level roles still lapse with the person who held them. Continuity covers the anchor and org-level authority only. A verified operator here is anyone holding a live operator credential — peer-approved on the Operators page, self-attested (personal accounts), or ID-verified; every path passes these gates equally.
What happens when an operator departs
- A co-owner departs — their link is removed; the agent keeps running. Nothing else changes.
- The primary departs, co-owners remain — the longest-standing co-owner is promoted to operator of record automatically (audited, agent.operator_promoted webhook). Zero disruption.
- The last operator departs — the agent suspends and an adoption request opens: every org admin is emailed with the deadline. An admin either accepts (they become the operator of record — this requires their own verified operator credential) or denies with a reason (the agent credential is revoked and the agent retires). An unanswered adoption auto-revokes at the deadline — fail closed.
Transfers and co-ownership
Admins and an agent’s current operators can transfer ownership to another verified operator (TARGET_NOT_VERIFIED_OPERATOR otherwise). The recipient sees the agent’s details — purpose, framework, model, environment, enrollment date — and must accept before anything changes; declining or letting the request expire leaves the agent untouched. Accepting a transfer on a suspended orphan reactivates it and resolves the pending adoption, so an admin can route an orphan to the right owner instead of adopting it personally.
Operators can also invite a co-owner — the path to a multi-operator agent. Invitations are capped by the org policy below (MAX_OPERATORS_REACHED at the cap) and, like transfers, require the recipient’s acceptance. Every request, acceptance, decline, cancellation, and expiry writes an audit event.
Org policy
- Decision window (default 72 hours) — how long pending adoptions, transfers, and invitations live. Expired adoptions revoke the agent credential; expired transfers and invitations are quietly cancelled.
- Max operators per agent (default 1) — co-ownership is an explicit opt-in. Raise it to enable multi-operator agents for critical workflows that must not depend on one person.
Not the same as the operator-group gate
The older operator group setting is a separate strictness control: an agent bound to a group is valid only while every active member of that group holds a live entitlement delegation — a unanimity requirement for high-control workflows. It does not anchor accountability and is unchanged by continuity. Co-operator links are the anchoring mechanism; the group gate is an optional extra condition on top.
Related: Agent RBAC (org-level roles survive departures; operator-level roles do not), Security model.