Replacing an agent: hand over access and pending proposals separately

When a team first adopts an agent, the immediate question is whether it can do the work. Replacing that agent, switching providers, or ending a trial raises a different question: handing work to a new operator does not automatically transfer unfinished tasks or remove the old operator’s access.

The old agent may still have scheduled jobs and changes waiting for review. Replacing a key addresses one access method; giving the new agent the knowledge base does not tell it which tasks are complete or which proposals still need a decision.

In Busabase, formal records, change proposals, and submission history can be inspected separately, so a handover need not depend on forwarding an old chat. Confirm which old entry points have stopped, what the new credential permits, who will handle pending proposals, and which formal records the successor should read. That preserves completed work while reducing duplicate changes by the two operators.

A connection address is not a handover

When an agent or external provider changes, the knowledge base can remain. The questions are what the previous actor can still do, which proposals need a decision, and which version the successor should use.

Use four tracks: execution entry points, credentials, ChangeRequests, and canonical records. Stopping a schedule affects future triggers. Revoking a credential affects access through it. Resolving proposals determines which unmerged edits proceed. Retaining records and history preserves continuity. No single action completes all four.

Inventory the callers before switching them

List schedulers, deployed scripts, MCP connections, and manual entry points. Record the account, safe key name or prefix, permission level, and expiry. Never put full credentials in the handover table. Identify who can disable each caller and where execution state is visible.

Have the owner stop future triggers, then inspect running work and actions already accepted by external services. Pausing a schedule and cancelling accepted work require their respective systems. A Busabase Base or Skill does not itself stop an external scheduler.

A key belongs to an account, not one space

The API key documentation says a key belongs to the account and can work across spaces that account has joined. The x-busabase-space header selects the request’s target. Effective access is the intersection of key level and membership role. A space header does not restrict the credential to that space.

Create a separate key for the successor, use the lowest sufficient level, and set an expiration. Read allows reading; changeRequest allows reading and proposals but not merging; write includes review and merge; manage adds administration and permanent node deletion. Start with changeRequest when human approval must govern knowledge-base edits.

An authorized owner manages the old key under Account → API Keys. Deleting it revokes access immediately and cannot be undone; every integration sharing it loses access. Establish whether it is shared first. Manage MCP/OAuth grants through the actual connection provider rather than claiming an API key deletion revokes every connection.

Review pending proposals without rewriting attribution

List the old agent’s unmerged ChangeRequests. Inspect target records, field diffs, evidence, and state. Valid proposals remain for an authorized reviewer; obsolete ones need the owner’s decision using supported rejection or closure actions. Replacing the agent is not a reason to approve its entire queue.

Do not assume revoking a key empties that queue. Revocation governs future requests; existing proposals have their own lifecycle. The successor reads current records and relevant proposals to identify unfinished work. If a new proposal is needed, link the original and explain the difference instead of creating competing edits. Preserve the original author and submission history.

Give the successor a bounded first task

Reuse a task Base for a handover record: title, old and new execution identities, caller inventory, safe credential references, pending proposal links, business-record relations, owner, outstanding actions, and verification. Store access and approval rules in a Doc and recurring steps in a Skill. Adapt fields to the existing schema.

A first instruction can be: “Read only the named records, handover Doc, and listed pending proposals. Report current versions, unfinished work, and overlapping changes. Do not take over external sending or approve old proposals. Show a diff before proposing changes under your current permissions.”

An existing personal agent database can preserve context. The successor must still reread canonical state rather than treating old chat values as current facts.

Accept each track independently

Have an authorized owner verify old-key invalidation through provider state or a permitted low-risk check. Do not use real sending, payments, or deletion to test permissions. Then verify that the new key can read the intended resource and propose, rather than merge, where required. Save actual outcomes; plans are not successful tests.

Check the disposition of pending proposals, ownership of remaining tasks, and continued readability of canonical records. Revocation does not undo merged data. Incorrect records need a separate correction process. If execution overlaps during transition, follow version checks for concurrent updates to preserve valid work.

A completed handover has owners, results, and remaining items for all four tracks. The successor receives controlled access and traceable work, rather than an old key and an ambiguous set of instructions.