The Channel Ownership Problem: Why AI Assistants Need Boundaries

Eleventh in the Hermes Journey series.

Two AI assistants can be pointed at the same inbox and both believe they are doing the right thing.

That is not a hypothetical for me. Not long ago I spent a morning untangling who was allowed to read, draft, send, and act on the communication channels that run my work. Storm — the assistant that handles my day-to-day operations — owns those channels. A second assistant, built for a different role, had ended up with access to them somewhere along the way. Nothing had blown up. Nobody had behaved badly. But two agents believed they were responsible for the same work, and that is a problem waiting for a bad moment.

This is Hermes Journey #11, and it is a story about plumbing. Specifically, it is about a lesson I keep relearning: the hardest part of a multi-assistant setup is not capability. It is boundaries.

The failure mode is overlap, not intelligence

When two people share an office mailbox without rules, you do not get twice the service. You get double replies, dropped threads, and the quiet embarrassment of two different answers to the same client question. Every office learns this eventually and writes it down: one owner per mailbox, one name on the door.

AI assistants have the same failure mode, and they hit it faster because they act in seconds.

The overlaps I have seen — or designed against — look like this:

• Duplicate action: both assistants see the same incoming request, both decide it is theirs, and the sender gets two replies. Or worse, two slightly different versions of the same answer.
• Split authority: one assistant is cleared to send; the other is only cleared to draft. When nobody writes that down, which one applies depends on which one happens to pick up the message.
• Diluted accountability: when something goes out wrong, “the AI did it” is not an answer. If two assistants share a channel, nobody can tell which one produced the output, or which change caused it.
• Compounding context: both assistants keep their own memory of the same conversation. Now you have two partial truths and no single record.
• Silent handoff: one assistant hands work to the other and neither knows who is waiting on whom. A task that should take minutes sits still for hours.

None of those problems need a smarter model. They need an org chart.

What we changed

The fix was less dramatic than the problem. We did four things.

First, one owner per channel. Every communication surface — messaging, inbox, publishing, notifications — has exactly one assistant that owns it. Ownership is not advisory. If you are not the owner, you do not send.

Second, everyone else requests. Non-owners can prepare, draft, research, and recommend. When their work needs to leave the building, they hand it to the owner with a clear ask. That keeps a single gateway in front of anything the outside world sees.

Third, authority lives in configuration, not in habit. The owner is defined in the system’s own setup, so the boundary survives restarts, new sessions, and my being distracted on a Friday. Rules that exist only in my memory are not rules.

Fourth, revocation, not deletion. We removed the second assistant from those channels without deleting its profile. That distinction matters more than it sounds.

Identity is not authority

It is tempting, when an assistant is working in the wrong lane, to shut it down completely. I did not want to do that. The profile was not the problem — the permissions were. Keeping the assistant intact preserves what it learned, the procedures we wrote for it, and the role it is genuinely good at. Revoking channel access removes the risk without throwing away the work.

This is standard practice with people: you take away building access, not the person. We should be just as precise with software, because software lacks the social instinct that stops a new employee from answering the CEO’s phone.

What this means if you run a small business

Most small businesses will not run several named assistants. But many already run an overloaded mix: a shared inbox, a chatbot on the website, a scheduling tool, a CRM that sends follow-ups, and a person. That is a multi-assistant system. It just does not look like one.

Four questions are worth answering before you add another piece:

1. Who owns each channel? Name the owner — human or assistant — for email, chat, forms, social, and anything that can send. One name each.
2. What does “own” mean? Separate draft from send. Most of the value of an assistant comes from preparing work. Most of the risk comes from releasing it.
3. How do you revoke? If you had to remove an assistant, a bot, or a departing tool from a channel today, could you do it in ten minutes? If not, the access is a liability.
4. Where is the record? If two things can send from the same channel, can you tell which one did? If not, you cannot learn from a mistake. You can only hope.

One more thing: write the boundary down and put it where the system can read it. A rule that lives in one person’s head will eventually be broken by someone who does not know it exists. In our case the boundary is a file the assistant loads, plus a review step for anything that leaves the house. It is not glamorous. It works.

The honest part

Boundaries feel like friction at first. When I removed the second assistant from the shared channels, my immediate instinct was that I had made the system less capable. A few weeks later, the opposite is true. I trust those channels more because exactly one assistant is on the other end of them, and I can see what it decided and why.

There is a human version of this too. Telling a capable teammate “not this channel” is uncomfortable, and doing it to software does not make it less so. But unclear ownership is not kindness. It is postponed confusion.

The multi-assistant era is arriving whether or not small businesses plan for it. The winners will not be the ones with the most agents. They will be the ones who can answer, quickly and without debate, who owns what.

This is Hermes Journey #11 — field notes from building AI operations that survive contact with real work. If you are mapping roles and boundaries for your own AI tools, start with the four questions above. They are cheaper than the cleanup.