Building OpenClaw with OpenClaw: Turning Agents into Team Collaborators

At OpenAI DevDay, Peter Steinberger, founder of OpenClaw, and Kevin Lin, head of OpenClaw Enterprise (OCE) at OpenAI, shared how their team is building OpenClaw with OpenClaw: ClawLabs: Building Open Source Together.

Peter was already running multiple Agent sessions concurrently, but whenever teammates wanted to get involved, they still had to ask him to relay their requests. During code reviews, reviewers could often see only what had changed, without understanding why it changed that way. To bridge this gap, they moved their work into shared sessions where teammates could participate directly, bringing dashboards, meeting notes, and ongoing maintenance into the same workspace. As the team grew, they also needed a unified way to manage identities and permissions for these persistent Agents.

OpenClaw is an open-source platform that lets Agents run persistently and collaborate across tools and teams. It is held by the independent non-profit OpenClaw Foundation, with support from OpenAI. At the time of the presentation, the platform already supported logging in with a ChatGPT account, connecting subscriptions, reusing plugins, and viewing Codex sessions. OpenClaw Enterprise (OCE) handles Agent deployment, identity, and access management within organizations.

Why Personal Sessions Fall Short for Team Collaboration

In his opening remarks, Peter reflected on how his workflow evolved while maintaining open-source projects. Early on, he worked primarily in a terminal (CLI) environment: splitting his screen across multiple Codex sessions, shuttling code between windows. As model capabilities improved, the need to hit Esc to interrupt and fine-tune Agents gradually decreased, and his workflow shifted toward a desktop client equipped with a graphical UI, a built-in browser, and review panels.

As parallel tasks and experiments multiplied, physical limits on a single machine quickly surfaced:

• Laptop disk space was rapidly exhausted;
• Cooling fans ran continuously under heavy loads;
• To offload pressure from his local machine, he began connecting to multiple DevBoxes and set up a cloud testing environment called Crabbox, operating six to ten machines at once to run code and experiments, managing them via Codex or VNC remote desktop.

Adding more machines did not eliminate collaborative roadblocks. When other teammates wanted to participate or assign tasks to an Agent, they could not access the sessions directly and had to ask Peter to relay their requests. Frank Allenby coined the term “Meat Proxy” to describe this dynamic: the developer becomes an intermediary between team members and the AI—colleagues bring requirements to you to relay to the Agent, and you copy the generated code back to them. Team members are not truly collaborating around the Agent.

Furthermore, the decision context behind the code easily breaks down. A concise prompt might produce thousands of lines of code changes, yet the underlying prompts and conversation history often remain trapped inside an individual's local client. When teammates review a large pull request in the codebase, they can see what specific lines changed, but struggle to grasp the prompts and conversational rationale that shaped them.

To overcome this fragmented, disconnected setup, the team began exploring ways to move Agents from isolated individual machines into a shared multiplayer workspace.

How Shared Sessions Bring Teammates into the Same Workflow

To address the siloed workflow, the team introduced a multiplayer collaboration model. Instead of treating servers merely as isolated execution backends, they transformed them into a shared workspace where teammates can be online together at any time.

On the shared server, teammates can view one another's session histories directly and send prompts into each other's sessions to take over or steer the work.

Co-editing: A Mini-game Demo

During the live demo, Peter used voice input to suggest that PartyClaw create a mini-game resembling Frogger. After submitting the request, the system noted that teammate Kevin had already built a working version (Lily Lane). Peter opened it to test, and decided he wanted to change the main character from a frog to a lobster.

Peter then shared a temporary link for live participants to join the server. In this multiplayer environment, the UI indicated multiple members typing simultaneously. Peter beat the others to submit a prompt asking for a lobster character and no elephant; the game view reloaded, generating a version featuring a lobster and sharks.

Prerequisites for Sharing: Equal Permissions and Mutual Trust

This multiplayer collaboration model rests on specific prerequisites: it is designed for teams whose members have equal access permissions and mutual trust. As Peter explicitly cautioned during the talk: “Don't invite anyone who you don't want to mess with your sessions.” Concurrent multiplayer participation means members can modify one another's sessions, which requires a shared understanding of project goals. While shared sessions help clarify mutual intent early and reduce certain conflicts, they do not mean traditional Pull Requests have disappeared (a PR, or Pull Request, is a proposed set of changes submitted to a repository for review and merging).

Moving personal sessions onto a server visible to the entire team typically demands a cultural shift. Peter mentioned earlier attempts to write plugins that encouraged members to attach sanitized conversation logs when opening PRs, but teammates rarely wanted to share them—and he was sometimes reluctant himself, as prompts exchanged with an Agent often reflect idiosyncratic trial-and-error habits and casual phrasing. Once the team made sessions public by default on their internal server, it took about a day of adjustment before people grew accustomed to it. They began learning effective prompting techniques from one another and catching misalignments much earlier.

Understanding Changes: Victor's Table Case

Transparent session histories play a critical role in daily team collaboration. The presentation featured a real-world case where divergent perceptions of a change sparked discussion.

One morning, Peter noticed a PR submitted by an automation tool authored by his colleague Victor. The PR shrunk the chat tables in the UI. Having spent time the previous day enlarging those exact tables, Peter was bewildered when he saw the change.

The PR description included a link to the associated working session, allowing others to trace the original interaction. Peter clicked through to Victor's working session and uncovered what had actually happened:

1. Victor had not discarded earlier work arbitrarily; he had directly reused the context from Peter's session the previous day;
2. Victor had left Peter a heads-up via email or messaging within the session;
3. During the session, Victor had vented about slow CI runtimes in passing (an unrelated side topic in the thread); on the table layout itself, Victor had carefully refined the design, making tables expand adaptively based on content to resolve issues with being either too large or too small.

With this context in hand, Peter approved Victor's approach, avoiding an unnecessary misunderstanding. When code reviews directly link back to the working session that generated the code, teammates gain immediate insight into the rationale behind changes, reducing friction in asynchronous collaboration.

Keeping Shared Tools and Long-Running Tasks Alive

Shared Tools: Session-Generated, Automatically Updated

In team collaboration, developers often maintain supporting utilities such as CI runtime dashboards and community PR trackers. Previously, these tools were scattered across different servers or automation scripts, making updates and upkeep tedious.

Peter used the term “Jellyware” to describe lightweight internal tools generated inside a session that can adapt quickly to changes:

• Such tools are typically created in a session as an artifact containing code, paired with an automation task that updates the session on a schedule;
• When someone wants to tweak the interface or functionality, they can prompt the Agent directly (for example, telling it to “turn this panel blue”), and the Agent updates the code and refreshes the view.

Beyond dashboards, the team built Daily Claw, an experiment that compiles merged changes from the server into a newspaper format. Peter noted that this daily digest is “sometimes pretty good, but many times it's very wrong”—its generated summaries still require human verification and cannot be treated as an authoritative record.

CI Dashboard: Inspecting Test Runtimes

Continuous integration (CI) pipelines are critical for running tests frequently. As Agent collaboration deepened, traditional exhaustive test suites created bottlenecks in response speed.

Peter mentioned during the talk that the existing CI model needs further refinement. Together with Codex, he is exploring model-assisted evaluation to determine which subsets of tests are genuinely relevant, pruning runs accordingly. This remains an ongoing experiment rather than a solved, production-ready solution.

Slop Meter: A Nudge to Clean Up Redundant Code

When using Agents to write code, volume accumulates rapidly. To prevent dead or redundant code from piling up, Peter built a dashboard called Slop Meter to keep code bloat visible and prompt Agents to trim unused code. Peter noted that the dashboard heightened awareness and steered habits in a positive direction.

Meeting Notes: Preserving Context and Handing Off Tasks

For daily communication, the team used a prompt paired with a model (GPT-5.6-Luna) to automatically summarize voice transcripts from Discord meetings.

Peter explained that these meeting-note Agents can also connect to GPT Live for two-way voice conversations, allowing developers to ask about project status or trigger new tasks directly during meetings (this live voice capability was not demonstrated on stage). Because the Agent maintains a consistent identity on the server and inherits accumulated project context from the primary session, new requests from meetings can hook straight into ongoing project work.

Long-Running Tasks: Loops for Maintenance, Goals for Defined Outcomes

For background automations, Peter drew a sharp distinction between “Loops” and “Goals”: Loops handle ongoing, recurring checks, whereas Goals tackle long-running tasks with a well-defined end state.

Loops: Continually Monitoring Feedback and Releases

Continuous loops maintain routine operations and quality monitoring:

• Bug-fixing loop: Peter wrote small CLI tools enabling Agents to pull feedback efficiently from Discord, social platforms, and GitHub. After ingesting and categorizing reports, the Agent investigates reported issues (such as update failures) and spins up an isolated test environment to attempt reproduction. Only when the bug is cleanly reproduced will the Agent attempt a patch; once the fix is verified as working, it is handed to another review Agent for code review; only when all conditions are satisfied is the change merged automatically. If reproduction fails, verification fails, or the review is rejected, the change cannot be merged.
• Release detection and regression checks: Following daily releases on the team server, an update loop detects the new release, captures a snapshot, and inspects it for performance regressions or areas needing polish.

These loops can break down or require manual intervention and maintenance as circumstances change. Previously, they ran scattered across individuals' machines, making it difficult even to locate where each was hosted. The team is now migrating them onto team servers so other members can inspect and take them over.

Goals: Driving Refactoring with a Clear End State

Unlike routine loops, Goals target tasks with a defined finish line.

Peter cited an ongoing example: refactoring the codebase from synchronous SQLite to asynchronous database access. The project currently still uses SQLite, and the refactoring goal remains actively in progress; as the system scales, the team is also considering making the database swappable in the future. According to Peter's self-report on stage, this goal task had been running in his local Codex environment for 18 days, incrementally splitting out and landing more than 100 PRs along the way.

Scaling Up: How OCE Governs Identity and Permissions

The shared workspace described earlier is built for peers with equal permissions and high trust. Across an entire enterprise, however, different teams and tasks require separate resource allocations and access scopes; organizations must also track which Agents are running, under what identities they access systems, and how to adjust permissions or decommission them. Beyond multiplayer collaboration, organizations require a unified governance layer.

To address enterprise deployment and permission governance, Kevin Lin of OpenAI unveiled the open-source project OpenClaw Enterprise (OCE). OCE provides a centralized control plane to govern Agent deployment, configuration, identity, and access permissions (the control plane is the management layer; multi-tenancy isolates resources and access boundaries across different teams or projects).

Actual execution is carried out by the Harness (the runtime framework wrapped around models that handles tool calling, execution environments, and context state), which governs how Agents interact with tools and environments. OpenClaw can use Codex's open-source execution harness at its base (the open-source release covers the execution harness, not the model itself or the full cloud service suite); OCE sits as the management layer above the execution tier. Official release materials emphasize that OCE remains vendor-neutral: not only can models be swapped freely, but core components including the Harness, models, and sandboxes can all be replaced with third-party alternatives or in-house implementations.

Security Controls: How the Four Mechanisms Work Together

Kevin introduced four security mechanisms underpinning Agent deployments, each fulfilling distinct boundary responsibilities:

1. Separate Workloads: Deterministic control logic (such as gateways and configuration management) is decoupled from non-deterministic Agent code execution. Execution environments run in isolated containers or sandboxes to prevent Agents from tampering with their underlying runtime configurations.
2. Sandboxing: Sandboxes impose runtime boundaries on Agent behavior, restricting outbound network traffic, filesystem read/write paths, and target code repositories to limit privilege escalation.
3. Model-based Auto-review: Before sensitive actions execute, a secondary model assesses operational risk and can block the action as an additional defense layer. Model review provides risk assessment; it cannot substitute for system access control policies, nor is it equivalent to human approval.
4. Dedicated Identity: Agents are assigned dedicated service accounts and connectors, existing as persistent entities rather than borrowing human credentials. This gives Agents independent audit trails, allowing them to be managed, audited, or disabled individually.

In actual configurations, these four mechanisms reinforce one another. Take the community Agent “Fred” from the demo: the system grants it read-only access to the codebase so it can inspect code to answer questions without permission to push changes; when connected to Linear, it can read project plans, but writes require explicit team approval; simultaneously, model reviews filter operational risk without granting organizational authority. These settings govern different actions by the same Agent independently: being able to read code does not confer push access, and connecting to Linear does not grant free rein to modify issues.

Deployment Demo: Configuring Agents by Task

In the live demonstration, Kevin showed how to provision a community Agent named Fred within the OCE console.

The console provides a Preset mechanism—pre-packaged, configurable agent bundles—to spin up Agent drafts equipped with common security defaults:

• The runtime framework is set to Codex Harness;
• A dedicated, standalone service account is assigned;
• The codebase is set to read-only so it can inspect code to answer questions;
• Integration with Linear: reads project planning data, while write operations require team approval;
• Integration with Slack: references existing Bot and App Tokens from the credential store, restricted to 4 selected channels, with direct messaging disabled (these represent the specific channels and DM policies selected for this demo).

Cooper: Teammates Continuing a Development Session

While waiting for Fred to spin up, Kevin switched to Cooper, an active software engineering Agent already running.

Cooper serves as a persistent collaborative Agent assisting the team daily with issue triage, defect investigation, and feature development. Kevin noted that every Agent deployed via OCE comes with built-in multiplayer support. He demonstrated opening an authenticated Cooper team server session: colleagues can log into the exact same working session to track progress in real time or type prompts directly to steer development.

During the demo, Kevin asked Cooper to add a “token usage heatmap per Agent” to the console interface, and followed up in the session by requesting “custom palette support.” The stage demo showed dispatching the request and guiding the session, but did not display the completed UI. According to Kevin's self-report during the talk, OpenAI has deployed over 400 Claw instances internally to assist with fixing code, running experiments, analyzing data, and investigating security issues; for user-reported Codex issues, software Agents triage, reproduce them in test environments, and merge some of the resulting fix PRs.

Fred: Pulling Work Context and Missing the Mark

After showcasing Cooper, Kevin returned to the community interface and asked the newly launched Fred: “What are we launching today?”

Fred received the prompt and retrieved context across Linear and Slack. Seconds later, Fred answered, but only surfaced OpenClaw's release notes, missing the headline announcement of OCE. Kevin remarked on stage that there might be a plugin issue (“Oops, I think we have some plug-in issues”), joking that Fred would do better next time.

Where OCE Stands Today and Current Limitations

According to the official release announcement, OCE is currently in a pre-1.0 open-source collaborative building phase, suitable for organizations conducting internal pilots. Initiated by OpenAI and donated early to the independent non-profit OpenClaw Foundation, it is developed jointly with partners like Red Hat and NVIDIA to preserve vendor neutrality. Kevin's comparison to Kubernetes on stage reflected a long-term aspiration to become foundational infrastructure for Agent deployment and governance, rather than claiming it is already an established industry standard today.

Regarding runtime architecture, Kevin noted on stage that internal practice isolates runtime environments across separate clusters, whereas the public architecture documentation specifies a single Kubernetes cluster as its default model:

• Under the single-cluster multi-tenant model, the Embedded mode co-locates the Gateway and Harness within the data plane;
• Only under Dedicated Kubernetes execution are independent Gateway and Harness Pods deployed with separated identities and storage within tenant namespaces; the Gateway communicates with the Harness via restricted file-operation APIs rather than mounting its workspace directly.

A dual-cluster setup remains experimental. In single-cluster deployments, operators must configure mutually exclusive node pools, network policies, and storage isolation rules themselves; because namespace administrators hold elevated privileges, network policies and credential mounts do not form a hard barrier against namespace admins.

Additionally, certain planned features in the public design doc (such as external ingress gateways and credential-free inference broker drivers) are not yet fully supported. The presentation also touched on Dots, OpenAI's official enterprise integration offering: Dots focuses on an out-of-the-box native product experience, whereas OpenClaw and OCE emphasize open-source neutrality, model interchangeability, full code control, and self-hosted infrastructure. Future interoperability between the two remains an area of ongoing exploration.

After Automation: What Remains Human Responsibility

From scattered terminal sessions on individual machines, to shared servers that retain collaboration context, to a control plane that manages permissions and deployment boundaries, the talk traces how software engineering can move from human message relaying to team collaboration.

Design Judgment: Victor's Sidebar Iteration

In his long-term vision, Peter imagines every project staffed by a persistent Agent equipped with its own memory, automations, goals, and loops, maintained through high-level instructions from humans. Under this division of labor, the engineer's irreplaceable core value lies in taste—the feel of interaction details, visual design intuition, and architectural tradeoffs remain subjective judgments that cannot be fully delegated to a model.

The refinement of the online presence sidebar demonstrated during the talk captures this process: Peter first assembled a rough version showing who was online. Victor wanted to make it look better, prompting an Agent to produce multiple design iterations and even having the Agent build a dedicated editor to tweak styling, yet Victor remained unsatisfied. Other teammates then jumped into the same session to make edits and layer on feedback, eventually settling on a much more compelling version.

This dynamic illustrates that what teams accumulate in a shared workspace is not merely the final merged code, but also the iterative deliberation—how prompts are phrased and how competing generated options are weighed. No matter how smoothly background automations run, aesthetic judgment in selecting solutions and the responsibility for maintaining Agent systems stay firmly in human hands.

Operations and Maintenance: Keeping Automations Operational

Peter summarized this division of labor as teams “maintaining the Agents that build software for them.” While continuous loops can monitor feedback and goals can steadily refactor architectures, these background automations break and drift, requiring ongoing human maintenance. In user experience, architectural style, and tradeoff decisions, human taste serves as an indispensable compass.

Open-Source Collaboration: Broadening Tool Access and Patching Vulnerabilities

At the open-source community level, the team expanded the Codex support program for open-source projects and, through the Patch the Planet project with security firms like Trail of Bits, explored using Agents to patch entire classes of vulnerabilities across open-source infrastructure. Successfully anchoring persistent Agents in real engineering teams requires trustworthy permissions and isolation boundaries—and continuously relies on human engineers injecting judgment into shared collaboration.