Scaling Agents on Kubernetes with acpx and ACP — Onur Solmaz, OpenClaw
Onur Solmaz from OpenClaw discusses the challenge of managing 300-500 daily, often AI-generated, pull requests. He introduces ACPX, a headless CLI for the Agent Client Protocol (ACP), designed to automate PR triage through a node-based workflow. The talk culminates in a vision for on-demand, disposable agent pods on Kubernetes, managed by a Go operator that provisions and tears down full compute environments per task, wiring them into chat platforms like Slack.
Onur Solmaz, a founding engineer and maintainer at OpenClaw, has been focusing on agent interoperability and orchestration to manage the project’s massive scale and accelerate enterprise adoption.
The Challenge: Managing High-Volume, AI-Generated Pull Requests
OpenClaw faces a significant challenge with a “firehose” of contributions, receiving 300 to 500 pull requests (PRs) per day, totaling over 60,000. A large portion of these are AI-generated, often of low quality (“slop”), and not directly mergeable. However, each PR represents a crucial signal—feedback from a user about a broken part of the codebase. The core problem is how to absorb, balance, and categorize the needs of tens of thousands of stakeholders without creating an overly complex system.
The manual review process is mechanical and repetitive. For each PR, a maintainer must:
- Determine the author’s intent.
- Assess if it’s the best possible fix.
- Judge the implementation quality.
- Check for and resolve conflicts.
- Ensure CI/CD checks pass.
This workflow is ripe for automation, leading to the development of tools to “automate the automator.”
From Discord-Driven Development to a Standardized Protocol
Initial attempts at automation involved “Telegram Driven Development” (TDD), using agents like Opus in Discord to interact with a Codex harness. This created a “telephone game” where instructions were paraphrased between agents, leading to unreliable results. This highlighted the need for a more structured communication method.
The solution came in the form of the Agent Client Protocol (ACP). Unlike agent-to-agent protocols, ACP standardizes the interaction between an agent and a client (e.g., a human user or an IDE). It was chosen for its existing adapters for tools like Codex and Zed’s editor, which helped avoid duplicated effort in building separate plugins for different platforms like VS Code. ACP provides a standardized interface to build upon once and ship everywhere.
ACPX: A CLI and Workflow Engine for ACP
To leverage ACP programmatically, Solmaz built acpx, a headless command-line interface (CLI) for the protocol. acpx acts as a “Swiss Army knife” for ACP, enabling one agent to call another from the command line.
More importantly, acpx evolved into a workflow engine, similar to n8n, that drives an agent session through a predefined, node-based graph. This allows for the creation of Standard Operating Procedures (SOPs) for agents to follow when processing PRs.
The workflow automates the entire triage process:
- Reproduce the Bug: Programmatically verify the issue the PR claims to fix.
- Judge Implementation: Assess the quality of the proposed solution.
- Review and Refactor: Run automated review loops to catch shallow bugs and perform superficial refactors. The system can distinguish between minor fixes and issues requiring fundamental, human-led refactoring.
- Check for Conflicts: Automatically handle merge conflicts.
- Emit Structured Data: The final output is a structured JSON object, making the results easy to integrate into other automated systems.
The Vision: On-Demand, Disposable Agents on Kubernetes
Looking beyond PR triage, the talk explores the future of enterprise agents. A key concept is the use of on-demand, disposable agents. For each specific task, a new, fully independent agent is provisioned in its own isolated environment.
Current chat platforms like Slack or MS Teams present a bottleneck. Creating a new agent with a unique identity requires manually creating a new app manifest, which is not scalable. The ideal platform would support programmatic, cosmetic provisioning of multiple agents under a single underlying application.
Until chat platforms support this, the solution is to orchestrate these disposable agents using Kubernetes. The proposed architecture includes:
- Kubernetes as the orchestration layer.
- An agent harness like OpenClaw or Codex.
- A Go operator to manage the lifecycle of agent pods.
Practical Implementation: The Spritz Operator
This vision is realized through Spritz, an open-source Go operator developed at TextCortex. This operator handles the complex parts of provisioning and managing agent environments.
When a task arises (e.g., a bug report in a Slack channel), a user can ask a “concierge” agent to dispatch a new agent to handle it. The Spritz operator then:
- Spins up a new, dedicated Kubernetes pod for the task. This gives the agent a full, isolated compute environment, similar to how OpenAI uses Firecracker.
- Wires the agent into a dedicated UI (since direct multi-agent integration in Slack isn’t yet possible).
- The agent works on the problem, with its progress visible in the UI.
- Once the task is complete, the entire environment is torn down.
This model provides a powerful, scalable, and secure way to apply AI agents to complex problems like triaging bug reports and processing high-volume code contributions, effectively taking the human out of the loop for repetitive, mechanical work.