Back to Podcast Digest
AI Engineer19m

Scaling Agents on Kubernetes with acpx and ACP — Onur Solmaz, OpenClaw

TL;DR

  • Onur Solmaz built a Discord-native coding workflow that now runs 1–5 agents in parallel — he started with a hacked-together “telephone game” between Claude/Opus and Codex, then evolved it into channel-bound ACP connections so he can code, test, and ship side projects from Discord.

  • ACP is his bet on agent interoperability because it standardizes human↔agent interaction, not tools — unlike MCP, which gives models tools, ACP lets clients like Zed, Codex, and Claude Code avoid rebuilding the same plugin stack over and over.

  • acpx began as a CLI shim and is turning into a workflow engine for PR triage at OpenClaw scale — Solmaz says OpenClaw sees 60K+ PRs total and 300–500 new/open PRs per day, so the real challenge is absorbing user feedback without drowning in AI-generated sludge.

  • His core idea is to automate the maintainer’s mechanical judgment loop, not the deep design work — acpx reproduces bugs, checks intent, judges implementation, resolves conflicts, runs review/refactor loops, and escalates to a human only when a change needs fundamental redesign.

  • He argues enterprise agents will diverge sharply from personal agents because they justify far more inference spend — that’s why he’s excited about disposable, on-demand agents per task, each with its own workspace, state sync, and harness running on Kubernetes.

  • At TextCortex, he’s already building that abstraction as an open-source Kubernetes orchestrator — the project spins up full pod-backed agents from Slack or a web UI for jobs like debugging post-release errors, while keeping the underlying model/harness interchangeable through ACP.

The Breakdown

From early Codex hacks to Discord-driven development

Solmaz opens with a very builder-coded origin story: he’s been making coding harnesses since before ChatGPT, starting with a JupyterLab extension over the old Codex model. He describes that harness as a “ship of Theseus” that’s been ripped apart and rebuilt so many times it barely resembles the original. His OpenClaw obsession goes back to the first Claude bot in Discord, when he installed it in his company’s cluster the next day and immediately saw coworkers’ minds get blown.

The awkward “telephone game” that pushed him toward ACP

Early on, he wanted Codex inside Discord, but the setup was clumsy: he’d ask Opus to tell Codex what to do, then inspect the Codex session and hope the paraphrasing didn’t ruin the prompt. It worked just enough to prove the need. Now he binds Discord channels directly to agents through ACP, effectively running a lightweight IDE in chat with parallel channels like Codex 1–5 and OpenClaw instances for testing.

Why ACP, not MCP, became the foundation

He makes the distinction cleanly: MCP is about giving tools to the model, while ACP is about standardizing the interaction between a client and an agent. He credits Zed’s push here — if Codex on VS Code and Claude Code all build separate integrations, that’s duplicated work that a protocol should eliminate. He chose ACP pragmatically because it already had adapters for Codex and Claude Code when he needed them.

acpx: a CLI that became a Swiss Army knife

What started as “let an agent call another agent over the command line” turned into acpx, a broader CLI and workflow engine for ACP. The pain point came from OpenClaw’s maintainer reality: with 60K+ PRs overall and roughly 300–500 open per day, maintainers are flooded with half-baked AI-generated fixes that they can’t merge, but also can’t ignore because they contain useful signals. Solmaz frames this as a categorization problem — extract intent, judge the implementation, and preserve the user feedback without letting the repo turn into slop.

Automating the maintainer’s repetitive review loop

He walks through the pattern maintainers already do manually: ask what a PR does, whether it’s the best fix, whether CI passes, whether conflicts are resolved, and what review comments still need attention. acpx encodes that into a workflow with structured outputs, replayable steps, and “review/refactor loops” aimed at shallow bugs and mechanical cleanup rather than open-ended design. His framing is memorable: this is “automating the automator,” or turning standard operating procedures for agents into executable workflows.

Agents as infrastructure: Kubernetes, disposable workers, and enterprise scale

The back half widens from OpenClaw into Solmaz’s day job at TextCortex, where he’s building an open-source Kubernetes orchestrator for disposable agents. His thesis is that enterprise agents will consume far more inference than personal agents, so the useful abstraction is one agent per task, each with its own state, files, and compute. Today chat platforms don’t really support clean multi-agent provisioning in Slack or Teams, so his system routes from Slack into a separate web UI, where a request like “debug new bugs after prod release” can spawn a full pod-backed Codex-style session running in Kubernetes.

A practical pitch: open source infra, no lock-in

He demos the setup as a concierge flow: ask in Slack, dispatch an agent, then continue the work in a cluster-hosted React UI tied to the pod. He admits the full-computer-per-agent approach is “wasteful,” but says open-source proved how much more capable agents become when you give them a real machine. The closing pitch is straightforward: if you have an internal deployment or an open-source project drowning in hundreds of issues per day, he can help wire up agent orchestration around Slack, Kubernetes, and ACP so you’re not locked to one vendor or one agent stack.

Share