OpenClaw DevDay 2026: How Persistent Agents Are Reshaping Open-Source Collaboration

At a workshop during OpenAI DevDay 2026, Peter, a core maintainer of OpenClaw, shared how his workflow for maintaining open-source projects has evolved over the past year — and what changed when the team started "building OC with OC." This talk was more than a product demo; it felt like an open-ended exploration of how software collaboration should work in the age of agents.

From CLI to Multi-Machine Collaboration: A Year of Workflow Evolution

Peter described his journey over the past year as a revolution that started in the terminal. He began by living entirely in the CLI — split panes, massive numbers of concurrent sessions, code flying across screens, and constant tapping of Escape to steer agents back on track. As models grew smarter, the need for that kind of "manual driving" dropped dramatically.

He then moved to the desktop, where it was easier to spin up many sessions at once, text was more readable, and he gained access to visualization, an inline browser, and code review capabilities. But a new bottleneck emerged: a single machine couldn't handle that many concurrent experiments, and the fans were "loud enough to sound like a chat engine." So he connected a dev box to share the load, set up a cloud-based "grab box" for running tests, and at peak times had six to ten machines simultaneously crunching code and experiments.

The real problem wasn't compute — it was collaboration. When teammates wanted to get involved, everything had to go through him personally. Peter referenced a phrase that gained traction this year: "meet proxy" — the idea that you become the sole interface between your team and the AI, endlessly ferrying messages between the two sides. That's exactly the pattern they wanted to break.

OpenClaw: An Open-Source Platform for Persistent Agents

OpenClaw^Ad (OC) is defined as an open-source platform for persistent agents, operating across tools, devices, and teams. Users can sign in with an existing subscription, and the platform automatically detects plugins — it can even see your Codex sessions.

The governance structure is worth noting: OpenClaw is open-source, owned by an independent nonprofit called the OpenClaw Foundation, with OpenAI providing support but holding no exclusive claim. Peter emphasized that his team at OpenAI is focused on exploring how to design useful agents, how to run them at scale, and "what an automated software engineer ultimately looks like."

His core argument is clear: models are advancing too fast, and our ways of working — the "harnesses" we wrap around agents — simply can't keep up. Workflows that made sense a year ago, or even six months ago, already feel cramped and outdated.

A note on terminology: A "persistent agent" is fundamentally different from a standard stateless AI call, where each request is independent and context vanishes when the session ends. Persistent agents have memory, identity, and state that carry across sessions, enabling them to maintain continuity across multiple tasks and operate autonomously for extended periods without human intervention. This is what makes long-horizon automations like Loops and Goals possible — an agent that autonomously merges 100 PRs over 18 days must remember what it has done, where it currently stands, and be able to resume work after a restart. The word "harness" in this context refers to the peripheral tooling wrapped around a core agent model — context management, tool-calling interfaces, task scheduling, error recovery, and so on. It's the critical infrastructure that translates model capability into reliable engineering behavior. Peter's key insight is that the model itself is improving far faster than this surrounding infrastructure, and that gap is the real bottleneck for agent adoption today.

Multiplayer Collaboration: Making Agent Sessions Visible to the Whole Team

The most striking part of the talk was a live multiplayer collaboration demo. Peter used voice to have an agent build a Frogger-style game, then shared a URL inviting the live audience to join the same server. In this mode, anyone could see each other's sessions — and even send prompts into someone else's session.

This reflects a deeper philosophical shift. Peter pointed out that teams used to collaborate through Pull Requests, but "that no longer feels like the future." When sessions are visible to the whole team, many conflicts can be avoided upstream — because you can see what instructions your teammates are giving the agent.

He also touched on a subtle human dynamic: how you talk to an agent turns out to be a surprisingly personal thing. He had tried asking people to attach sanitized conversation logs to their PRs, and almost no one was willing — including himself, sometimes. When sessions first became visible to the whole team, the awkwardness lasted only a day before it became the new normal — people started learning from each other and catching mistakes earlier.

He gave a concrete example: bleary-eyed one morning before coffee, he spotted a PR that had shrunk some tables — tables he had just made larger the day before. His cortisol spiked. But now he could click into that work session and see that his teammate Victor had actually reused his session, @-mentioned him, and ultimately made an improvement. The conflict was resolved by lunchtime.

From Dashboards to "Jellyware": Everything Is a Session

Peter showed off an array of apps living on the server: a dashboard tracking CI times, community analytics, an auto-generated "newspaper" called Daily Claw, and a self-deprecating "slop meter" — a tool that measures how much redundant code the agent has generated, reminding him to have the agent clean up periodically.

His reframing of what a "dashboard" really is was particularly interesting: most dashboards are just a session that produced an artifact, plus an automation that periodically refreshes that session, where the artifact contains code — so it's fundamentally software. But because the iteration speed is so extreme, he coined a new term: jellyware. Half-joking, the concept neatly captures the fluid, malleable nature of software in the AI era.

The server also integrates meeting functionality, using Luna to summarize meeting transcripts. Agents can automatically join Discord meetings, speak via GPT Live, answer questions about ongoing work, or spin off new tasks — because they operate under a single identity that represents the entire server and has full context of everything happening on it.

Loops and Goals: The Path to a "Software Factory"

Peter's broader vision is building "an agent that builds software for us" — a path he calls the "software factory." He distinguishes between two types of automation:

• Loop (continuous loop): Persistently running monitoring tasks. For example, a monitor that scans Discord, Twitter, and GitHub, categorizes different types of feedback, reads bug reports, spins up a test box to reproduce errors, proposes a fix, validates it, has another agent review it, and then automatically merges it. There's also a performance-monitoring loop that tracks each server release daily for regressions.
• Goal (target-driven task): Work oriented toward a defined end state. He cited an ongoing goal: gradually migrating the codebase from synchronous SQLite to asynchronous database access. This task has been running for 18 days on a local Codex instance and has merged over 100 PRs to date.

He admitted he had previously been running too many loops, scattered across various machines and hard to maintain, and is gradually migrating them to the team server so others can learn from them. His ultimate vision is an "agent pair project" — one with its own memory, automations, goals, and loops, where you simply issue high-level directives and it maintains and improves your software. The human contribution lies in "taste" — something hard to articulate and something you wouldn't want to hand over entirely to an agent.

Context note: The "software factory" vision has deep roots in software engineering's long-standing dream of a fully automated development pipeline, but before large language models it remained stuck at partial automation. In today's context, it refers to an end-to-end agentic system that can autonomously receive requirements, decompose tasks, write code, run tests, review output, and merge to main — with humans only setting top-level goals and providing "taste" calibration. The Loop/Goal distinction maps onto two control-theoretic modes: Loop corresponds to feedback control systems, continuously sensing environmental deviations and correcting for them; Goal corresponds to goal-directed planning, converging from an initial state toward a target state. Together they cover the full lifecycle of software maintenance — Loops handle live anomalies and continuous monitoring, while Goals drive long-cycle architectural migrations and feature development. Peter's point about human value residing in "taste" echoes a broad consensus in AI-assisted creation: high-level aesthetic judgment, priority tradeoffs, and edge-case identification remain dimensions where human contribution is currently irreplaceable.

OpenClaw Enterprise: A Security Foundation for Agent Deployment

As more teams adopt agents, "how to run, configure, and secure them at an organizational level" has become a new challenge. To address this, the team built and open-sourced the enterprise control plane OpenClaw Enterprise (OCE) on the day of the talk. Introduced by Kevin Lin, OCE brings multi-tenancy, governance mechanisms, and hard security boundaries to OpenClaw. Its security foundations include:

• Hard isolation between trusted and untrusted workloads: Deterministic code runs in separate containers or even separate clusters, preventing agents from tampering with their own runtime.
• Sandbox constraints: Controls over network access, writable files, and repositories an agent can push to — giving agents useful tools without granting access to everything.
• Model-based review (auto-review): Using a separate model to review agent behavior and intercept dangerous operations before they execute.
• Secure runtime and independent identity: Agents run under dedicated service accounts, existing as persistent entities rather than impersonating users — independently controllable, auditable, and shut-downable.

Kevin revealed that these controls are what enabled OpenAI's internal OpenClaw deployment to scale to over 400 "Claws." He demonstrated live how "presets" can quickly spin up agents pre-configured with security best practices — such as read-only repo access, Linear write access requiring team approval, and Slack integration. Another software agent named Cooper handles triage, reproduction, and end-to-end merging of a large volume of issues: Codex issues submitted over the past month were very likely processed by an OpenClaw agent.

Kevin drew an analogy between OCE and Kubernetes for agent deployment — a vendor-neutral open standard. OCE originated at OpenAI, was donated early to the OpenClaw Foundation, and is being co-developed with partners including Red Hat and NVIDIA.

On the Kubernetes analogy: The comparison is precise. Kubernetes solved a core problem: how to reliably orchestrate, isolate, and govern large numbers of containerized workloads in production, rather than leaving every team to figure out deployment on their own. OCE addresses a structurally identical problem — as the number of agents within an organization grows from a handful to hundreds, ad-hoc security configurations and manual governance no longer scale. You need a declarative, auditable control plane. "Multi-tenancy" means different teams' agents share infrastructure while remaining isolated from each other. "Independent identity" means agents run under dedicated service accounts rather than borrowing an engineer's permission token — critical for post-hoc auditing and the principle of least privilege. "Model-based review" (auto-review) is a notable meta-layer mechanism: using one model to supervise the executing model, forming a second line of defense at the tool-call level that compensates for the semantic blind spots of purely rule-based filters.

Closing: Open Source as Critical Infrastructure

Peter closed by returning to first principles: OpenClaw can use Codex at its foundation precisely because Codex is open-source. The team has also extended the open-source Codex project to bring AI capabilities to more people, and through "Hatch the Planet" they're working with teams like Trail of Bits to improve open-source security.

He called open source "critical infrastructure" and suggested that one of the ambitions of this whole effort is to patch an entire class of security vulnerabilities. The real message of the talk wasn't any specific feature — it was an open-ended question: in the age of agents, what workflows are we still doing "the old way" that could be completely reimagined and done better?