How to retire an AI agent without losing its email accounts

Retiring an AI agent means stopping its work and ending its access while keeping a responsible owner for the accounts and correspondence it leaves behind. Do not start by deleting its mailbox. First identify the dependent accounts, assign their next owner, stop execution, revoke the appropriate credentials and verify the result. Decide what mail to retain or remove only after that handoff.

This is a recommended operating procedure, not an automatic offboarding feature in Mermail. We reviewed the sources on October 13, 2026. We did not revoke a live credential, transfer an external account or delete a mailbox to test this guide.

Start with the accounts the agent leaves behind

An agent may stop running today while receipts, support replies and account-recovery messages continue arriving next month. The inbox address can also remain the login or recovery address for another service. Creating a new inbox does not update those external accounts.

Make an inventory outside the agent's conversation history. For each service, record the account identifier, receiving mailbox, responsible human, active subscriptions, outstanding work and the provider's approved ownership-change process. Store credential references in this record, not credential values. Keep passwords, tokens and recovery links in the appropriate secret-management system.

An agent being replaced is different from a compromised agent. For suspected compromise, follow your incident-response process and contain access promptly; do not wait for a routine content or mailbox cleanup.

Review the signup and verification workflow

Separate four actions that often get confused

Stopping the runner prevents that execution process from starting more work. Check scheduled jobs, webhook consumers, background workers and queued retries as well as the visible chat. Closing a conversation is not evidence that all those processes stopped.

Removing a connector from a host changes that host's configuration. It does not establish that every token, alternate client or copied credential has been revoked. Check the provider's connection state and any other authorized execution environments.

Revoking a credential ends the access represented by that credential, subject to the provider's rules and propagation behavior. A shared credential may affect other agents too. Identify its users before changing it, and arrange replacement access for legitimate workloads where necessary.

Deleting a mailbox changes the resource that receives or stores correspondence. It is not a substitute for revoking an external application's sessions, ending a subscription or transferring ownership of a third-party account. Treat deletion as a separate, explicitly approved decision.

What the Mermail documentation establishes

Mermail's interactive MCP flow uses OAuth and asks the signed-in user to select a workspace. Its documentation describes one-hour access tokens and renewable access for eligible clients. That is why waiting for a short-lived access token to expire is not a reliable offboarding plan when refresh access remains valid.

The same documentation says expired or revoked connections require sign-in again. It does not make removing a local configuration file equivalent to provider-side revocation. Use the available account or workspace controls for the actual connection, and involve the workspace owner or support if you cannot identify a documented revocation path. Do not guess an endpoint or claim access has ended without checking.

The agent-inbox profile narrows the available tools, but it is not a revoked connection and it is not entirely read-only: mailbox creation remains available. A retiring agent should not be kept connected merely because its profile omits sending. Separately review other connectors, browser sessions and any payment authority that the runner possessed.

Mermail MCP authentication and connection documentation

Mermail agent-inbox workflow

Make the handoff explicit

Choose a named human or team responsible for future mail before resuming anything under a replacement agent. Confirm that the receiving address still belongs to the intended workspace and that the new operator has appropriate access. Do not copy the retired runner's entire credential store into its replacement.

For each external account, use that provider's supported process to change contacts, recovery addresses or ownership if needed. Some accounts cannot be transferred, and a mailbox alone does not prove authority to make the change. Leave unresolved cases with the owner rather than improvising a recovery flow.

Record subscriptions separately. Stopping an agent or its mailbox does not establish that billing stopped. Have the authorized owner check each service's subscription state and retain the relevant receipts or support references.

Use a human handoff for account recovery

Verify access has ended without exposing secrets

Decide on the acceptance checks before making changes. In a controlled test environment, a harmless, separately authorized read using the retired connection should fail for the intended access reason. An unrelated network error or rate limit is inconclusive. Also verify that the replacement owner's permitted access still works.

Check the provider's documented timing before declaring failure or success. For example, Google documents that token revocation can take time to have full effect. That is a Google-specific observation, not a promise about Mermail's timing. Do not reauthorize the retired client just to make a check pass.

Keep the connection identifier, change time, operator, observed result and unresolved dependencies in an access-controlled record. Never log the credential used for a check. If your environment cannot safely perform the check, record access termination as unverified and assign an owner to resolve it.

Google OAuth token-revocation reference

A small handoff record you can reuse

Synthetic example: “Research agent R-17 is retired. Its scheduled runner is stopped. The owner has identified three dependent service accounts and retained their mailbox for ongoing correspondence. Credential revocation is requested; denial of the old connection is not yet verified. No mailbox deletion is authorized. The operations owner will resolve the remaining access check.”

This is an example of honest status reporting, not a completed test or a product screenshot. Replace each statement with observed evidence. In particular, keep requested, completed and verified as separate states.

A reusable record needs the agent and workspace identifiers, dependent account list, owner, runner state, credential-change state, access-check result, outstanding billing or support work, and a date for the next review. It does not need copied message bodies or authentication secrets.

Decide mailbox retention last

Once access and ownership are settled, choose a retention or removal process appropriate to the correspondence and your organization's requirements. Confirm the actual product behavior before relying on an archive, export, deletion or address-reuse assumption. This guide does not promise any particular retention period or recovery capability.

A dedicated inbox helps keep the agent's service-account correspondence separate from personal mail. It still needs an owner after the agent is gone. Practise the handoff with synthetic records before relying on it for production accounts; the end-to-end offboarding procedure described here remains untested against a live provider.

Use the email-workflow testing guide

Create a Mermail account and assign an owner to the agent's inbox from the start.