Lessons learned from building a multiplayer AI agent harness. Part 1: Why.

I've been building my own version of Claude Tag for half a year now, and several teams are using it daily. Here's what I learned.

Anthropic just launched Claude Tag, a new way for teams to work with Claude in Slack.

The first item on the advantages list of the announcement is:

@claude is multiplayer. Within a given Slack channel, there's one Claude that interacts with everyone.

We developed our own version of it half a year ago at Corgi, and have been using and iterating on it daily ever since.

Some of our clients, friends and family have been using it inside their companies as a multiplayer AI teammate for months now, and we iterated according to their feedback and needs.

Since I've been doing it for a while now and learned a few things the hard way, here are my thoughts about the problems, use cases and technology.

Part 1: Why.

At Corgi, we help companies accelerate AI adoption.

"The future is already here. It's just not evenly distributed." — William Gibson

We noticed that even for AI-native startups, the future isn't evenly distributed. Typically, the technical founder(s) and technical staff are AI-pilled to the bone, orchestrating loops and running their work lives entirely from Claude, while other teams like marketing, sales, operations, finance, etc. are often left behind, still using AI like it's somewhere between a better search engine and a ghostwriter.

The incentive to ramp up the entire company is clear, because AI-enabled teams are getting more work done faster.

These companies often try to close the AI adoption gap by having dedicated enablement workshops, which is fine, but is still essentially a one-off effort that, at best, leaves people inspired and better equipped with mental models and tools, but old habits die hard. Ingraining an AI-native culture and workflows into a company's DNA requires an ongoing, intentional hands-on collaboration, from someone who's intimately familiar with the company's craft.

In other words, these companies don't need tutoring, they need apprenticeship.

However, startups are extremely demanding. Focus and time are the scarcest resources. Apprenticeship costs both, and that's why some founders explicitly don't hire junior developers. But right now, almost everyone is a junior when it comes to AI, the same way almost everyone was a junior when it came to the web back in the '90s. You just can't exclusively hire AI experts simply because there aren't enough of them in the world yet, and the technology and its applications are moving fast.

When each person uses their own agent, there's no built-in sharing of knowledge. It takes effort. So what if multiple people talk to the same agent?

Shopify understood that. They created River:

"One constraint: River only works in the open. No direct messages." with conversations public to all employees by default—according to Shopify Engineering's blog post on River

When you let your AI-skilled workers interact with an agent in the open, you get the knowledge transfer for free: other people can watch and learn. But a fundamental aspect of apprenticeship is hands-on participation, so you need people to actively interact too, not just passively watch.

"In my own channel, there are over 100 people who react to threads, add color and context, pick up the torch, help with reviews, remind me how rusty I am, and importantly, learn from watching." — Tobi Lütke (CEO of Shopify) on X

So one agent, multiple people solves knowledge sharing among the people using it together.

But what about agent-to-agent? Single-player agents don't share context with other agents by default. Each one figures out the same things again and again, needlessly spending time and tokens on a problem someone else on the team has already figured out. The right context is just out of reach.

This problem is partly solved by internal context repositories, such as a literal git repo, obsidian, LLM-wiki or a dedicated Notion teamspace, but these require deliberate effort from both the producer and consumer to push and pull from them.

Another possible solution is to let agents communicate with each other directly, but that costs extra latency and tokens, because it takes several agent turns to figure out what's needed, find the right context and hand it out to the requester.

But with multiplayer agents, shared team context is naturally accumulated over time in one place, things like who owns what, who signs off, where the systems of record are and how they are structured internally, and how it all comes together into the big picture of "the way work gets done here".

To put it simply, single-player agents have an intrinsic cost of context sharing, with both other agents and humans. Multiplayer agents get it for free.

So the need for accelerated AI adoption is better met by multiplayer agents. But are there any other needs that require multiplayer agents, not just benefit from them?

Our thesis is that yes, there are, and that coordination is the reason. Organizations require collaboration: they are systems for information passing and decision making between multiple entities (people, software, and now agents).

Looking at concrete examples, consider cross-team hand-offs: a lead from marketing becomes a prospect for sales, becomes an account for CS to nurture, and feeds back into product and R&D, which generate outputs that are handed off from R&D to product, back to sales and marketing, which then need to communicate back to the outside world. The customer lifecycle inside a company is a coordination and synchronization problem.

We can model companies as graphs: humans are nodes, information flows are edges. Single-player agents are leaf nodes that are connected to a single human node. The humans are hubs, connected to many other nodes.

Each new hire adds an edge to everyone they work with, so the edges grow faster than the nodes. Information flow is a graph traversal. It means that the cost of coordination grows as the company grows, because information needs to travel through a longer path.

The pains of managing growing organizational complexity are well known. When information needs to travel across the company's org chart, it can fail in several different ways, each with bad consequences:

• Dropped (a missing edge): repeated questions, duplicated work.
• Slow (a congested or long path): blocked hand-offs, project behind schedule.
• Lossy (a long path, detail falls off at each hop): misunderstandings, wasted iterations.
• Misrouted (no clear owner, or the wrong one): sub-optimal decisions, data leaks, important things falling through the cracks.

Imagine sales and marketing asking the same questions over and over (dropped edge) on #product-questions and blocked on the product team's availability (slow path), which is sometimes itself blocked on R&D. Product then may misunderstand R&D's answers (lossy path), giving the wrong answer to the customer who asked the original question.

Everyone has had similar experiences from their own professional lives. Most people treat them as "cost of doing business". But does it have to be this way? Can we do better?

"At Block, we're questioning the assumption that organizations must be hierarchically organized with humans as the coordination mechanism. Instead, we intend to replace what hierarchy does." — Jack Dorsey (CEO of Block), in "From Hierarchy to Intelligence"

Single-player agents greatly amplify the throughput of the human node they are connected to. They can push information to other nodes, but they can't become a hub that others connect to directly.

If agents could do that, a whole new class of use cases becomes possible: coordination of complex companies at scale. Less hierarchy, higher throughput between nodes, faster delivery of outputs.

So why can't agents become multiplayer? More precisely: they can't do it safely. The reason is that single-player agents have ambient authority, which means they inherit the identity and permissions of the person using them and can do anything that person can.

So the issue is letting other people directly instruct the same agent. The reason you don't hand your Claude to someone else is that it essentially lets them act as you and call any tool with your identity and permissions: a classic confused deputy problem.

Coordinating across teams, and even across the organization boundary, requires agents that are able to serve multiple people in the same surface: a Slack channel, an email thread, or a WhatsApp group. You just can't get there by improving a single-player agent.

So for agents to become multiplayer, we must make them safe to use by multiple people.

We'll deep dive into the how in part 2, and give some concrete examples!