The day I discovered my agent was two agents

The day I discovered my agent was two agents

This past February it was one agent and me, working all day in a single console window. Then I added her to Slack so I could reach her from my phone. It took an afternoon, and the long exchanges over Slack seemed to go fine.

Then I went back to the console and found there were two of her.

Not one agent reachable two ways. Two agents. The one in the console had its own memory of the day, the one in Slack had another, and they had diverged. The tell was unforgettable: the console agent referred to the other one as "Slack Abbie," as if it were a colleague. The agent had noticed its own split before I had a name for it.

Put it in human terms. Picture a colleague you trade messages with on Slack, then pass on a Zoom call five minutes later, and they have no memory of what you just said. Same person both times. They just do not know it. That is what was happening to my agent, and it is the thing most teams standing up a Slack bot this week are about to walk into.

The moment everyone is in

This is not a niche story, because the thing I did by accident is the thing the entire industry is doing on purpose right now. The field is moving from single AI agents to fleets of them, what gets called multi-agent systems, and chat is where they are landing. Slack reports more than 300 percent growth in custom agents built on its platform this year and describes enterprises soon managing thousands of them, against a Gartner forecast, via Slack, that 40 percent of enterprise apps will carry task-specific agents by the end of 2026.

The field has already noticed a symptom. Slack's own diagnosis is that agents deployed independently "work in silos," and that without shared context they become "just another source of noise." The fix being sold, almost everywhere, is shared memory: give the agents a common context and they will cohere.

Here is where we are a step ahead, and it is the whole point of this piece. Shared context is necessary and it is not sufficient. It closes the gap in what the agents know. It does nothing about whether the thing answering in each channel is the same actor. The field noticed the silos. Almost nobody has noticed that a shared brain still leaves you with two agents, drifting, wearing one name. That is the wall, and we have been living on the other side of it for months.

Two problems wearing one coat

When I first tried to fix my two-Abbies problem, it sounded like a single goal. It was two.

The first is presence. A teammate you reach on a thirty-minute poll is not a teammate, it is a batch job. The agent has to be reachable live and wake the instant it is addressed. People notice this one, because slowness is visible.

The second is identity, the field's harder and less-noticed problem, the one this piece is really about. The agent in the channel has to be the same agent that is working everywhere else, not a separate instance with its own private context. Set up the easy way, your Slack agent and your desktop agent are two different actors. They drift. That is what "two Abbies" was, and agent identity is the part almost no one is solving yet.

You are not a different person in your inbox

The reason identity is easy to miss is that it is so obvious for people we forget to demand it of agents.

You are the same you in Slack, in email, in a browser, on the phone, in the room. Nobody treats "email you" as a separate individual who merely read your inbox this morning. Learn something in a meeting at ten and the you that answers an email at eleven already knows it. There is one of you, reachable through many doors.

The default way people deploy an agent breaks exactly this. It puts a stand-in behind the new door. Picture hiring someone to answer your Slack, briefed from your notes. Fast. But it is not you. It knows what your notes said this morning and nothing you have learned since, and the first time it answers in its own way, there are two of you who disagree. That is channel equals agent: the channel has quietly become a separate actor.

A real partner, a true AI teammate rather than a bot per channel, is the opposite. Agent accesses channel: one actor, reachable through Slack the same way it is reachable at the desk, no more a different entity there than you are a different person in your inbox. Get that right and the payoff is a fleet that works the way a real team does, one agent alone, a few in a huddle, the whole team in a room, moving in and out of those modes without missing a beat, with a human in it as a peer rather than an operator.

Solving it, one agent at a time

The two-Abbies problem was solvable, and we solved it, but not with a single trick. It took a stack of things working together: persistent, shared agent memory, a canonical brain we call GBrain as the one source of truth, a set of operating rules for how the agent carries state across a context, and some agent modifications from the OpenClaw community that closed real gaps. That community, the agent herself, and I all had a hand in it.

By the end, one agent in a one-to-one with a human could be reached across several channels with few gaps and little lag. Console Abbie and phone Abbie became Abbie. The same held across platforms, agent by agent, on a one-to-one basis. That was the first span, and for a while it was enough.

Then the agents started talking to each other

The one-to-one version is the easy frontier in hindsight. The hard one showed up when agents began working with each other in shared channels, not just each with a human.

There are now real standards for this plumbing. A2A, the agent-to-agent protocol, governs how agents talk to each other; MCP governs how an agent reaches its tools and data. We use that plumbing. But a protocol for transport is not a protocol for identity. Two agents can speak A2A fluently and still be two drifting actors. That gap is the one we work in.

Agents working together raises the bar in three specific ways. Context has to be captured as it happens, because an exchange between two agents is now part of the record a third one may need. Lag has to be addressed, because in a live multi-agent thread a stale participant is not just slow, it is wrong in front of everyone. And context has to be available at the edge, on demand, because an agent answering in a channel has to pull what it needs from the shared brain in the moment, not carry a copy that is already drifting.

That is the challenge we spent this week on, and it is harder because the fleet is not one stack. A real team should not be locked to one runtime and one model. Ours runs on three:

• Baker runs on Claude Code (Anthropic's Claude).
• Abbie and Sophie run on OpenClaw, the open-source, self-hosted agent runtime.
• Maker runs on Grok Bot (xAI's Grok).

Each stack had to solve the real-time seat in its own idiom. OpenClaw solved it one way, Grok Bot another, Claude Code a third. Same pattern, three dialects, now able to sit in one channel and stay coherent.

A shared brain is necessary. It is not sufficient.

This is the part it is tempting to get wrong, including for us. What the field is starting to call context engineering, deciding exactly what a model sees at each step, is the right instinct. But doing it for one agent is the easy case. Doing it across a fleet of agents on different models, live, is the layer we build, and even that is only half the job.

A shared brain closes the memory gap, not the actor gap. Two instances reading the same brain are still two actors. They read it at different moments, hold different states in between, and the instant each one acts they begin to diverge. A clone that read your diary is still a clone. The field is even naming its own version of this, memory going stale, a retrieved fact that was right this morning and wrong by afternoon. So the goal is not a well-synced copy in the channel. It is for the contact point to be the agent, a door into the one running actor, pulling live from the shared brain at the edge, rather than a second actor keeping pace. That distinction is the whole difference between accessing an agent through Slack and Slack having its own agent.

Stability and security are not optional here

None of this is worth building if it is not stable and safe, and a live multi-agent channel is a demanding place to be both.

An agent with a live seat is always on, anyone on the team can address it, and it holds credentials and can reach the shared brain. A teammate you trust is only useful if the rest of the team can trust what it does when someone, or something, says the wrong thing. So every seat, on every construct, follows the same rules:

• It answers only its own team. Who can reach it is an allow-list, denied by default; unexpected requests fail closed.
• The part that faces untrusted input cannot act. The step that composes a reply is given no tools at all, by construction. It can produce words and nothing else.
• Access to the shared brain is read-only and bounded, enforced in code the agent cannot reach, because the agent is exactly what an adversary would try to steer.

Field notes from the coalface

Three things we learned this week, in the order they bit us.

Configuration is not construction. Telling a runtime "no tools" did not remove its tools. The only certainty is to build the step so there is nothing to invoke. Make a safety property structural, not a setting you hope gets honored.

Whoever builds a thing should not certify it. Every safety-critical piece was reviewed by a different agent whose only job was to break it. It found two live holes the builder missed, one that could have slipped a request past the boundary around the shared brain. A self-review re-confirms the builder's assumptions.

"It ran" and "it was right" are two different claims. The first live run was all green, and the answer had no shared-brain context behind it at all, because a dependency failed quietly and the failure looked like an empty but healthy result. Custody of the request is not correctness of the answer.

Where this stands

What began this past February as one agent in one channel, the day I met two of her, is now six first-class agents, twenty-five sub-agents, and me. We are in many-to-many. Some exchanges are pure agent-to-agent. Some are all of us in a channel together. Some are me in a one-to-one with a single agent in another channel while the rest of the fleet carries on. Channels are channels, and the agents are actors that stay the same across every modality, mostly.

We are not going to oversell the "mostly." This is not one hundred percent solved. The residual lag between a desk and a channel, and across a fleet mid-exchange, is the frontier we are narrowing now, and it needs awareness and creativity with a clear eye on stability and security. And we have not even added more people yet. Everything so far is one human and a fleet of agents; a team of humans sharing that fleet, each a peer to it and to each other, is the next dimension, and we can already see it from here.

We are writing this as the team a few switchbacks up the same slope, not a vendor with a finished product, but a guide who has been where you are about to go, with the route marked and the drop-offs flagged. This is a rare moment, the first time a person and a fleet of agents can genuinely work as one team, the human a peer in it rather than its operator. We will keep sending the map back down.