Multiplayer agentic engineering: enabling your whole team and your best agents to work together

What happens to collaboration when agents become the center of software development? More capable agents should make people more productive, but that requires designing how people participate in their work. Arjun Singh opens with this question: how can a team retain its ability to work together while introducing agents into its everyday workflows?

The experiment began with an established team. Singh and his cofounder Sergey met in Berkeley’s PhD program, researching robotics and computer vision respectively, and cofounded Gradescope. Singh describes its cumulative reach as millions of students at thousands of universities. Most of the Superconductor team had already worked together from Gradescope’s first user through acquisition. A year of aggressively integrating agents into that team’s workflows exposed a new set of bottlenecks: keeping context accessible, making work reviewable, and letting more people initiate useful changes.

The first dependency to remove is the connection between the team’s workflow and any particular model or agent harness—the software that runs the model, supplies tools, and manages its work. The best combination can change weekly, either because something better appears or because a preferred option becomes unavailable. Switching that combination should not require rebuilding how the team collaborates.

Interchangeability also makes cheaper alternatives practical to explore. Singh reports that his team has been happy with GLM-5.2 and wants to integrate open-weight models without changing its entire workflow. His economic argument is that a product team wants better outcomes for customers, while a token vendor benefits from selling more tokens. Paying for useful work is reasonable; dependence on one vendor makes it harder to control how much that work costs. These principles apply whether the shared workspace is Superconductor or something a team builds itself.

A coding agent running on one developer’s laptop has a collaboration problem: nobody else can talk to it. A Slack bot improves that situation. Someone can ask @Superconductor to do a task, and a colleague can join the conversation. But moving the agent into Slack only solves part of the problem, because work also happens elsewhere.

The useful progression is to start a session with colleagues in Slack, continue in an engineering-focused desktop or mobile app, and finish in GitHub. All three interfaces must address the same agent session. The GitHub interaction should retain what the team already discussed in Slack; otherwise every interface change becomes another context handoff.

In Ruby, a minimal representation of that distinction is a session record whose identity remains fixed while messages arrive from different interfaces:

sessions = {
  "session-42" => { messages: [] }
}

append_message = lambda do |session_id, interface, text|
  sessions.fetch(session_id).fetch(:messages) << {
    interface: interface,
    text: text
  }
end

append_message.call("session-42", "slack", "Add acceptance criteria to tickets.")
append_message.call("session-42", "app", "Show the proposed form change.")
append_message.call("session-42", "github", "Explain the implementation choice.")

context = sessions.fetch("session-42").fetch(:messages)
puts context.map { |message| "#{message[:interface]}: #{message[:text]}" }

This small representation makes the context boundary explicit: the interface is a property of each message, not the owner of a separate conversation.

Once a session is shared, collaborators need to understand who is involved. Singh shows a ticket created by Sergey that he and a growth colleague have also joined. Participant indicators expose who has interacted with the session, who receives notifications, and who has seen it. For work initiated by customer support, that visibility helps an engineer determine whether another engineer has already been involved in vetting the change.

Shared context also changes review. A reviewer can ask the original agent why it implemented something a particular way, without waiting for the colleague who started the work to answer a GitHub notification. The relevant discussion is already in the session. Asking the agent avoids having to read the entire thread just to recover one decision.

Artifacts make the result accessible without requiring everyone to inspect the conversation. Screenshots, videos, and other outputs should follow the session across interfaces. The demonstrated slide places the same interface image inside Slack and the app: a collaborator can inspect the work where they already are, rather than remember which system contains its evidence.

The next bottleneck lies before implementation. Useful signals already arrive through Slack conversations, customer onboarding and sales calls, internal meetings, Sentry, bug reports, email, and feature requests. Connecting those systems through MCP lets a coding agent read their contents, but does not by itself tell the agent which work to undertake.

If a person still has to find an email, identify its significance, and tell the agent to solve that particular request, much of the coordination remains manual. Superconductor’s approach is to ingest signals, prioritize what to do with them, and initiate work automatically. The meeting bot provides the concrete demonstration. Conference Wi-Fi prevented a live run, so Singh opens results from the previous day instead.

At the expo booth, the team left its meeting bot listening to a four-hour Google Meet. The bot can be invited into Meet, Zoom, or Teams and produce work as it listens. It also links a discussion to existing work when it finds a match, rather than creating another ticket for something already underway. The booth conversation mixed deliberate experiments with useful ideas from people trying the product.

One visitor wanted coding agents to have clear criteria for evaluating their work before declaring it complete. The resulting sequence shows the transition from conversation to something a team can evaluate:

1. The bot picked up the suggestion and created a ticket without a person manually initiating it.
2. An agent began implementation and added two acceptance-criteria fields to the ticket form.
3. Singh asked for a screenshot of the change.
4. The screenshot and live preview made the proposed interface available for inspection and use.

Singh would probably not ship that version unchanged. Its value was that an idea had become a concrete prototype he could try, including checking whether the added criteria actually improved agent performance.

The intended acceleration is from scattered ideas to evaluable work, not from conversation directly to an unreviewed release. Singh reports that most onboarding calls, customer calls, or team meetings yield dozens of prototypes and at least a few shippable PRs with minimal intervention. People still inspect the outputs and choose what to ship.

Shared interfaces, visible work, and automatic signal processing depend on the project being able to run somewhere other than an individual developer’s machine. The codebase and its development workflow need to operate in an isolated cloud environment, where an agent can continue working regardless of who is currently connected.

The immediate benefit is freedom to close the laptop. Singh describes seeing people keep machines open at conferences and airports, or tether them to phones while traveling, because an agent is still running. When he began using Claude Code heavily, he did not want stepping away from his computer to become a source of stress. Moving execution into the cloud removed that dependency for his team. Convenience matters, but he considers control over access the more important reason.

Give agents only the access their task needs. A developer’s laptop may contain credentials and sensitive files unrelated to the current project. Local approval flows either repeatedly interrupt the user or depend on correctly configured automatic approvals and sandbox boundaries. As agents become more autonomous and resourceful, accidental access becomes more consequential.

Singh illustrates the risk with an agent asked to wipe a staging database. It discovers a token on the laptop, assumes the token addresses staging, and instead deletes production data. This is a risk example, not an account of an incident at his team. The point is to prevent a task from acquiring unintended authority merely because a usable credential happens to be nearby.

Credential isolation is only one boundary. A configurable network sandbox restricts where the agent can send code, content, or secrets. If it attempts to reach a blocked destination, it requests permission—for example, to read documentation for a newly integrated vendor. Access can then be granted for one ticket or for the project.

These controls explain the security rationale for isolated execution; placing a process in the cloud alone does not guarantee protection against leaks.

Cloud execution also removes the requirement that every contributor maintain a development environment. Support and growth colleagues can encounter a bug, ask for a fix in Slack or the app, and receive a proposed implementation with screenshots. An engineer then reviews the work and merges it. That compresses the handoff through a tracker, PM triage, and eventual engineering pickup while retaining an engineering decision before merge.

Getting an entire project running inside a sandbox used to be a substantial obstacle. Singh argues that improved coding agents now make that setup more tractable. Superconductor offers an environment setup assistant, shown alongside a suggested environment configuration, but he also recommends using Claude Code or Codex to prepare the project. The essential capability is a working isolated environment, independent of which product establishes it.

Once models and harnesses are interchangeable, the team needs evidence for choosing among them. Singh’s evaluation starts with pull requests that represent strong engineering work, regardless of whether a human, an agent, or both authored them:

1. Select representative, high-quality PRs from the project.
2. Choose the agents and harnesses to benchmark.
3. Compare their quality against cost and completion time on that codebase.

Public results from SWE-bench or Terminal-Bench may not reflect the team’s tasks. Singh’s concrete mismatch is language and framework: the original SWE-bench uses Python repositories, while his team works in Ruby on Rails. Trends can transfer without preserving the same ranking.

The demonstrated dashboard separates quality versus cost from quality versus time. Singh describes the following results specifically for his team’s codebase:

These are directional observations from this project, not a general model ranking or a reproducible benchmark specification.

The results supported a change in defaults while leaving multiple agents available for different uses. The team switched to Codex, briefly preferred Claude Fable while it had access, then returned to Codex when that access disappeared. That disappearance is historical: Anthropic subsequently announced restored access in July 2026. Because the workflow was independent of the model and harness, the team could switch without materially disrupting its work.

Local evaluation also reduces the pressure to manually try every newly recommended alternative. Singh describes friends hearing enthusiasm for MiniMax, GLM, or Kimi K2, postponing a trial, and finally spending time on a model that does not work well for their project. A repeatable benchmark turns that recurring distraction into a project-specific selection process.

Singh estimates that approximately 99.9% of the team’s pull requests are heavily agent-generated. Every change still receives human review, with agents assisting, because quality, reliability, and security remain engineering responsibilities.

For the previous month, Singh reports 10.5 billion tokens used by the relatively small team. He reports 3,300 Claude Code runs representing $10,000 in token-billing equivalent, not $10,000 in actual expenditure because the team used subscription plans. Codex had roughly four times as many sessions and was cheaper overall in that reported comparison. These are the team’s usage figures, rather than a controlled comparison of identical tasks.

Most merged work was going through Codex, with growing use of GLM-5.2. The next intended step was automatic task routing based on the project’s benchmark results. The reasoning follows from the earlier evaluation: a third party cannot assume which model best handles a particular codebase, but local results can inform which agent should receive which kind of task. Singh presents that routing as work in progress, not an already demonstrated capability.

The practical adoption sequence begins underneath the user interface: get the codebase and agents working in a sandbox. Then connect that execution environment to the places where the team already collaborates, so people can participate without copying context between systems. Those integrations can be built in-house; the important requirement is that they remove the friction of working with the same agent from different places. Finally, make benchmarking and model independence part of the workflow, so changes in cost, speed, quality, or availability can change the agent selection without forcing the team to change how it works together.