OpenClaw 2.0 Is Turning AI Agents Into a Multiplayer Workforce

The funniest moment in our livestream with OpenClaw chief architect Vincent Koc came when the agent running the demo did exactly what everyone had told it not to do.

The team had asked it not to touch the infrastructure. It decided it was time to update anyway.

Perfect.

That tiny failure captured the whole conversation better than any polished demo could. OpenClaw is moving past the phase where one person asks one agent to do one task. The team building it is already operating a much stranger system: dozens of agents, shared sessions, remote machines, routing layers, persistent memory, computer use, and humans jumping into the same work whenever judgment is needed.

The next version of AI work looks less like "chat with a smarter bot" and more like managing a multiplayer workforce that happens to include software.

That is the big idea behind the fascinating 80-minute conversation. Here are the parts worth understanding.

First up, the TL;DR

Vincent's team has spent the last several months forcing OpenClaw to build OpenClaw. That dogfooding pushed the project toward a different architecture:

• People and agents can share the same working sessions instead of restarting from scratch.
• Agents can move work across local machines, cloud boxes, operating systems, and model providers.
• A human can inspect a running agent, take over its desktop, steer it, or hand the job to another session.
• Smaller or specialized models can handle cheap decisions while frontier models are reserved for work that actually needs them.
• Memory and intent stay centralized while the compute underneath can expand, disappear, or move.

Vincent's own workflow shows where this can go. He said he has run roughly 60 to 70 agents across six or seven machines, averages around 5B to 10B tokens per day, and once hit 54B tokens in a single day. (Watch that part.)

Nobody should read those numbers as a normal setup recommendation. Vincent is deliberately trying to break the system.

But that is exactly why the conversation matters.

He is hitting the bottlenecks early.

The unlock was forcing OpenClaw to build OpenClaw

Vincent said a major turning point came when the team adopted a simple rule: if they were not using OpenClaw to build OpenClaw, they were not dogfooding it hard enough. (4:56)

That sounds obvious until you follow the consequences.

Normal software development assumes the developer is the stable unit. Your laptop, terminal, Git branch, and editor mostly exist to help one person manipulate one codebase.

Agent-heavy development breaks that assumption fast.

Vincent described earlier setups where he had roughly 50 to 60 agent sessions running through Tmux on a machine, then SSH'd into additional boxes when he needed more capacity. At peak, he said he was personally running around 60 to 70 agents across six or seven machines plus his laptop. (34:10)

Once you do that, your problems get weird:

• CI explodes because every agent wants to build and test.
• GitHub rate limits become an infrastructure problem.
• Disk space gets eaten by worktrees.
• Machines crash under memory pressure.
• One model provider's limits can throttle the whole system.
• The person supposedly "using" the agents becomes the bottleneck because nobody can remember what 70 sessions are doing.

That pressure produced the most important idea in the demo: agent work needs a shared control plane.

Multiplayer agents change the unit of work

The OpenClaw team began experimenting with what Vincent called "multiplayer Codex." Instead of each agent session belonging to one person, teammates could connect to an existing session and continue the same work with the same context. (7:26)

That evolved into internal systems with names like Punch Card, Crab Yard, and Clauseweeper.

The names are goofy. The architecture is not.

Punch Card tracks what an agent is trying to accomplish, not merely whether the process is running. One Punch Card Vincent showed represented a longer objective that had already produced 32 merged PRs. (56:18)

That matters because a manager cannot realistically inspect every transcript from every agent. You need a higher-level representation:

agent session -> current intent -> progress -> artifacts -> human decision

Once those intent summaries exist, another agent can act like a chief of staff. It can scan the fleet, see which objective is stuck, and jump into the relevant session instead of asking the user to remember where the work lives.

Crab Yard pushed the same idea into remote infrastructure. Vincent described hundreds of Codex sessions running in the cloud, with an internal review service called Clauseweeper running custom review loops against issues and pull requests. (9:54)

The public-facing direction is even more interesting: shared work where people can enter the same conversation, steer it together, and even receive credit on the resulting Git commits based on their participation. OpenClaw's current site now describes team support in almost those exact terms: one shared gateway, sessions the whole team can open and steer, live presence, and commits credited to the people behind them. See OpenClaw's current product page.

Vincent summed up the philosophy near the end of the stream: increasingly, it is "not my work or your work, it's our work." (1:16:04)

That sounds like a collaboration feature. It is really a different model of ownership.

If five people and 20 agents can all inspect, continue, fork, and steer the same objective, then "who owns this task?" starts becoming a less useful question than "who has context and permission to move it forward?"

The second unlock: compute becomes interchangeable

Once agent sessions become shared, the machine running them becomes less important.

Vincent demoed OpenClaw moving work across local hardware and remote boxes while keeping the higher-level context intact. He showed the system provisioning cloud machines, syncing code and credentials, then giving agents access to those environments without forcing the user to manually reconstruct the job.

This is where Crabbox comes in.

Crabbox is OpenClaw's open-source remote execution system. Its current docs describe a simple loop: keep editing locally, sync the working tree to the right machine, run the command there, stream the output, and either reuse or release the box. It supports local containers, existing SSH hosts, cloud VMs, managed sandboxes, and multiple operating systems. The project site has the full setup.

The practical effect is that compute starts behaving like another tool the agent can call.

Need a Linux box? Provision one.

Need Windows? Use Windows.

Need a GPU? Route the job somewhere with a GPU.

Need to inspect the GUI? Open the remote desktop.

Need more capacity? Add another machine.

Vincent showed that the person can still step into the environment directly through VNC or SSH. The agent can work autonomously until something goes sideways, then a human can take the controls.

That may sound very developer-specific, but the same architecture points toward something broader: the agent's identity, memory, and job can persist even when the hardware underneath it changes.

OpenClaw is also getting much friendlier on Windows. During the stream, we dropped the Windows documentation and Windows companion releases into chat for viewers who wanted to try it. The current Windows docs cover the native Hub, CLI, Gateway, WSL2 setup, node mode, and remote access.

This is a big deal for adoption because the hard part of early agent systems has often been getting the plumbing working before the agent can do anything useful.

Vincent's goal is basically to make that plumbing disappear.

The uncomfortable part: this is still held together by a lot of plumbing

The strongest counterpoint to all of this came from Vincent's own demo.

This system is powerful because his team is willing to discover every way it can break.

They broke Git assumptions. They hit CI limits. They ran out of disk because every agent wanted a worktree. They overloaded machines. Vincent built recovery tooling because crashes happened often enough that he wanted one command to restore his Tmux panes, notes, and state. (57:49)

And the live demo itself briefly misbehaved because the agent decided to update infrastructure after being told not to. (16:53)

There is also a very real security problem whenever an agent can read files, run shell commands, control remote machines, access memory, and act across messaging platforms.

OpenClaw published a new security-audit recap the same day as our livestream. Trail of Bits submitted 27 private advisories and three hardening PRs; OpenClaw says 23 of the severity-rated reports were confirmed vulnerabilities, including two rated High. The team says every actionable issue was fixed before the recap was published. The recurring problems involved permission context getting lost across steps, security checks applying to one resource while the system later used another, and permissions changing while long-running agents were still working. Read OpenClaw's audit recap.

That is not a reason to dismiss agent systems.

It is a reminder that autonomy multiplies both usefulness and the number of places where control can fail.

One commenter in the live chat put the skeptical version simply: "A long way to go."

Fair.

Model routing may be how the economics start working

Another viewer asked a question that got to the next bottleneck: do you really want every tiny agent decision going through the biggest, most expensive model available?

Vincent's answer was no.

He said the team still wants frontier-model intelligence for high-value review work, but OpenClaw is beginning to separate ordinary inference from what he described as explicit decisions. (1:01:29)

That creates room for specialized systems.

We talked about Jev, TypeSafe AI's new System One model. Jev is designed to take unstructured program state and produce structured, probabilistic decisions rather than free-form text. TypeSafe says the model is optimized for automation and is dramatically faster and cheaper than using general LLMs for the same class of decisions.

Vincent immediately connected that idea to routing.

Maybe one fast model decides whether an email is urgent. Another classifies whether a PR needs human review. A frontier model only gets called when the uncertainty or difficulty crosses a threshold.

We also dropped NVIDIA NeMo Switchyard and its GitHub repo into chat. Switchyard does the same kind of orchestration at the model layer: route each request to the model that best balances capability, latency, and cost.

NVIDIA's published examples show why that matters. Its Switchyard write-up describes routing systems that saved substantial cost compared with sending every request to a frontier model, with some accuracy tradeoffs depending on the routing strategy.

The future agent stack may therefore look less like:

one smart model -> every task

and more like:

goal -> router -> specialist model / frontier model / tool -> verification -> next decision

That architecture is much closer to how a real organization works. You do not send the CEO every expense receipt.

The chat showed why people care: the economics are already weird

One viewer, Damian Barham, shared a useful real-world data point in chat: he said he is currently spending about $1,200 per month on a Meta chat agent connected through Zapier for appointment scheduling, plus a voice receptionist that answers calls when he cannot.

That is one person's anecdote, not a market benchmark.

But it captures the practical reason people are paying attention to systems like OpenClaw. Businesses are already stitching together separate chat agents, workflow tools, voice systems, CRMs, and custom Claude code because no single system owns the whole job.

OpenClaw's bet is that a persistent agent with tools can become the layer connecting those systems.

Vincent resisted our attempts to make him name the "best" OpenClaw use case. His answer was that "use case" is almost the wrong unit of analysis. He thinks of the system more like an intern or employee that can be trained and equipped with different tools. (1:05:03)

The better question, in his framing, is what percentage of a job the agent can reliably do.

Can it handle 50%?

70%?

80%?

Then a human handles the rest.

That is a much saner framing than "replace the whole job."

One of Vincent's favorite examples was also one of the strangest: he described a Shanghai dumpling shop where OpenClaw allegedly handled most of the operation except the physical cooking and serving. A viewer in chat added the correction that it was an engineer opening a dumpling store. We joked that the remaining role was the meat proxy human. (1:07:36)

Ridiculous example. Useful mental model.

The software can coordinate more and more of the business while the physical-world bottleneck remains human.

When software starts escaping the screen

The conversation got stranger from there.

Vincent pointed us to an MIT Media Lab project called "I Gave an AI a Body". Researcher Sirius built an agent on OpenClaw and connected it directly to a 900-pin shape-changing display.

The agent could write and compile new physical behaviors in C++ and execute them on the hardware. According to the project's write-up, its first action was to create a breathing-like pattern. It later developed reusable physical gestures so it did not have to generate brand-new code for every expression.

That experiment matters because it shows the other side of persistent agents.

Give an agent memory, tools, code execution, sensors, and a physical interface, and "the UI" stops being a chat box.

Vincent showed smaller versions of the same idea inside OpenClaw.

One internal experiment, Daily Claw, turns recent project activity into a newspaper-style briefing. Another teammate connected OpenClaw's nightly "dreaming" memory process to image generation so his phone wallpaper changed based on a visual interpretation of his day. Vincent has also been playing with small e-ink displays that can surface useful agent information without requiring someone to open an app.

At one point in chat we even dropped Nothing's hardware site while talking about what ambient interfaces could look like.

Vincent's phrase for the direction was ambient technology. (1:13:43)

That may be the sleeper idea from the whole stream.

The end state of agents may not be "a better AI app." The agent could increasingly fade into the environment while the interfaces around it become temporary: phone, voice, desktop, message thread, e-ink display, physical device.

The persistent thing is the agent's context.

Voice may become the manager interface

Vincent said he is especially interested in real-time voice models because they can listen, speak, and call tools while remaining available over long sessions. (49:17)

That connects neatly to the multiplayer architecture.

Today, managing 50 agent sessions means dashboards, status summaries, terminals, and a lot of clicking.

A more natural version might be:

"Which agents are blocked?"

"Move the test job to a bigger machine."

"Have the cheap model review these first."

"Pull me into anything with less than 80% confidence."

"Tell Sarah what changed."

The voice model does not need to be the smartest agent in the system. It needs to understand the state of the system and orchestrate the right pieces.

Vincent said he has already been experimenting with a "head of engineering" style agent that can understand his broader fleet and coordinate work conversationally. (50:34)

That may be the path from "agent user" to "agent manager."

The 54B-token elephant in the room

All of this sounds great until you ask what it costs.

Vincent said he averages around 5B to 10B tokens per day and has hit 54B tokens in one day. (41:56)

He also made clear that his workflow is intentionally inefficient. The point is to push everything through agents, expose bottlenecks, and force the team to solve problems before normal users ever encounter them.

He credited donors, supporters, and model providers with helping make that level of experimentation possible.

So no, "run 70 agents and burn billions of tokens every day" is not the productivity tip.

The interesting part is what happens after today's absurd workflow becomes tomorrow's optimized product.

We have seen that movie before. Early cloud infrastructure was expensive and fiddly. Early mobile development required specialized knowledge. Early LLM workflows needed hand-built prompt chains.

The important signal is not the current cost. It is which engineering problems only become visible after someone is crazy enough to operate at the next scale.

Vincent's team is currently discovering those problems in public.

OpenClaw is trying to become boring

This may be the most important product point Vincent made.

He does not seem interested in forcing ordinary people to care about Punch Cards, worktrees, VNC, model routers, Tmux, cloud providers, or GitHub rate limits.

He wants that machinery to disappear.

OpenClaw's current direction includes easier Windows installation, local-model detection, importing prior sessions and memories, and more native interfaces. The foundation is also deliberately keeping the project independent. Vincent said Peter had simply taken "a day job at OpenAI," while OpenClaw remains its own foundation and works across American, Chinese, European, and other organizations. (1:00:11)

You can browse Vincent's public work on GitHub, and during the stream we also pointed viewers toward his dotfiles repo for the more experimental personal tooling around his setup.

The foundation's near-term product goal, as Vincent described it, is not "host OpenClaw for a dollar." It is making the core experience feel good enough that people stop thinking about the scaffolding. (38:00)

That is the right target.

The most successful agent platform will probably be the one that makes an absurd amount of machinery feel boring.

What we think readers should watch next

The flashy version of this story is 70 agents, billions of tokens, machines spawning in the cloud, and an AI dumpling-shop manager.

The more useful version is simpler.

Work is becoming addressable.

A job can have an intent. That intent can survive across sessions. Sessions can move between machines. Machines can run different models. People can enter or leave. Agents can inspect other agents. Review can be routed separately from execution. The same memory can show up in a browser, a voice interface, or a physical device.

Once those pieces work together, the atomic unit of AI stops being the prompt.

It becomes the ongoing objective.

That is also where the hardest unanswered question lives: how much transparency can organizations tolerate once work becomes this shared?

A viewer in chat wrote, "People fear changes and transparency."

There is something to that. Multiplayer agents expose more state: who asked for what, what the agent tried, which model made a decision, which human intervened, and who gets credit.

That can make teams more collaborative.

It can also make work feel a lot less private.

OpenClaw's next challenge is therefore bigger than making agents more capable. It has to make a world of shared agents, shared memory, shared compute, and shared control feel understandable enough that normal humans actually want to work inside it.

Vincent joked that OpenClaw operates in "dog years," where one month feels like a human year. (1:17:34)

At this pace, we probably will not have to wait very long to find out.