DEV Community

Cover image for Your Agents Should Be Multiplayer
dev.to staff for Daily Context

Posted on

Your Agents Should Be Multiplayer

AI Engineer World's Fair Coverage

by Sergey Karayev, cofounder @ Superconductor

Recently, my wife and I sat down to plan an upcoming trip. Naturally, we each asked an AI. Trouble was, I had my chat and she had hers, and they knew nothing about each other. So we served as couriers between chatbots: her idea pasted into my chat, my hotel booking screenshotted into hers, the itinerary reconciled by hand in a Google Doc.

I bring this up because your team probably works the same unfortunate way: each person in their own chat or coding agent session, with precious little shared.

I've been building software with the same set of people for over a decade. In the past year, we all got a superpower: coding agents that can do extremely impressive things. But each one (Claude Code, Codex, Cursor, etc.) was built for a single player. That's fine and dandy if you're vibe-coding your own little app. It's just you and Claude, and it's absolutely magical.

But put that same agent on a team and the magic fades quite a bit. The model is no longer the bottleneck. Coordination is. You don't know who's working on what. You can't see that an agent already tried the approach you're about to attempt, and abandoned it. You spend an hour re-deriving context that a teammate has, because it's trapped in their private chat.

Now let me tell you of a better way. On the Superconductor team, every coding agent session is in the cloud, open to anyone else on the team to join. What this enabled was transformative.

Code review improved first. My teammate reviews my work by joining the session I built it in. The session holds the full history of decisions, including the dead ends. Instead of Slacking me "why'd you name it this way?" she asks the agent. She gets her answer, and I never waste time answering. She also doesn't have to check out the branch locally — the live app preview in the cloud sandbox does the job.

Handoffs became easy. If I have to pass a feature to a teammate, he picks it up with full context: what's done, what's left, what the agent already tried. Nothing is trapped on my laptop, and the ball keeps rolling. And since agents don't sleep, a team spread across time zones can push forward around the clock. The old "shift" model of work might be making sense again.

Perhaps most importantly, we are continually learning best practices from each other. Every knowledge worker is facing the same question right now ("what's the best way to use these things?") and mostly figuring it out alone. Your teammates are quickly going to teach you more than any blog post.

And the utility of multiplayer AI goes beyond code. We now have an agent sitting in all of our team and customer meetings, reading the live transcript and taking actions while we talk. Another agent regularly checks on our progress against our stated goals and messages people as needed for clarifications.

My bet is that the agentic company of the future runs on shared cloud sessions. More like Slack threads, less like terminal sessions. The teams that pull ahead will place their agents where everyone can collaborate with them, instead of handing each person a genie with a lamp to hide it in.

My co-founder Arjun expands on the theme in his talk on "multiplayer agentic engineering: how to have your whole team and your best agents work together." Come by today (Thursday, July 2) at 1:55 p.m., Room 2020 — we'd love to hear what you think.

Top comments (1)

Collapse
 
unitbuilds profile image
UnitBuilds

Fair, but there's a better way. You dont need sessions open, you just need a unified sitemap that every agent can view. Think of git-history, but with the context of what, why, by who. That way you code on the same codebase, you each do your own task, but in the end, everyone's agents know exactly what the current state is at all times and when there's a conflict, they can resolve it with eachother on a background thread, instead of pausing your workflow to achieve it. Think unified cache, but for a codebase.