Scaling Agents on Kubernetes with acpx and ACP

How do you use your preferred coding agent from Discord without another agent rewriting your instructions along the way? That integration problem sits inside a longer history of building agent harnesses. Onur Solmaz started with a JupyterLab extension over an early Codex model, then repeatedly rebuilt it into the harness used at his startup. After following Peter Steinberger’s Claude Code is My Computer, he installed OpenClaw in his company’s cluster, where coworkers could interact with it through Discord. Enterprise requirements led him to add Microsoft Teams integration and become an OpenClaw maintainer. His focus expanded to interoperability and orchestration, with security still a work in progress.

Chat-driven development initially involved a telephone game. Solmaz preferred the Codex harness for complex coding work, but from Discord he was asking Opus to tell Codex what to do. When he inspected the resulting Codex session, his instructions had been paraphrased. The work sometimes succeeded, but the extra interpretation was an uncontrolled transformation at a boundary where wording matters. His assessment of Opus concerned the version he was using then; he explicitly notes that the agents had since improved.

Direct channel binding made Discord function more like an IDE. Solmaz reports working with one to five agents across separate channels, with another channel reserved for testing OpenClaw’s ACP support. This made it practical to start and follow side projects while away from his desk. He built acpx through Discord itself: a channel connects to Codex through the Agent Client Protocol, or through the Codex App Server integration he credits to fellow maintainer Harold.

The PDF example exposes what channel binding does not solve. Before flying to London, Solmaz asked Codex to turn the ACP documentation into a PDF. Codex could create the file, but it did not understand the surrounding chat harness or how to deliver an attachment into Discord. He therefore asked it to save the PDF in a temporary location, then moved to another channel and asked the agent there to send it. Reaching an agent and delivering its artifacts are separate integration responsibilities.

ACP addresses the boundary between an agent and its client. The motivation is visible in editors: if each coding agent builds a separate plugin for each editor, much of the integration work repeats. Zed’s approach is to give those integrations a common interface, so clients do not have to reproduce the same machinery for every agent.

These categories do not prevent an agent from acting as an ACP client. An interface designed for a human-facing editor or chat client can also let one agent invoke another. Solmaz leaves room for supporting other protocols as they mature; ACP was his practical starting point because Zed already had the Codex and Claude Code adapters he needed. His comparison with Google concerns those adapters at the time of his choice, not Google’s participation in ACP.

OpenClaw’s command-line extension pattern suggested the next step: expose ACP through a CLI. That became acpx, allowing an agent with command execution to call another agent through the same standardized client boundary. It began as a way to invoke agents and expanded toward broader ACP tooling. The CLI is the accessible entry point; the protocol is what separates the caller from the particular harness being called.

Solmaz reports more than 60,000 total OpenClaw pull requests and roughly 300–500 opened per day on average at the time of the talk. These are his estimates of incoming work, not automated processing throughput. With many stakeholders requesting changes, the difficulty is not merely reviewing patches quickly: it is absorbing their needs without allowing every local fix to dictate the architecture.

The review starts by asking what a PR actually does, then whether it is the best available fix. An AI-generated description may not answer either question. A user can encounter a problem, ask their agent to fix it, and submit the result through GitHub without doing the reasoning a maintainer needs before merging. Further conversation with a coding agent can help unpack the implementation and alternatives.

Separate the evidence of a problem from the proposed implementation. A patch may be unmergeable while still identifying broken behavior that matters to a user. Categorizing that signal preserves it for future work. Solmaz shows Codex sessions making these judgments; after repeating the same questions and follow-ups, the procedure begins to look programmable. The next automation target is the maintainer’s repeated interaction with the agent.

The PR workflow breaks the work into explicit stages:

1. Identify the intent behind the incoming PR.
2. Judge whether the implementation fits that intent.
3. Resolve conflicts and address issues raised by review.
4. Repair failing CI before presenting the result to a maintainer.

The goal is to remove mechanical work from the maintainer’s queue where possible. It does not make every incoming patch suitable for merging.

Repeated review and refactor loops have a bounded role here. Solmaz argues that an unattended loop can uncover shallow bugs and make superficial repairs without being entrusted with architectural design. When the required change becomes a fundamental refactor, the workflow should relay it to a human. Conflict resolution and other routine operations become parts of an executable standard operating procedure.

In acpx, this takes the form of an n8n-like workflow engine driving a Codex session. The demonstration is a replay of one PR: the agent reproduces a bug, assesses the refactor, and enters a review loop that produces no further findings. Programmatic steps surround the agent’s work. The crucial connection is structured JSON output: a judgment becomes data that a workflow can inspect and use to choose its next step.

A small TypeScript routing function illustrates that boundary. Here the review result proposes a next action; it does not itself execute a repair or approve a merge.

type ReviewResult = {
  refactor: "none" | "superficial" | "fundamental";
  findings: string[];
};

type NextStep = "human-review" | "repair" | "continue";

function nextStep(review: ReviewResult): NextStep {
  if (review.refactor === "fundamental") return "human-review";
  if (review.refactor === "superficial" || review.findings.length > 0) {
    return "repair";
  }
  return "continue";
}

const review: ReviewResult = {
  refactor: "none",
  findings: [],
};

const proposedNextStep = nextStep(review);

This is the useful division of labor: the agent supplies a judgment, while ordinary code handles the branch. PR review is the demonstration, but the engine is presented as usable for other workflows built from agent turns and programmatic steps.

Once workflows can run without constant personal intervention, the scale of enterprise use may diverge from personal use. Solmaz expects organizations to consume substantially more inference, and sees commercial potential in that difference. His proposed operating model is on-demand, disposable agents: start an agent for a task, let it work, and avoid forcing every task through one persistent personal assistant.

Chat identity becomes an obstacle. In the integrations he describes, connecting an OpenClaw app to Slack, Teams, or Discord gives users one app identity. Giving another agent its own name, avatar, and separately addressable presence can require creating another app and manifest. Repeating that provisioning manually does not fit an agent-per-task workflow.

The slide’s multiple named agents illustrate the desired experience, not a working chat-platform feature: Solmaz used ChatGPT to generate the concept. Because his desired provisioning model was not supported, his implementation moves task-agent conversations into another UI. Those agents create and edit files, so the system must also keep their working state synchronized. The interface problem therefore leads directly to an infrastructure problem.

The proposed infrastructure has several distinct responsibilities:

• Orchestration: Kubernetes supplies the substrate for running task agents.
• Agent execution: OpenClaw, Codex, or Claude Code supplies the harness; ACP provides a common interaction boundary.
• Working data: Repository read/write access lets agents act on code, while synchronization keeps files and state available where needed.

Solmaz mentions GitHub, rsync, and Dropbox-like synchronization as possible ingredients. He does not specify a single implemented synchronization algorithm in this part of the talk.

The orchestrator he introduces comes from his TextCortex work, outside OpenClaw. A Go operator handles the provisioning complexity. Consider his example of a shared Slack concierge serving 100 employees: one conversational entry point can become a bottleneck, so a new task should be able to get a separate agent. The concierge creates that agent and returns a website link where the user can continue. Solmaz acknowledges Cognition and Devin as precedents for this category of developer-agent experience.

The project is TextCortex Spritz, and the demonstrated use case is error reporting. A user asks in Slack about new bugs after a production release, then asks for an agent to investigate. Slack is the starting point; the new agent’s conversation moves into a separate web interface because Solmaz cannot provision the desired agent presence directly inside Slack.

The web UI is an open-source React app hosted in the same cluster where the Helm charts are deployed. Opening the task starts a conversation in that interface, and the agent begins working on the problem. The selected frame shows an error report and a debugging response with root-cause, fix, and verification details. The experience resembles Codex Web or Devin, but the task runs in a full Kubernetes pod.

Solmaz acknowledges that this can be wasteful. His reason for choosing it is the flexibility of giving an agent a full computer-like environment, a capability he sees demonstrated by OpenClaw. He tentatively mentions OpenHands and Firecracker while acknowledging limited familiarity with virtualization options; that is not a settled comparison of runtime architectures. His concrete claim is narrower: he has a working product running on Kubernetes.

The intended deployments include internal web access to Codex and separate agents for individual tasks. Solmaz also offers setup help to open-source projects receiving hundreds of issues per day; that is an adoption target, not a demonstrated processing rate. The product handles the surrounding Slack integration, agent lifecycle, and user interaction, while ACP abstracts access to the agent so the harness can be switched. The final distinction matters: this orchestration and deployment demonstration is his TextCortex work, separate from his contributions to OpenClaw.