Scaling Agents on Kubernetes with acpx and ACP

Onur Solmaz, OpenClaw19:00 · May 2026 · 5,347 views
Thumbnail for Scaling Agents on Kubernetes with acpx and ACP Watch on YouTube
TL;DR
  1. 1

    acpx gives agents a command-line interface built on the Agent Client Protocol, so tools such as Codex can be driven through structured agent-to-client communication instead of PTY scraping.

  2. 2

    OpenClaw's large volume of AI-generated pull requests can be processed through workflows that reproduce bugs, judge implementations, resolve conflicts, run review loops, and emit structured JSON before a human sees the change.

  3. 3

    Disposable Kubernetes agent pods can give each task its own compute environment, connect the work to Slack or another interface, and disappear when the task is finished.

Summary

Onur Solmaz describes how he moved from relaying instructions between OpenClaw and Codex to running several coding agents from Discord. The foundation is acpx, a CLI for the Agent Client Protocol, which standardizes communication between a client and an agent. Solmaz uses it to drive Codex sessions and to turn repeated pull request checks into a workflow. The workflow asks what a PR does, judges whether the implementation is appropriate, checks conflicts, runs review and refactor loops, and returns structured JSON. He treats poor AI-generated PRs as useful reports about problems in the codebase, even when they cannot be merged. The final part presents a separate Kubernetes-based orchestrator from his work at TextCortex. It provisions a complete pod for each task, connects the agent to a web interface and Slack-related workflows, synchronizes state, and removes the environment afterward. Solmaz argues that agents need isolated computers and better multi-agent provisioning across chat platforms.

Key ideas
03:07

Discord can become a front end for several coding agents

Solmaz describes using Discord channels as parallel workspaces for Codex and other agents. He usually has one to five channels open, with one agent attached to each task. This lets him work on side projects while traveling, moving from an idea to an implementation without sitting at a traditional IDE. He built the setup by binding a Discord channel to Codex through ACP. The arrangement is imperfect. For example, Codex cannot directly send a generated PDF back through Discord, so Solmaz has to use another channel to request the file. He presents this as a practical developer tool that works despite rough edges.

05:14

ACP standardizes communication between clients and agents

Solmaz distinguishes ACP from MCP. MCP gives models tools, while ACP standardizes interaction between an agent and its client. He credits Zed with developing the protocol and points out that editors and coding products otherwise need separate integrations for Codex, Claude Code, and similar systems. ACP reduces that duplicated plugin work by giving clients and agents one interface. He also distinguishes agent-to-agent protocols from ACP, which is intended for a human client talking to an agent. Solmaz chose ACP because adapters for Codex and Claude Code were available when he needed them.

06:48

acpx began as a command-line bridge for any agent

After deciding to add ACP functionality to OpenClaw through a CLI, Solmaz started building acpx. Its initial purpose was simple: let one agent call another agent over the command line. He describes it as gradually becoming a general-purpose tool for ACP. The motivation came from his earlier workflow, where he told OpenClaw to tell Codex what to do. That relay introduced uncertainty because wording affects agent behavior. Directly binding a client channel to Codex through ACP removed part of that telephone-game problem.

07:15

AI-generated pull requests are still reports about broken code

OpenClaw receives 300 to 500 open pull requests on an average day, on top of more than 60,000 total pull requests. Solmaz says most are AI generated and most are not mergeable. He does not treat them as items to merge or discard immediately. Instead, he asks an agent what the PR does and whether it is the best possible fix. Even a poor patch can show that a user encountered a problem in the codebase. The repository needs a way to categorize that signal and absorb useful information without accepting the generated code as-is.

09:35

A pull request workflow can remove repetitive checks before human review

Solmaz turns the repeated PR examination into an abstract workflow. A task enters with the pull request, then the system finds its intent, judges the implementation, checks for conflicts, handles review comments, and gets CI passing where possible. He also uses review, refactor, and review-again loops. He argues that repeated agent runs are reasonable when they look for shallow bugs or make superficial fixes, while fundamental refactors should be sent to a human. The workflow is implemented in acpx as an engine that drives a Codex session and emits structured JSON for later workflow steps.

12:32

Disposable agents need isolated compute and task-specific state

Solmaz expects people to start one agent per task rather than keep one personal agent handling everything. Each agent may create files, edit code, and maintain state that needs synchronization. His proposed setup includes Kubernetes, an agent harness such as OpenClaw, Codex, or Claude Code, read and write access, and a mechanism such as rsync for synchronizing data. The goal is to provision an agent when work arrives, give it an isolated environment, and connect it to the user's normal tools without manually creating a new chat application for every agent.

16:00

The TextCortex orchestrator provisions a full Kubernetes pod per task

In the final demo, Solmaz shows an open-source orchestrator he works on at TextCortex. Their use case is error reporting. A user can ask from Slack for an agent to investigate a problem after a production release, then the system creates a task-specific environment. Because chat platforms do not yet support easy provisioning of multiple separate agent identities, the conversation moves to a web UI hosted in the cluster. The agent runs in a full Kubernetes pod rather than a narrower process. Solmaz calls this wasteful, but says giving an agent a full computer is a more powerful abstraction. The orchestrator handles the wiring, keeps agents running, and leaves the agent implementation replaceable through ACP.

"Wasteful, but I think it's the better abstraction because when you give a full computer to an agent, it's a lot more powerful."16:36
Who should watch
  • You are building a developer workflow around Codex, Claude Code, or OpenClaw and need a client interface that does not depend on a specific editor plugin.
  • Your repository receives more pull requests or bug reports than people can inspect manually, especially when many submissions are AI generated.
  • You want each agent task to get an isolated environment on Kubernetes and need to connect those environments to chat or web interfaces.