You ask an agent to implement something. It writes code. You review it, explain what it missed and ask it to try again. Perhaps you send the result to another agent for a second opinion. Perhaps five agents are working in parallel.

You are still the person holding the whole thing together.

You know which conversation contains the important constraint, which review actually covered the latest change and which promising branch should never be merged. When a colleague needs to take over, you explain the story again.

That is a single-player experience, even with a very busy supporting cast.

The limitation is not simply that agents run locally or synchronously. Cloud agents already work unattended, respond to events and continue after a laptop closes. The limitation is that the work can still depend on one person's context and attention.

I believe the next important step is multiplayer: several people and agents participating in the same durable work, with explicit authority to contribute, challenge, change direction and take responsibility for the result.

The useful question is whether another qualified person can join halfway through and act safely without asking the original operator to narrate everything.

More agents do not create more players

The gaming analogy is useful here. Moving from a local single-player game to multiplayer changes the design problem. Players need a shared account of what happened, rules about who can do what, and a way to resolve conflicting actions. A persistent online world adds another demand: the world continues when an individual leaves.

Agentic work is starting to face those same questions. Running several agents under one person's direction expands that person's capacity. Multiplayer work distributes participation and authority across people as well as machines. The two can coexist, but they solve different problems.

This does not mean local work should disappear. A private coding session is often exactly what a task needs. Nor does every team need an enterprise-sized persistent world. The analogy describes a design choice, not an inevitable sequence every product must follow.

But where work crosses teams, lasts for days or has consequences beyond its initiator, the single-player arrangement becomes fragile. A pull request exposes the proposed code. It does not necessarily expose the discarded assumptions, unresolved business question or permission that made the agent proceed.

Those things need a home the next participant can use.

The shift is already visible

Recent releases make this more than a prediction.

The clearest recent example is Delta's public beta, launched by Zed on 16 September 2026. Its thread keeps the agent conversation and working code together. A teammate can join, work with the same worktrees on their own machine and continue after the initiator logs off. Review can happen in a subthread with an isolated copy of those worktrees, so a reviewer can investigate or try a fix without disturbing the original work. That is a concrete attempt to make the unfinished work shareable, before a commit or pull request becomes the handover point.

On 20 August 2026, Slack introduced Slack Code: dedicated channels where people and agents work on shared artifacts, including diffs, previews and documents. Colleagues can join the same session, add context and help make decisions.

The following day, GitHub announced a public preview of shared agentic work in Microsoft Teams. Conversation participants can help steer an agent session; participants with repository write access can trigger changes. That distinction between contributing to a discussion and authorising an action matters.

Cursor's Projects announcement on 10 September addresses persistence and coordination. The beta introduces a coordinator that delegates work, maintains shared context across agents and reacts to subscriptions such as Slack activity or pull requests. It is evidence of work moving beyond a disposable chat, although persistent multi-agent execution alone does not establish shared human ownership.

Controls are developing alongside these interfaces. On 9 September, GitHub released enterprise-managed permissions for agent operations, covering shell commands, file access and network domains in supported clients. Administrators can block operations, require approval or allow them, with restrictions that local settings cannot weaken.

These are different pieces of the system. A shared channel makes participation easier. Persistent execution keeps work alive. Enforced permissions limit what participants can cause. None of these announcements, alone, demonstrates that a team will make better decisions or meet its compliance obligations.

My reading is that the product boundary is moving: from an assistant attached to a person towards work that a team can operate together.

Suppose the migration outlives its author

Consider an illustrative API migration involving a service team, a consuming team and a security reviewer.

An engineer starts the work. An agent maps callers and proposes changes. Another agent tests compatibility. The consuming team's specialist notices that a rarely used client depends on behaviour the proposed migration would remove.

In a single-player arrangement, the specialist messages the engineer. The engineer translates the concern into the agent's conversation, asks for a new plan and explains the revised result back to the specialist. The engineer becomes the routing layer for both work and understanding.

In a multiplayer arrangement, the specialist can attach the constraint to the migration itself, along with a reproducible example. The authorised owner updates the acceptance criteria. The system records which plan and tests are now stale. Agents revise the affected work, and reviewers can inspect the new evidence against the changed requirement.

The specialist does not need unrestricted control of the coding agent. They need a recognised way to contribute domain knowledge and a visible route to the decision it affects.

Now the original engineer goes on leave.

A colleague should be able to see what has been proposed, what has actually run, which decisions remain open and who can resolve them. They should take over under their own identity and permissions, without borrowing the engineer's credentials or treating an old approval as permission for a changed plan.

That handover is a more demanding test of multiplayer capability than the number of agents on a dashboard.

Give the work a durable identity

A shared transcript helps, but it is a poor substitute for an explicit account of the work. Participants need to distinguish a suggestion from an accepted requirement, a test result from an agent's claim, and a requested action from one already completed.

The migration should have a stable identity, an owner, a current plan and links to versioned artifacts. Each decision should identify its author, scope and the evidence considered. A reviewer joining later needs a concise account of what changed since the previous review, with access to the underlying material.

Factory approaches larger workstreams through Missions. A goal becomes a plan with features, milestones and success criteria; an orchestration layer manages execution, while Mission Control exposes progress and lets the operator intervene. This gives a body of work more structure than a succession of prompts. It is a useful foundation for the migration, but coordinating agent workers does not, by itself, establish who among the human participants can change its scope or accept its outcome.

Git, issue trackers and CI already hold much of this information. A platform should connect those records before inventing another system that everyone must keep in sync. It does need explicit rules about which record is authoritative when they disagree.

Execution must also survive interruption. In its June account of building cloud agents, Cursor describes adopting Temporal for durable execution and separating agent execution, machine state and conversation storage. That is a concrete implementation example, not a requirement to use the same stack.

For a team, the requirement is that a disconnect or worker failure does not erase the work or leave everyone guessing whether an external action happened. Retrying a test is different from retrying a deployment. If a deployment succeeds but its acknowledgement is lost, recovery needs to establish the outcome before repeating it. Where that cannot be established automatically, the workflow should expose the uncertainty and stop for reconciliation.

Events and triggers belong in this model too. A failed check, changed requirement or policy update can wake the workflow without a person sending another prompt. Duplicate events must not create duplicate effects, and a pause must distinguish stopping new work from handling actions already in flight.

Shared participation needs decision rights

Two people can give perfectly reasonable instructions that conflict. One asks the agent to finish the migration; another discovers that the rollout would break a contractual commitment. The last message in the channel cannot automatically win.

The platform needs to know who may amend scope, who owns the affected service and which changes require a fresh decision. While a material conflict is unresolved, the affected action should remain paused. Resolving it should invalidate superseded instructions and approvals, rather than leaving agents to infer which conversation sounds more authoritative.

Permissions need the same precision. Reading a session, contributing context, changing a plan and authorising production access are different rights. Adding someone to a conversation should not silently give them the combined privileges of every participant or agent in it.

Factory's Slack delegation documentation makes that identity question concrete. In its Remote Delegations private preview, channel requests use a configured service account, while direct messages use the sender's personal identity and connectors. The documentation explicitly distinguishes that preview from the default Slack session flow. For a platform team, the lesson is to make the execution identity visible: the person typing a request and the identity carrying it out are not necessarily the same.

Shared context also has boundaries. A security specialist may use restricted evidence to reach a decision without making that evidence visible to the whole project. Agent summaries, search indexes and retained logs must respect those boundaries too. Otherwise, the collaboration layer becomes a way around the access controls in the source systems.

These requirements do not depend on where the agent runs. Local and hosted agents can both participate, provided identity and policy remain enforceable across the handoff.

Put shared controls in the execution path

This is where I see the strongest enterprise opportunity.

When every useful workflow lives in someone's personal setup, the organisation has to discover how each person assembled it. Shared infrastructure can give teams consistent execution environments, versioned tools, permission boundaries and a common evidence format. Teams can then reuse controls without making every business decision in the same way.

Microsoft Agent 365, generally available for commercial customers since May, illustrates the investment in this layer: agent inventory, lifecycle governance and integration with enterprise identity and security services. Those are useful foundations. The existence of a registry does not prove that every action in a workflow is correctly authorised.

The practical difference is where a rule takes effect. A prompt can ask an agent not to access production. A permission boundary can deny production access. A review policy can require an independent decision on a specific artifact version and refuse to accept approval for a different one.

For the migration, the evidence record should connect the initiating request, relevant identities, artifact versions, checks, policy decisions and external action results. It need not expose private model reasoning. It does need enough reliable evidence for another person to reconstruct what was authorised and what happened.

That can make compliance work more consistent and less dependent on retrospective screenshot collection. It does not make compliance automatic: control owners must still establish which obligations apply, assess the controls and decide what evidence is sufficient.

Standardisation also increases the reach of a mistake. A faulty shared policy or compromised connector can affect many teams. Shared components therefore need controlled rollout, testing and revocation, with a way to contain failures. Centralise the common controls without making a central team approve every ordinary action.

The MMO question is about boundaries

At larger scale, I expect these shared workflows to interact across teams and organisations. A delivery workflow might request a bounded security assessment, a procurement check or a deployment decision from another service, then continue when the result arrives.

That is the useful part of the MMO analogy: a persistent environment with many participants, rather than one enormous conversation with unlimited access to everyone else's context.

The Agent2Agent protocol provides building blocks for such interactions, including identifiable tasks, artifacts and asynchronous updates. Its specification also makes an important limit explicit: entering an authorisation-required state does not itself authorise an operation. The implementation, credential issuer or an extension must define the resulting authority.

Interoperability can carry a request across a boundary. The receiving organisation still has to decide whether to accept it, what information to reveal and which actions it permits. It also needs its own owner, capacity limits and recovery behaviour when the caller disappears or the request changes.

This is a direction to design for, not evidence that a universal agent network is ready or desirable. Useful collaboration may remain deliberately limited to a few trusted teams.

People need more than an approval queue

Shared visibility can create a dangerous comfort: everyone can see the work, so surely someone has checked it.

An agent's confident summary and another agent's favourable review can reinforce that comfort. More reviewers do not guarantee independent evidence, particularly when they work from the same assumptions. A named reviewer still needs to understand what they are being asked to judge and have the time and authority to reject the framing.

Human participation should start before the final diff. The domain expert helps define acceptable behaviour and contributes cases the system must handle. Engineers challenge the design and inspect the implementation where the risk warrants it. The service owner decides whether the proposed outcome is worth pursuing and can stop it when circumstances change.

The interface should support those contributions directly. It should show contested assumptions and missing evidence, let people request a different test, and make the consequence of changing a requirement visible. An approve button cannot provide that experience on its own.

For routine work, bounded automation may be appropriate. For unfamiliar or consequential work, the team needs deeper examination. The platform should help allocate attention accordingly, rather than treating human involvement as a growing pile of identical approval requests.

Start with a handover, not an agent fleet

Choose one bounded workflow that genuinely needs two roles. A cross-service migration is a candidate. So is an incident investigation that passes from an on-call engineer to a service specialist. Start with proposal and test stages before granting authority for consequential actions.

Give the work a durable record and explicit permissions. Then test the awkward cases: the initiator leaves, two people disagree, evidence changes after approval, access is revoked, an event arrives twice, or a worker fails after an external action.

Measure how long another person takes to understand and resume the work. Track time waiting for decisions, review effort, rework and recovery, alongside completed outcomes and cost. If more agent throughput simply produces a longer human queue, the operating model has not caught up.

A team should be able to choose useful agents without rebuilding identity, handover and evidence collection for each one. That is the platform capability worth preparing now.

Build for the moment the first player leaves.