I remember when 'multiplayer' became a big promise in SaaS. Several people could work inside the same file, move a sentence, leave a comment, and see where the others were working without passing versions around. For all that changed, productivity still centered on humans: how quickly could a person or a team get to an outcome?
Products such as Figma made simultaneous work and feedback part of the ordinary product experience. The little cursor mattered because it showed that someone else could enter the work where it stood.
When models began taking on longer tasks, I found myself wondering whether we would keep making that comparison, only now with an agent attached to each person. Would it become, 'My agent finished in three hours; yours finished in two'?
We did arrive at that scorecard. But, the question I keep returning to has shifted. When several humans and agents contribute to one outcome, productivity depends on whether the work can travel between them with its decisions intact.
We learned to admire the stopwatch
I understand why agent completion times became such an easy thing to share. A task that might have taken an afternoon can come back in half an hour, and the difference is immediate. You can watch an agent search, draft, code, or revise while you do something else. The timer gives that experience a number.
And, the number does tell you something. If an agent can make a first pass quickly, a builder has more room to inspect it, change direction, and try again. I have no interest in pretending that speed doesn't matter.
The timer stops before the next person has to sort out what happened.
An agent can finish a product brief before the team decides which customer it is for. Another can produce a working prototype from yesterday's requirement. A third can summarize the right research and leave out the conversation in which the team decided what the research meant. Each task may be fast and well executed on its own terms. Someone still has to bring the pieces back into the same reality.
That work doesn't show up on the stopwatch.
The old SaaS idea of multiplayer helps me see why. When several people could edit the same file, the product removed the awkward ritual of saving versions, sending them around, and asking which one was current. We did not have to become faster typists to benefit. We could spend less energy recovering the state of the work.
Agents now make that recovery problem more interesting. Builders can deploy a local agent for the brief and a cloud agent for implementation while a teammate reviews both. A person can ask a clarifying question in a meeting, notice a hesitant reply, or remember why a decision was made. An agent needs a way to encounter the relevant part of that history. Managing the work means making sure each contributor can pick up the decision where it stands. If they cannot, a quick answer may only move the recovery work to the next contributor.
Where the handoff breaks
I keep picturing this in three ordinary places.
Case: One builder, two agents. A local agent helps a builder revise a feature specification. The builder decides to remove an onboarding step after seeing that customers repeatedly skip it. A cloud agent, working from an earlier version, begins building the flow with the step still in place. Both agents are doing their assigned jobs. The builder now has to discover the mismatch, explain the decision again, and reconcile the outputs. Tools such as Codex make supervising multiple agent tasks a visible part of building; the handoff between those tasks is where the builder's judgment has to survive.
Case: Several humans, several agents. A product team is preparing a launch. Research, design, copy, and support each have a different view of the customer. A human chooses to narrow the first release to one group, but the writing agent still has the broader brief while the design agent has the revised one. Everyone can be busy. The launch can still drift. The problem is not a lack of contributors; it is that the decision reached only some of them.
Case: An external partner. A company and a specialist firm work on the same launch. The partner can use the conclusion that the first release serves a narrower audience, but the underlying customer interviews stay with the company. The handoff needs to say what the partner can build from that conclusion, and who can approve a change to it.
The three scenes share a familiar irritation: the next contributor arrives, and we begin the orientation again.
What follows the cursor?
We have been naming pieces of this problem for a while. A 'skill' can capture the way a person performs a recurring task: the standard, the steps, the examples, the things they would check before calling it done. A specialized agent can take a particular role. 'Context' has become our broad name for the information an agent needs to work with some awareness of its surroundings.
These are useful inventions. I use the word 'context' often myself. But, it can hide two different kinds of knowledge.
One kind is reusable. A writing skill can teach an agent how the team evaluates a launch audience, checks claims, and recognizes a good draft. You would want that judgment available each time the task returns.
The other kind belongs to this launch, today. The team chose a narrower audience after the customer call. The designer has a concern about the first screen. The draft is waiting for one person's approval. The next contributor needs those facts, including which are settled and which are still open.
The first is expertise; the second is the living state of the work. A writing agent can follow every rule in the team's skill and still promise a feature to the audience the team decided to leave out of this launch.
The cursor was a sign of presence. What I want now is a sign of continuity: a way for the next person or agent to see where the work stands and why it got there.
Follow one launch through
Let us stay with the launch for a moment, because this is where 'multiplayer' stops being an attractive label and becomes a practical question.
Imagine a team preparing to launch a feature that helps support teams triage incoming requests. A research agent looks through customer calls and support notes. Small support teams can use the feature as it stands; larger operations teams need an approval workflow the product does not have yet. A human builder reads that finding alongside the original plan and chooses small support teams for the first release.
What should happen next?
The easy version is to update a sentence in the brief and ask a writing agent for new copy. It returns a polished page with a line promising the feature to “every support organization.” That phrase came from the earlier brief. A teammate catches it in review, but now has to find out whether the audience decision changed again or the agent missed it. Meanwhile, a cloud agent building the onboarding screen may still be working from that same broad promise.
The useful version of the handoff carries a little more than a corrected sentence: small support teams for this release; larger teams need approval routing; the launch owner approved the change; the onboarding screen is still in progress. The reviewer can point to that decision and send the broad claim back. The writing agent revises it for small teams. The designer can check whether the first screen speaks to them, and the support teammate can prepare for the questions those customers will bring. Each contributor still has room for judgment, but the next one can act without reopening the audience debate.
And, if the choice changes again, the next agent should be able to see that too. 'Current' is not a permanent property of a document. It is a relationship between a decision and the moment of the work.
This is where I put the limits of connectivity. MCP standardizes how AI applications connect with tools and data sources. It can help an agent reach the customer note. In this launch, access still leaves the team with a coordination question: which audience decision governs the next task, and who can change it?
Across organizations, the partner can receive the approved audience decision and its limits while the customer records stay with the original team. The next contributor needs enough to continue the launch, within the boundary the teams agreed on.
Notice how little of this depends on agents becoming slower or humans doing more administrative work. It depends on making the decisions we already make easier to carry forward. Sometimes that will be a short note attached to the task. Sometimes it will be a review, a shared artifact, or a question an agent pauses to ask. The form can vary. The purpose is the same: let the next contributor continue the work rather than reconstruct it.
What would we measure instead?
I suspect we will keep celebrating the quick agent run. I probably will too. There is real delight in seeing something move that quickly.
But, when the work is shared, I would also want to ask what happened after the run. Did the reviewer understand the agent's assumptions? Did another agent inherit the latest decision? Did the builder need to explain the same constraint for the fourth time? Could an external partner contribute within the agreed boundary without a fresh round of translation?
These questions are less neat than an elapsed-time chart. They get closer to the work as a team experiences it. A fast draft that sends the reviewer back through old briefs is one kind of outcome. A draft whose assumptions can be inspected and corrected without rediscovering the decision is another.
We started by making shared work visible. Now we are trying to make it transferable among contributors who do not all think, remember, or act in the same way. In the launch, the useful moment was the reviewer seeing why “every support organization” no longer belonged on the page. The workspace helped a person make that judgment, then helped an agent carry it into the revision.
Perhaps that is the next form of multiplayer productivity. The stopwatch can tell us when an agent finished. I want to know what the next person, or the next agent, could do when they arrived.
