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.

Full Video Insights

Below is the full timecoded insight list from our livestream with Vincent Koc.

• (01:04) Vincent says he began tracking OpenClaw in late November or early December, started maintainer contributions around December or January, and formally joined the team around February.
• (02:03) Vincent agrees OpenClaw marked a shift from agents that merely promised automation toward agents that could actually carry out work using tools.
• (03:28) OpenClaw 2.0 took roughly a month and a half to build, with Vincent saying something close to 20,000 PRs were merged and roughly the last 60% of PR volume landed in that release.
• (03:57) The team deliberately stopped its previous rapid release cadence because 2.0 was changing enough that they wanted the overall experience to feel right before shipping.
• (04:56) A major product unlock came when the team adopted a rule: if they were not using OpenClaw to build OpenClaw, they were not dogfooding the product hard enough.
• (06:00) OpenClaw's move toward "multiplayer" agents grew out of the team's own frustrations with agentic development, including workflows that began breaking assumptions in Git and CI.
• (07:26) Vincent describes early "multiplayer Codex" experiments that let teammates connect to and remotely continue another person's agent session instead of restarting with fresh context.
• (07:26) His "Punch Card" experiment let teammates steer long-running agents, but Vincent configured his agents to accept an overriding instruction only when two maintainers independently supplied the same instruction.
• (09:54) The team eventually moved the concept into the cloud with "Crab Yard," which Vincent describes as hundreds of Codex sessions running remotely.
• (09:54) Crab Yard powers another internal service called "Clauseweeper," where Codex sessions run the team's custom review loops against incoming issues and PRs.
• (10:20) That experimentation evolved into a first-party multiplayer experience where work is shared transparently, teammates can jump into one another's sessions, and agents can turn a team conversation into a program of work.
• (10:20) Vincent says the system can credit people who participated in the originating conversation on the resulting GitHub commits.
• (12:00) Running hundreds of threads across multiple users has become a stress test for OpenClaw, exposing bottlenecks the team can then feed back into development.
• (13:26) The team's workload outgrew a lightweight virtual machine and now runs on what Vincent calls a "huge ass bare metal server," with further horizontal and vertical scaling likely ahead.
• (14:20) Vincent warns that the live demo is running directly off the main development branch, meaning viewers are seeing unreleased software that the team itself uses to find bugs.
• (14:57) Before moving more work into OpenClaw, Vincent's local setup involved hacked-together Tmux sessions running roughly 50 to 60 agents per machine and SSH linking additional machines together.
• (15:56) OpenClaw's "nodes" let the team move workloads between machines and automatically allocate additional compute from cloud providers when local resources are insufficient.
• (16:53) The live demo itself produces an appropriately agentic failure: Vincent had told everyone not to touch the infrastructure, but the agent running it decided it was time to update anyway.
• (17:22) The infrastructure can provision machines across AWS, GCP, Daytona, Alibaba Cloud, and other providers with selectable hardware and operating systems.
• (17:22) Once a cloud box spins up, OpenClaw can sync code and credentials into it and begin running the requested development workload while retaining the user's broader context.
• (18:21) Corey highlights one of the core multiplayer benefits: the user can monitor a large number of otherwise separate agent conversations from a single place.
• (18:40) Vincent switches from his own filtered view to an "everyone" view, exposing the volume of concurrent agent work occurring across the team.
• (19:31) Because development happens inside remote machines, agents can send screenshots or video of their work and humans can remotely take over the underlying environment when necessary.
• (20:58) Vincent demonstrates opening the actual remote machine behind an agent session, giving him the ability to inspect and steer the environment directly.
• (21:56) The team has used computer-use agents to play Doom inside remote machines, treating game performance as an informal benchmark for improving the computer-use workflow.
• (22:21) Vincent estimates computer use now accounts for roughly 10% of his workload, particularly when tasks still require clicking through infrastructure interfaces or verification screens.
• (24:17) The demo is running on a normal OpenClaw service behind a Cloudflare tunnel, plus team-specific plugins that Vincent says also live in the public OpenClaw codebase.
• (25:12) A workload provisioned onto Azure with Windows could expose a Windows desktop in the same interface and be steered just like the Linux-based machine shown in the demo.
• (25:39) Corey notes how easily the system appears able to switch between Windows, macOS, and Linux depending on what a task requires.
• (26:34) The same abstraction works for physical machines the user owns: OpenClaw nodes can expose Macs, Windows machines, or other boxes for agents and teammates to use remotely.
• (28:12) The cloud orchestration layer is an open-source project called "Crabbox," combining a CLI and orchestrator that agents can use to request infrastructure.
• (28:12) Vincent says Crabbox can itself be deployed through infrastructure such as a Cloudflare Worker or Docker image, then provision machines on the user's cloud accounts.
• (28:36) Crabbox supports controls around who is allowed to provision what, although Vincent says explicit cost limits are not yet built in and jokingly invites a PR.
• (29:05) Once a requested machine exists, the user can open its VNC desktop or SSH directly into it from the orchestration environment.
• (29:49) Instead of giving every internal task its own OpenClaw instance, the team prefers a handful of powerful shared instances backed by infrastructure and reporting systems.
• (30:18) The team has built databases and collection tools that pull information from sources such as internal messages, Discord, and GitHub so agents can understand what is happening across the organization.
• (30:47) An early project called Git Crawl emerged because the OpenClaw repo was being overwhelmed by issues and PRs and needed a system for identifying duplicates.
• (31:44) Vincent says one of the first major scaling bottlenecks was CI, because TypeScript and end-to-end testing consumed enormous amounts of compute as agent concurrency rose.
• (32:12) After solving more of the compute problem, Vincent says his recurring bottlenecks became GitHub rate limits, memory, disk space, and the model provider's own rate limits.
• (33:08) Disk space became surprisingly painful because every agent and PR created worktrees, leading the team to experiment with filesystem techniques that avoid storing full physical clones.
• (34:10) At peak, Vincent says he was personally running roughly 60 to 70 agents across six or seven machines plus his laptop.
• (35:10) The next unlock was centralizing more of that fleet inside OpenClaw itself, so the system could manage infrastructure and shift work rather than Vincent manually juggling machines.
• (36:38) Vincent says OpenClaw is moving toward a more mainstream installation experience, including a Windows Store app that installs OpenClaw, configures the gateway, and exposes control through the app.
• (36:38) On sufficiently powerful laptops, OpenClaw can detect available hardware and set up a local model automatically.
• (36:38) Vincent also describes importing existing account information, memories, and sessions from tools such as Codex or Claude so users can continue previous work rather than start over.
• (38:00) The foundation is deliberately not prioritizing a "pay us a dollar and we'll host it" model yet. Vincent says the immediate goal is to make the product itself feel "ten out of ten."
• (38:00) He says other organizations are already building managed services or internal products on top of OpenClaw, including Microsoft Scout using OpenClaw as an underlying engine.
• (39:03) Vincent's explanation for OpenClaw's rapid rise is that agents had been a promise, but there was a gap around simply giving an agent a sandbox where it could steer and build its own tools.
• (40:32) He describes a "Cambrian explosion" in token usage and calls the resulting wave of agentic products the "post-claw era."
• (40:32) Vincent frames the OpenClaw Foundation's broader mission as making agentic AI useful for everyone, with success measured partly by the wider agent ecosystem growing beyond OpenClaw itself.
• (41:06) Corey says OpenClaw radically changed his own sense of token scale: before it, he thought in thousands of tokens; later he encountered 100M-token workloads, which can now feel like a slow day.
• (41:56) Vincent says his personal usage averages roughly 5B to 10B tokens per day and once reached 54B tokens in a single day.
• (42:18) Vincent says effectively 100% of his development work now goes through an agent, even though that deliberately agent-heavy approach is not token-efficient.
• (42:18) He argues that deliberately forcing everything through agents exposes new problems and compels the team to invent infrastructure and workflows that do not yet exist.
• (42:57) Vincent says donors, supporters, and AI labs including OpenAI help make that token consumption possible by subsidizing or supplying model access.
• (43:26) He credits both large organizations and individual GitHub donors with supporting the foundation from the project's early days.
• (45:08) Vincent says he is beginning to feel the original OpenClaw "magic" again in development because he can stay inside a browser instead of living in terminals.
• (45:08) His next target is a similar native experience on phones, potentially with an always-available voice model acting as an orchestrator over many concurrent agent sessions.
• (46:22) Vincent's ideal is infrastructure independence: users might connect local machines, DGXs, cloud compute, and different models, then control everything through one shared interface.
• (46:52) He emphasizes choice rather than a local-versus-cloud ideology: users should control their data, decide where workloads run, and swap models or providers as they wish.
• (47:22) Vincent says maintaining that level of extensibility is one of OpenClaw's hardest problems because every additional messaging platform or provider introduces another integration that must actually work.
• (47:52) Testing messaging integrations may eventually require something resembling a device farm full of agent-controlled accounts and phone numbers because the platforms often interpret automated tests as spam bots.
• (48:22) For some messaging PRs, the team's automation can already validate changes against a live account, attach a video of the result, and let visual language models inspect the change.
• (48:22) Vincent expects this "factory" to automate more small bug fixes and validation work while maintainers still decide what changes ultimately enter the project.
• (49:17) Asked which voice models he likes, Vincent points to what he calls GPT Real Time or GPT Live, particularly its bidirectional ability to listen, speak, and execute tools simultaneously.
• (49:47) What stands out to him is persistence: the voice session can sit quietly for 10 minutes, then immediately resume when the user says something.
• (50:34) Vincent has been experimenting with a "head of engineering" or similar orchestration skill that can understand his broader fleet of agents and coordinate work conversationally.
• (50:43) He revisits Git Crawl, explaining that GitHub issues and PRs are analyzed by LLMs, clustered, vectorized, and stored so agents can quickly retrieve shared project intelligence.
• (52:07) Vincent says the team once had around 25,000 PRs and issues where roughly 70% were duplicates or already solved; using the clustered database, he closed roughly 8,000 in one afternoon.
• (52:59) He says OpenClaw had passed 150,000 total combined PRs and issues by the time of the livestream.
• (53:50) Vincent's older "fleet" system used a private GitHub repo and skills to make every agent aware of other agents, Codex sessions, and machines so work could move between them.
• (54:41) A primitive called "Beam" lets one session hand work to another by sanitizing the current transcript and session state, then transferring that context to the destination machine or session.
• (56:18) Punch Card also stores an agent's current "intent," letting the system capture what a long-running agent is actually trying to accomplish instead of merely recording that it exists.
• (56:18) One example Punch Card entry represented a piece of work that had produced 32 merged PRs, giving Vincent a compact way to understand the larger objective behind a huge stream of changes.
• (56:46) Because those intent summaries are small, a "chief of staff" or engineering-management agent can index all running work and jump directly into the relevant session when something needs steering.
• (57:49) Vincent also built recovery tooling because his machines crashed so often under heavy load; he says he could issue a single restore command and recover Tmux panes, notes, and state.
• (58:28) His broader conclusion from all that infrastructure is that users should not have to manage it manually. He wants most work to move from janky terminals into native apps, messaging, or voice.
• (58:28) Centralizing the agent experience also solves a memory problem: context and memory can stay with the shared system while additional compute is added or removed underneath it.
• (1:00:11) On the OpenAI relationship, Vincent says Peter simply "took a day job at OpenAI" and that OpenClaw itself remains a 100% independent foundation.
• (1:00:11) He says the foundation works with American, Chinese, European, and other organizations rather than aligning itself exclusively with one company.
• (1:00:41) Vincent declines to discuss any OpenAI roadmap overlap but tells viewers to "keep an eye out" for OpenAI Dev Day about a week later.
• (1:01:29) For review agents, Vincent says the team still prioritizes frontier cloud-model intelligence, with fallback mechanisms available if providers go down.
• (1:01:29) OpenClaw is also beginning to distinguish ordinary inference from explicit "decisions," opening the door for specialized decision models such as JEV to handle routing and classification.
• (1:02:28) Vincent says he had already been working on an open-source JEV-like system based on attaching a classifier, and JEV's release motivated him to accelerate that project.
• (1:02:28) One potential application is deciding which model or reasoning level a particular task actually needs rather than sending every request to the same expensive model.
• (1:03:21) Vincent points to NVIDIA's Switchyard as another routing idea: try local inference first, evaluate whether it is sufficiently accurate, and escalate when necessary.
• (1:04:13) After Corey describes using a fast diffusion model for routine OpenClaw work, Vincent floats rebuilding his open JEV-style system around a diffusion approach to make decisions extremely fast.
• (1:04:27) Vincent describes JEV conceptually as a classifier using classical language-model methodology, saying the architecture feels obvious once you understand it.
• (1:05:03) Asked about OpenClaw's best use cases, Vincent argues that "use case" is the wrong framing because OpenClaw is closer to an employee or intern that can be trained and equipped with different tools.
• (1:05:53) His preferred question is not whether an agent can do a task, but what percentage it can do reliably: 50%, 60%, 70%, or 80%, with a human handling the remaining edge cases.
• (1:06:53) Vincent says some enterprises have already deployed OpenClaw broadly enough that hundreds or thousands of separate "claws" are running across employees and teams, though he says those examples are not yet public.
• (1:07:36) One of the stranger stories he recalls is a Shanghai dumpling shop where OpenClaw allegedly ran essentially the entire operation apart from the final physical cooking and serving.
• (1:08:38) Corey describes one of his own agent pipelines: one model finds website updates, another classifies them, JEV handles binary decisions, another model handles edge cases, and Corey provides final approval.
• (1:09:09) Vincent recommends a research video from an MIT-affiliated researcher called Sirius in which OpenClaw was connected to moving wooden blocks and taught to express behaviors resembling emotion.
• (1:09:37) The memorable example is the agent learning a sigh-like physical movement, which Vincent says gave him goosebumps as an illustration of connecting agents and memory to the physical world.
• (1:10:38) OpenClaw plugins can now create dynamic dashboards inside the interface; Vincent shows an internal "Daily Claw" that converts recent project activity into a newspaper-style daily briefing.
• (1:11:16) The Daily Claw was partly inspired by experiments that turn personal digital information into physical daily artifacts, such as automatically printed morning briefings.
• (1:12:21) Vincent is also experimenting with small e-ink displays that could surface OpenClaw information without requiring the user to actively open a phone or computer interface.
• (1:12:53) One teammate connected OpenClaw's nightly "dreaming" memory-summary feature to artwork generation, automatically changing his phone wallpaper based on a visual interpretation of his day.
• (1:13:43) Vincent describes that broader design direction as "ambient technology": digital intelligence present in physical surroundings without demanding constant direct interaction.
• (1:14:33) Asked what model capability is still missing, Vincent says most of what he personally needs already exists; the larger bottleneck is building the application layer that glues capabilities together.
• (1:15:04) Even when a capability is absent, he argues users can increasingly teach the agent the workflow or train a smaller specialized model and give the broader system access to it.
• (1:15:35) Vincent closes with what may be the biggest organizational implication of the demo: multiplayer agents could change how teams think about ownership, transparency, and management.
• (1:16:04) His framing is that work increasingly becomes "not my work or your work, it's our work," because people and agents can continuously enter, inspect, and steer the same shared sessions.
• (1:16:35) Corey predicts the gap between what technically advanced users do today and what mainstream users can do will continue collapsing, joking that the "six years" gap is increasingly more like six to 12 months.
• (1:17:34) Vincent's own joke for the pace is that OpenClaw operates in "dog years": roughly a month of project time can feel like a human year because so much changes so quickly.