When Your AI Champion Leaves: Keep the Agent Running

When the person who owns an AI agent leaves, continuity depends on three things: written documentation of what the agent does and why, access that belongs to the company instead of the individual, and a named successor who has run the agent alongside the owner before the exit. Do these during the notice period and the agent keeps working with no gap in accountability. This article shows what to write down, what to transfer and how to check that the handover held.

Key takeaways

• An agent that depends on one person's memory and personal logins has a single point of failure, and a resignation exposes it.
• Document the agent's purpose, boundaries, knowledge sources, tools, approvals and known weak spots in plain language a new colleague can follow.
• Move every credential, integration and alert route from the individual to company-held or role-based identities, and test each one before the last day.
• Name an accountable owner and a backup, and let the successor run the agent with the outgoing owner watching.
• Review the agent after the exit: failed calls, unanswered alerts and any permission still tied to the former owner.

Why does one person's exit put an AI agent at risk?

Most business agents begin with a champion: someone who argued for the project, shaped the role, chose the documents the agent reads and answers questions from colleagues. Over time that person becomes the only one who knows why the agent behaves as it does. Why it refuses certain requests. Which spreadsheet is the real source and which is a stale copy. Who approves an exception when the usual approver is away.

The second risk is access. Integrations are often set up under whoever was available at the time. An API key created under a personal login, a calendar or file connection authorized with a personal account, a shared inbox that only one person administers. Authorization flows such as OAuth 2.0 are typically granted by a specific user, so when that user's account is closed during routine offboarding, the agent can lose reach to the systems it depends on. Sometimes it stops loudly. Sometimes it keeps running with an identity nobody reviews, which is worse.

The third risk is accountability. Alerts, approval requests and staff questions land in one person's inbox. When that person is gone, nobody pauses the agent when it misbehaves and nobody approves the change that would fix it. A clear operating model that names who owns, reviews and runs each agent removes most of this exposure before anyone resigns.

What should the owner write down before leaving?

The goal is a handover record: one document, in plain language, that lets someone who never worked with the owner understand and operate the agent. It should be written for a new hire, not for the person who built it. Include the following.

• Role and purpose: the job the agent does, for whom, and what it must never do.
• Success criterion: the observable measure used to judge whether it works, and where to see it.
• Knowledge and memory: what the agent knows, where the source documents live, who updates them and how often.
• Tools and integrations: each system the agent touches, the permission level it holds and the account it uses.
• Approval boundaries: which actions need a human, who approves them and what happens when that person is absent.
• Channels: where staff reach the agent and where it posts or sends messages.
• Known failure patterns: questions it handles poorly, past incidents and the workarounds in use.
• Change history: recent changes, the reason for each, and anything pending.
• Contacts: the provider or internal technical contact, plus the business stakeholders who rely on the agent.
• Usage limits: the spending or volume caps in place and who receives the alerts.

The list captures the what. The harder part is the why. Ask the outgoing owner to explain, out loud, the five or six decisions that shaped the agent: why a boundary sits where it does, why a source was excluded, why an approval step exists. Record those explanations in the same document. Knowledge about reasons disappears first, and it is the knowledge a successor needs when something unexpected happens.

A simple test of quality: ask someone outside the project to read the record and describe the agent back to you. Where they hesitate, the document has a gap.

How do you transfer access without breaking the agent?

The principle is that access should belong to the company and attach to a role, not to a person. The order matters: replace first, disable second. If you close the personal account before the replacement is tested, you find the dependencies by outage.

Start with an inventory. For every system the agent reaches, record the account or token it uses, who created it, what it can do and where its secret is stored. Mark each as personal or company-held. Anything personal needs a replacement, usually a service account or a role-based identity with the same scope and no more. The OWASP authorization guidance recommends least privilege and deny by default, and a handover is a good moment to apply both: do not copy the owner's broad rights to the successor, grant what the role needs.

Then handle secrets. Any key, token or password the departing owner could read should be rotated after the new connections are working. Do not hand a former login to the successor. Shared personal credentials destroy the audit trail you will want later.

Finally, move the routes. Alerts, approval requests, error notifications and billing notices should go to role mailboxes or team channels, with at least two people attached. Test each integration after the swap while the outgoing owner is still available to help diagnose surprises. A formal permission review gives you a repeatable way to do this, and it is worth repeating after the exit.

The owner may also have been a daily user of the agent, with saved settings, shared files or personal automations. The plan in offboarding employees who used a company AI agent covers that side of the departure.

What is a practical step-by-step handover plan?

Use this sequence from the day notice is given. Compress it if the notice period is short, but keep the order.

• Step one: freeze non-essential changes to the agent, and name the successor and a backup.
• Step two: build the access inventory, listing every integration, credential and alert route, and mark which are tied to the departing person.
• Step three: complete the handover record using the checklist above, including the recorded explanations of key decisions.
• Step four: move credentials, connections and alert routes to company-held identities, and test each one with the outgoing owner present.
• Step five: run a shadow period in which the outgoing owner leads routine tasks, such as reviewing logs, approving actions and answering staff, while the successor watches and asks questions.
• Step six: reverse the roles. The successor leads while the outgoing owner observes, and the pair handle one real change request and one practice incident, such as a wrong answer reported by a user.
• Step seven: confirm that a backup of the agent's configuration and knowledge exists and that a restore has been tested. The guidance on backup and restore explains what to save.
• Step eight: on the last day, disable the personal accounts, confirm the agent still runs and announce the new owner to staff and stakeholders.
• Step nine: review after the exit, looking for failed calls, unanswered alerts and any permission still tied to the former owner.

Step five and step six are the ones teams skip, and they matter most. Reading a document is not the same as operating the agent. The successor needs to see a log, make an approval and handle a complaint at least once with someone nearby who can say what normal looks like. Logging and tracing help here: if the agent records what it did and why, the successor can follow its behavior without relying on anyone's recollection. The OpenTelemetry observability primer is a useful introduction to what those records should contain.

What does this look like in practice? An illustrative scenario

Illustrative scenario: a mid-sized distribution company runs an agent that answers supplier questions and drafts purchase order summaries. Its owner, an operations manager, gives notice. The agent reads a shared spreadsheet through a connection the manager authorized personally, and it sends approval requests to the manager's inbox.

Without a handover, the manager's account is closed the day after departure. The agent can no longer read the spreadsheet, and approval requests go to a mailbox nobody checks. Drafts pile up unnoticed until a supplier asks why nothing has arrived.

With the plan above, the inventory in step two finds both dependencies. In step four the spreadsheet connection moves to a service account and the approval route moves to a shared role mailbox watched by two people. During the shadow period a procurement lead, the successor, handles a week of approvals and learns from the record why the agent never emails suppliers directly: finance requires a human to review anything that leaves the company. After the last day, the agent keeps running, and the first post-exit review finds one forgotten calendar connection that is fixed within the hour.

Who should own the agent next?

The successor does not have to be the most technical person. They need authority over the process the agent supports, time set aside for the role, and the ability to approve changes, pause the agent and escalate. Use this decision guide.

• If the agent serves one department, choose a leader from that department who owns the process, and pair them with a technical contact.
• If the agent crosses departments, name one business owner for results and a separate reviewer for permissions and risk.
• If no internal person has capacity, name an accountable executive and delegate day-to-day operation to a provider under written responsibilities.
• If the likely successor is uncomfortable with technical detail, write the owner tasks as short routines (review the log, approve or reject, pause if unsure) and keep a technical contact on call.
• In every case, name a backup, so the next departure is a handover and not a crisis.

It also helps to write down what the owner can decide alone and what needs a second signature. The article on which settings business owners should control is a good reference for that boundary.

How does Be Human handle changes of internal owner?

Be Human defines the agent's role, memory, tools, permissions and approval boundaries in writing at the start of an engagement, so the record exists from day one and does not have to be reconstructed at an exit. Integrations are set up against accounts the company controls, and managed operations include monitoring, permission review and integration maintenance. When an internal owner changes, the provider can walk the successor through the current state, confirm that access and alert routes point to the right people, and check the agent again after the transition. Decisions about scope, approvals and permissions remain with the company.

Frequently asked questions

How early should we start the handover? As soon as notice is given, and ideally long before, by keeping the handover record current as the agent changes. If the notice period is short, prioritize the access inventory, the alert routes and the successor's authority to approve and pause. Those three protect continuity even if the rest of the document is incomplete.

What if the owner has already left? Begin with a read-only audit: find out which account each integration uses, read the logs, and gather any configuration the provider or IT team holds. Restrict risky actions until you know who can approve them, then rebuild the record from what you find. If the relationship allows, ask the former owner for a short conversation about the reasons behind key decisions.

Does the successor need to be technical? No. They need authority over the process, time for the role and a clear routine for reviewing, approving, pausing and escalating. Technical support can come from IT, a trusted colleague or a provider, as long as someone is named and reachable.

Should we pause the agent during the transition? Usually not. A better approach is to freeze changes and reduce its scope if needed, so people keep their service while the handover happens. Pause it only if nobody can currently receive alerts or approve the actions that need a human.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.