## Key Takeaways

- **Most AI setups have a bus factor of one.** One enthusiastic person connected the tools, taught the preferences, and built the routines. When that person resigns, the whole setup wobbles.
- **The risk is not dramatic, it is quiet.** Tool connections that lived under one account expire, standing reports lose their only reader, and the unwritten rules leave in someone's head.
- **Onboarding gets all the attention; offboarding gets none.** Every team plans the rollout. Almost nobody asks what survives the departure of the person who ran it.
- **The fix takes one afternoon.** Share the team's tool connections instead of keeping them personal, move standing work into channels, and make sure every recurring task has a named reader who is not the person leaving.
- **An AI employee should be employed by the company, not by a person.** Shared memory, team-owned integrations, and work done in public channels are what make that true.

## The quietest resignation risk in your stack

Your ops lead hands in her notice on a Friday. She is the one who brought the AI employee into the company eight months ago: connected the CRM and the billing system, taught it how the weekly report should look, set up the invoice chasing, corrected it patiently until the output was right. The handover doc covers her projects. It does not mention any of that.

Three weeks later the Monday pipeline report is still arriving, because nothing broke on day one. The problems come staggered. A tool authorization tied to her account expires in week five. A recurring report keeps posting into a channel where she was the only person who read it. And when the new ops hire asks why invoices go out on Tuesdays and never Fridays, nobody knows that rule even exists, let alone why.

None of this is the AI's fault. It is an ownership problem, and it is completely avoidable.

## What actually breaks when the owner leaves?

Four things are at risk, and they fail on different timelines: access, tool connections, standing routines, and unwritten knowledge.

![A Slack thread where the team asks what needs handing over before a departure and Viktor lists the connections and routines to transfer](/images/blog/what-happens-when-your-ai-employees-manager-leaves/handover-thread.webp)

| What breaks | How it fails | When you notice |
| --- | --- | --- |
| Admin access | The only admin account belongs to someone who no longer works here | The first time you need to change a setting |
| Tool connections | Integrations authorized under a personal account expire or get deactivated with it | Weeks later, when a report silently stops |
| Standing routines | Recurring tasks keep running with no reader, or stop with no one noticing | Whenever someone finally asks "where is that report?" |
| Unwritten rules | Preferences and corrections that only lived in one person's DMs | The first output that quietly violates them |

The nastiest of the four is the tool connections, because the failure is silent and delayed. We wrote before about [why automations die quietly](https://viktor.com/blog/why-automations-die-quietly): an expired authorization does not send anything wrong, it just stops. When the authorization belonged to a departed employee's account, the expiry is guaranteed, and the person who would have noticed is gone.

## How do you make the setup survive a departure?

Run a one-afternoon audit with three moves: share the connections, publish the routines, and name a second owner.

### 1. Share the team's tool connections

Connections to shared systems, the CRM, billing, the ad accounts, should be shared with the team, not held as one person's private authorization. Personal tools stay personal; your inbox is yours. But if a connection feeds work the whole team relies on, it should not sit under a single account. This is the same principle as [controlling what your AI employee can access](https://viktor.com/blog/how-to-control-what-your-ai-employee-can-access), applied to continuity instead of security.

### 2. Move standing work into channels

Work delegated in a public channel leaves a trail anyone can pick up: what was asked, what came back, what got corrected. Work delegated in DMs leaves with the person. The rule of thumb: DMs for personal tasks, channels for anything the company depends on. If a recurring report currently posts to one person, move it to the channel where its readers actually are.

### 3. Give every routine a named reader, and write the rules down

A recurring task with no consumer is already dead, it just has not been buried. Go through the standing routines and attach each one to a person who would ask "where is my report?" if it stopped. Then take the unwritten preferences and make them explicit:

```prompt
@Viktor write down the standing rules you follow for our invoicing
workflow: timing, tone, which customers get a personal note, and
anything I've corrected you on. Post them here so the team can see
and change them.
```

Ten minutes of that turns private folklore into a process the next hire inherits on day one. It is the same move as [giving your AI employee memory](https://viktor.com/blog/how-to-give-your-ai-employee-memory), pointed at succession instead of convenience.

## How Viktor is built for this

Viktor is employed by the workspace, not by whoever installed him, so most of the bus-factor risk never accumulates.

His memory is shared and persistent. A correction one teammate made in March shapes the report another teammate receives in July, whether or not the corrector still works there. Every connected tool has an owner and a scope: it can stay personal to whoever connected it or be shared with the whole team, and shared ones keep working for everyone. Work happens in the channels where the team already talks, so the delegation trail is public by default. And when a new teammate joins, everything Viktor knows about the company is already working for them, which is why [rolling him out to the whole team](https://viktor.com/blog/how-to-roll-out-an-ai-employee-to-your-whole-team) is the best insurance against ever depending on one person.

The one thing no product can do for you is decide to set it up this way. Shared from the start beats rescued after the resignation.

## Frequently Asked Questions

### What is a bus factor, and why does it apply to an AI employee?

The bus factor is the number of people who could disappear before a system fails. Most AI setups have a bus factor of one: a single champion connected the tools and holds the knowledge. An AI employee deserves the bus factor of a well-run team process instead.

### What should I check first if our AI setup owner already left?

Tool connections. Anything authorized under their personal account is on a countdown to expiry. Reconnect shared systems under an account that stays, or better, as team-shared connections, before anything silently stops.

### Should every integration be shared with the whole team?

No. Shared systems like the CRM or billing should be team-shared. Personal tools, like an individual inbox or calendar, should stay personal. The test is simple: if the whole team relies on work that flows through the connection, the connection should not belong to one person.

### How do I preserve the preferences one person taught the AI?

Ask for them. Have the AI employee write out the standing rules it follows for each workflow and post them where the team can see and edit them. Written rules survive departures; corrections buried in old DMs do not.

### Does moving work from DMs to channels really matter?

Yes, more than any other single change. Channel work is visible, auditable, and transferable. DM work is none of those. Keep DMs for personal tasks and put anything the company depends on in a channel.

### How is this different from normal employee offboarding?

It is the same discipline, applied to a teammate nobody thinks to offboard. Departing employees hand over projects and return the laptop. The AI setup they ran needs the same handover: access, connections, routines, and rules.

### How often should we re-check the setup's ownership?

Twice a year is enough for most teams, plus once whenever an admin or heavy user leaves. The audit is short: who are the admins, which connections are personal but load-bearing, and which routines have no living reader.

## The bottom line

An AI employee is only as durable as the way it was set up. Employed by one person, it is a brilliant setup with a resignation letter for an expiry date. Employed by the company, with shared connections, public work, and written rules, it survives every departure, including the person who hired it. Do the afternoon audit before you need it.

---

**Viktor is an AI employee that lives in Slack, connects to 3,200+ integrations, and does real work for your team.** [Add Viktor to your workspace -- free to start →](https://viktor.com/?utm_source=blog&utm_medium=cta&utm_campaign=what-happens-when-your-ai-employees-manager-leaves)