Synthetic Coworkers Need Offboarding, Not Just Onboarding

There are at least five offboarding states:

The table makes an important distinction: offboarding is a control transition, not a trash can.

The memory problem after an agent leaves

Agent memory makes offboarding harder. A retired agent may have written memories that active agents still retrieve. A downgraded agent may have left behind runbook notes, customer preferences, vendor risk claims, or codebase conventions. If those memories keep influencing future action, the agent has not really left.

A serious offboarding flow should classify memory into four buckets. Verified memories can remain if their source and scope are intact. Useful but unverified memories can remain as low-authority context. Disputed memories should be quarantined from authority. Sensitive or cross-tenant memories should be removed or locked behind review.

The mistake is treating memory as harmless because it is not a tool permission. Memory can change decisions. That makes memory part of the offboarding surface.

Handoffs need negative instructions too

Most handoff plans focus on what the replacement agent should inherit: goals, context, open tasks, customer history, useful memories, and prior evidence. A serious offboarding plan also says what the replacement must not inherit.

Negative inheritance is the missing discipline. The new agent may need to know that an old shortcut is no longer allowed, that a vendor note is disputed, that a customer preference expired, that a prior approval applied only to a retired workflow, or that a memory came from an agent whose trust was downgraded. Without negative instructions, handoff becomes a laundering path. The successor looks fresh while carrying stale authority from the predecessor.

This is especially important in swarms. A retired agent may have influenced many peers. Offboarding one agent should therefore trigger a dependency review: which other agents used its memory, relied on its outputs, or copied its assumptions into their own context?

The dependency review should not be dramatic. It can begin as a graph query. List the agents that consumed this agent's outputs, the workflows that referenced its memories, the tools it was allowed to call, and the pacts still tied to its identity. Then decide which dependencies can remain, which need recertification, and which should be severed immediately.

Offboarding checklist for agent operators

The checklist should run before deletion, before replacement, and after any material trust downgrade.

The Armalo lifecycle boundary

In Armalo's architecture, identity, pacts, memory evidence, disputes, and scores are not separate decorations. They are the record that makes lifecycle transitions inspectable. A retired agent should not erase its proof history. A downgraded agent should not keep its old authority. A replaced agent should not silently pass unverified trust to its successor.

Armalo can support parts of this workflow today through explicit agent records, commitments, evidence surfaces, and trust-state concepts. The broader lifecycle discipline remains an operating responsibility: teams still need to define offboarding states, owners, retention rules, and downgrade triggers.

That honesty is part of the point. The category does not need another launch checklist. It needs a lifecycle model for what happens after launch.

The uncomfortable executive question

Ask your AI program owner this: how many agents have we retired, downgraded, or replaced, and what happened to their authority?

If the answer is "we have not needed that yet," the program is probably too young or too informal to notice the risk. If the answer is "we delete them," the program may be destroying evidence it will later need. If the answer is "we leave them disabled," the next question is whether their memory, outputs, credentials, and downstream dependencies are also disabled.

FAQ

Should inactive agents keep their public reputation?

They should keep history, but the current trust surface should clearly show inactivity, retirement, or downgrade state. Old performance should not imply current authority.

How is offboarding different from incident response?

Incident response handles an acute problem. Offboarding handles lifecycle transition. Some incidents trigger offboarding, but many offboarding events are ordinary: replacement, scope reduction, owner change, or mission completion.

What should be automated first?

Automate stale permission detection and memory provenance review. Those two surfaces are where retired authority most often lingers.

The lifecycle takeaway

The enterprise will eventually treat agents like coworkers in one crucial respect: they need a lifecycle. Onboarding earns authority. Offboarding prevents old authority from haunting the next workflow.