After Each Department Got Its Own Agent, They Talked to Each Other Even Less

Companies spent years breaking down silos—hiring consultants, doing agile, rolling out OKRs. Then AI arrived, and the number of silos doubled, one per department.

Engineering has one agent, product has one, marketing has one, sales has one, QA has one, and over in finance someone is running a local model on a machine whose fan sounds like a commercial leaf blower. Everyone writes their own prompts, accumulates their own context, and gets different results. Cross-department communication between humans was never solved; instead, everyone first taught their own agent to ignore the others.

OpenClaw's demo at the GitHub Universe booth was simple. Two laptops connected to the same agent, with a large screen beside them rendering their location, Fort Mason, in real-time 3D. Audience members picked a landmark outside San Francisco; most picked the Statue of Liberty.

The first laptop typed Add the Statue of Liberty. Before Enter was pressed, the sentence was already appearing word by word on the second laptop. When it was submitted, a low-poly Statue of Liberty with slightly sagging edges landed next to Fort Mason.

Switching to the second laptop, they typed Make that three times bigger. The first laptop saw it in sync. Submit, and the statue became three times bigger.

At no point did anyone explain what that referred to, copy the previous exchange, or ask the agent to reconstruct a colleague's train of thought.

The blog says they counted 11 spontaneous cries of oh my god at the booth. They counted themselves.

The mechanism isn't complicated: shared workspace, shared agent, shared context, and requests go through the same queue, so you can see when the agent is busy and don't blindly stuff in conflicting instructions. Inside the foundation, more than 50 people already collaborate in the same environment. MIT licensed, model-agnostic, self-hostable, bring your own model—OpenAI, Qwen, Claude, local, anything. 83,000 forks. Free.

The official blog has a bit about everyday product-engineering life: PM describes a requirement, engineering implements it, PM says that's not what I meant, engineering explains why it was implemented that way, PM adds something, engineering points out that the new requirement conflicts with what was agreed last Tuesday. Once each side has its own agent, this conversation has to run twice, once on each side, with a manual summary passing in between. As it gets passed along, important information disappears.

The demo went smoothly; the questions in the comments were closer to everyday reality.

One user said they open one agent per task, and half their time goes to copying answers from one window to another.

Some worried about two people editing the same plan at the same time and still wanted a sandbox before touching production.

Someone asked how conflicting edits are handled. In a project they maintain, two contributors fixed the same rule bug in parallel, each with a different local state, and merging was the real work.

Others were uneasy about shared context itself: what happens when one agent's memory leaks into another team's rules, or when marketing's prompt breaks engineering's agent? Some said outright that shared context is good in most cases but not right for them.

These concerns all point to the same gap: a shared queue handles concurrency; permission boundaries handle whether something should happen at all.

Being able to see the other person typing and to queue a submission is not the same as being able to decide who has permission to change which part. Whether marketing's prompt can contaminate engineering's context depends on whether the workspace can be split into permissioned rule sets, rather than just being a room anyone can enter. The blog doesn't address this.

One more premise gets skipped: shared context requires everyone to trust the same agent's output. When trust doesn't hold, shared context makes errors spread faster. The old silos could at least keep mistakes inside a department.

The industry has spent a lot of ink calculating how much work one person can do with an agent: code output, speed of drafting requirements, hours saved. Those numbers all look good. The cost of a group of people each being efficient and then spending half a day syncing context is rarely calculated.

OpenClaw has put this problem on the table. Whether silos can really be dismantled depends on how conflicts and permissions are implemented. The Statue of Liberty in the demo can get three times bigger; rules in production cannot.

Original article: Shattering Silos with OpenClaw Multiplayer

Multiplayer docs: docs.openclaw.ai/start/multiplayer

Original tweet: OpenClaw on X