Cryptographically transfer an AI agent identity from one person to another

When you need this

Employee resignations. Internal team changes. M&A integrations. Vendor handovers. Any time an AI work history needs to migrate from one human supervisor to another. Without the transfer, the receipt feed orphans (no one owns it post-departure) or the new person inherits without a signed chain of custody. The cryptographic countersign produces a verifiable handover record both sides can stand behind.

The transfer mechanism

Initiated by the org owner from /agents/[did]/manage → Transfer. Inputs: source human (the departing employee), target human (the inheriting employee), effective date, optional scope (specific projects or full transfer). The source's keypair signs the transfer; the target's keypair countersigns; the agent's record updates atomically; an audit-log receipt is emitted. The whole flow takes ~5 minutes of IT time.

What transfers and what doesn't

Transfers: receipts, memory snapshots, project tags, API keys (rotated), MCP configs (auto-pushed via the install-token flow). Stays with the leaver: their personal human DID (different from the agent DID), their KYC record (if any). Optionally scoped: you can transfer only project-tagged work and archive personal AI conversations separately.

Bad-leaver scenarios

If Sarah leaves on bad terms and refuses to countersign, the org-admin override kicks in: a forced transfer signed by the org's admin keypair instead of Sarah's. The audit log captures that the transfer was admin-forced; the chain of custody is still cryptographic and verifiable. This is the regulatorily-acceptable path for exit-with-prejudice cases.

Multi-recipient transfers

Sometimes one departing role needs to be split across two replacements. The transfer model is 1-to-1 atomically, but the export-then-attach flow lets you split work post-transfer. Transfer everything to Replacement #1, then export specific projects from #1 and re-attach to #2 via the import flow. Both replacements end up with the right slice; the audit chain is preserved.

Compliance angle

For regulated roles (financial advisors, healthcare workers, legal counsel), the transferred AI work might itself be regulated. The cryptographic chain of custody is what the regulator wants to see — "Sarah's AI-assisted client work transferred to Tom on date X with both signatures and a third-party admin verification". GenZAgents produces exactly that audit artifact.

Common questions

Can a transfer be reversed?▾

Yes — a reverse-transfer (target → source) is a new signed transfer that undoes the original. The audit log shows both transfers. Useful when an internal team change reverses 6 months later.

What if the agent is in mid-conversation when transferred?▾

In-flight conversations finish under the source human's human_id (the audit log is correct historically). New conversations after the transfer effective date are attributed to the target human.

How does this work for M&A?▾

For mergers: the acquirer's org admin initiates bulk transfer of the target's agents into the acquirer's org. The transfers are batched but each one is still individually signed. For acquisitions of single teams: same flow, smaller batch.

Does the new owner inherit the old owner's billing?▾

The agent's billing tier moves with it (transfer of liability). If the new owner is in a different org with a different tier, the agent inherits the new org's tier on the transfer date. Billing reconciliation handled via /v1/orgs/[id]/billing endpoint.