Here is a launch I know well: a campaign that opens with an event. When marketing runs one, the campaign owner decides what the event should be. The page lives on the website, which has a different owner. It has to follow design guidelines someone else maintains. And whether the campaign worked is decided by whoever measures registrations against what it cost. Now imagine each of them working through an agent. A week out, the design agent signs off on the event page against a standard the website team’s agent has never seen. The campaign owner calls it “our best event yet,” while the person measuring return has a different definition of best. Every agent has done the job its owner gave it. No one on the team has made a mistake. The system has a design gap.
That gap opens before anything changes hands. Nobody has agreed on what the event is for, or on what each agent is allowed to know. It becomes impossible to ignore when the page moves from one person or agent to another, and the recipient gets the output without the judgment behind it.
Multiplayer AI will take more forms than we can picture today. Agents will work in chats, in the background, across applications, inside companies, and between organizations whose interests do not align. The interfaces and protocols will change. The handoff will stay. Someone finishes part of the work and someone else picks it up, and both need to know the terms it moves on.
At a gathering I helped host in San Francisco, five builders showed different ways into multiplayer AI. Some made it easier for people and their assistants to work in the same space. Others focused on agents working as a team, or on finding where that team failed. Each solved a real piece of the problem. None could tell us, on its own, what happens when the work reaches someone with a different goal or a different right to act. Go back to the campaign event, and that question first shows up in a single word of the brief.
Who decides what “best” means
Tell the campaign agent to make this “our best event yet,” and it has to fill in that word. Does best mean more sign-ups, or the right people signing up? The agent can produce an excellent page under one definition and fail the other. The website team’s agent can check the page for speed and accessibility without knowing that the headline promises a speaker who hasn’t confirmed.
Same brief, different definitions of best | Source: Context and Chaos
The fix starts with the team’s decisions reaching the people and agents doing the work. Which definition of a qualified registration counts for this campaign? Who can approve a claim on the page? Some answers belong to the whole team. Others are limited to a role or a project. Shared context needs that scope, so each decision reaches the agents it applies to without exposing everything their owners know.
Some of those decisions become instructions the team uses again. Say the campaign owner turns the event-page process into a reusable skill: check every number with the person measuring return, and ask the website team before promising anything new. The next teammate can use it without rebuilding the process from memory. But if the definition of a qualified registration changes, who updates the skill? When another team needs a different version, who decides what can vary?
The knowledge that guides work can be shared; the decision to change it still has an owner. A team must settle what its agents are entitled to treat as true before those agents can usefully pass work between them.
What arrives with the page
Say the team has settled what best means. The campaign agent sends the page to the agent that runs the website. What actually arrives?
The page, and usually not much else. The receiving agent also needs the intended audience, the metric the campaign is optimizing, the approved claims, the publishing constraints, and the questions that still need a person’s answer. A plain “approved” stamp collapses judgments made by different people into a single word. Design approving the layout does not mean the website team approved the date.
The output needs the judgment behind it | Source: Context and Chaos
My bet is that judgment becomes part of the handoff. The next person or agent should be able to see what was checked, against which standard, by whom, and how far that approval extends. Agents need not copy the way people coordinate. A website agent can quietly flag an exception where a person would call a meeting. Whoever picks up the work still needs to know what they can rely on.
A handoff also needs a route back. If the website agent catches an unconfirmed speaker in the headline, fixing the page solves today’s problem. Tracing the claim back to the brief or shared skill that supplied it gives the team a chance to fix the next page too. Otherwise, an error gets corrected at the edge while its source stays ready for reuse.
On GitHub, a change travels with its pull request, so the reviewer sees the diff and who approved it. Agent protocols can move tasks and messages between agents. They do not, by themselves, tell a new team which business decisions to trust or whose judgment counts. I would start with the question a receiving teammate already asks: what was done, and what am I allowed to do next? Whatever shape the handoff takes, it has to answer that.
The rules change with the room
Everything so far assumes the people behind the agents want the same result. A campaign team has a company around it. Roles, owners, and a shared objective already exist, even if its agents can’t see them yet. Change the players and some of those assumptions disappear.
Picture two research groups working under an agreement. They want to exchange findings without sharing private methods. The agreement can say what is allowed, and an agent can read the PDF. That still leaves both groups to decide how those limits become permissions their agents follow and each side can check, including what can enter the shared project and when access ends. Outside work, friends planning a birthday face a version of the same boundary: an assistant may know something about the guest of honor that its owner has no right to share.
Now take two law firms on opposite sides of an acquisition. Imagine their agents exchanging drafts and proposed terms. Each firm has duties to its own client; neither can treat collaboration as an instruction to reveal everything it knows. The receiving side needs to tell a proposed term from one the other side is authorized to accept. Both need a way to check a commitment without trusting the other agent’s private account of it.
Both cases are hypothetical, and they are useful because they change the relationship between the people behind the agents. Teammates can disagree and still want the same result. Partners cooperate on one narrow project and guard everything else, and opponents can reach a deal while each protects a different interest. Their permissions and standards for accepting work will differ. The game theory question comes from those incentives: what does each side gain by cooperating, and what does it gain by bending a rule? Sometimes an incentive is hidden. If your agent costs you nothing and the seller pays for every transaction it completes, whose interest is it serving?
Some groups exist for one job. Two companies staff a joint project, or specialists come together for a deal and disband when it closes. Their messages and files can remain after the project ends. The harder question is what either side is entitled to carry into the next one. Does a record of a missed commitment survive? Who can see it, and who can contest it? When trust is thin, the history of the work can matter as much as the final deliverable.
Same handoff, different trust | Source: Context and Chaos
That is another handoff, from a temporary group to whoever may rely on its work later, and what can cross it depends on the agreement the group made. Where the sides do not fully trust each other, I would go further. The system keeping the record should not automatically decide the consequences of a broken commitment. Some collaborations will need a referee both sides accept, one that checks actions against the agreed scope and leaves a decision either side can challenge.
Build what sits between the agents
Referees, shared records, and scoped permissions all live between agents, and that is the part we have barely built. Today, we can give each person a capable setup: a model, tools, access to data, and memory of their own work. Give four teammates four such setups and you have four useful assistants, with no way yet to work together.
Alignment does not scale pair by pair | Source: Context and Chaos
If every agent has to manage a separate relationship with every other, the work of keeping them aligned grows fast. Four agents have six possible pairs; ten have forty-five. Collaboration built as a pile of private, pairwise arrangements gets harder to manage with every person who joins.
One piece of that space started filling in this month. In the first week of October, two open protocols for personal agents arrived within a day of each other: the Personal Agent Protocol and PACT. Agents could already tell each other who they are. These two add a way to show who sent them and what that person allowed, and both let the business on the other side set its own limits. Both are early drafts, but they are the first serious attempt at that part of the handoff for personal agents.
Those protocols were built for a system of trust, where a person picks a business and sends their agent to deal with it. The harder rooms remain unsolved. Inside a company, the outcome is shared but much of the information is privileged. Across companies, some of the agents in the room work for the other side. The trust that holds a group chat of friends together doesn’t carry into either. Inside one company, platforms are starting to scope what each agent can see. Across companies, where interests and permissions differ, nothing yet settles how they share context both sides can rely on.
In those rooms, the line between memory and context starts to matter. My agent’s memory can hold what it knows about my work. Shared context holds what this group has decided, for as long as the right people and agents need it.
Memory stays with each agent. Context is what the team shares | Source: Context and Chaos
In some group tools, each person already decides what their agent contributes and can keep private or personal details out. That works for planning a weekend. It gets much harder on a campaign team, where the result is shared and the information is not. The definition of a qualified registration should stay available to the agents that need it, even after the person who wrote it leaves the project. A private note about a registrant should not become everyone’s memory just because an agent encountered it.
So what does a team govern: the memory or the context? My bet is the context. Today, an agent’s memory usually belongs to its owner and shifts with every conversation, so a team shouldn’t depend on it to carry its rules. Shared context can be governed, and how much of it reaches an agent should depend on who is running the work and what that agent already knows.
Context also has to arrive in time. A background check can take hours without holding anyone up. If a person is waiting to approve the page and the next agent cannot answer a simple question quickly, that delay becomes part of the cost of working together. The right speed depends on the decision waiting on the other side.
Most of this drops out of view when we picture multiplayer AI as an agent joining a group chat. That is an easy shape to draw, and it tells us little about a campaign or a negotiation. A chat gives agents somewhere to meet. The teams behind them still have to decide what each agent knows and what it can promise.
Without shared context, the campaign team ends up where it started: four agents moving faster against four different understandings of “best.” That is chaos, faster. The team writes the rules. Shared context gives those rules somewhere to live and a way to reach the agents that depend on them. In a lower-trust setting, it also has to respect what each side has not agreed to share.
So here are my bets. The handoff will outlast today’s interfaces and protocols. The context behind it will need owners and boundaries. And as the players change, the rules for sharing and judging the work will change with them. We get to write those rules, and no single company or protocol will write them alone. That work should start now, because until it does, agents will keep solving individual problems while the organizational ones wait.
The next player should not have to guess what the previous one meant by “done.” Multiplayer AI becomes real when that player can tell which rules they have inherited and who agreed to them. If you have seen a kind of collaboration that breaks this picture, tell me where I’m wrong.
Rishi Gaurav Bhatnagar first sketched these questions in Multiplayer AI on X in September.
The Cats of Context & Chaos
Approved to do what? | Source: Context and Chaos
About Context & Chaos
Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.
Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.
Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.
Got something on your mind? We’d love to hear from you.
Share this article