ACPX in Practice: Scaling AI Agent Deployment on Kubernetes for Automated PR Processing

Open Source Projects Drowning in PRs: The Maintenance Nightmare of 60,000+ PRs

Imagine maintaining an open source project that receives 300 to 500 PRs daily, with a total backlog exceeding 60,000. Many of these PRs are AI-generated, with vague descriptions and wildly varying code quality. You need to understand the intent of each one, assess implementation quality, check for conflicts, and ensure CI passes—all mechanical work that consumes enormous amounts of time. This is the real challenge faced by OpenCLO (an open source AI Agent framework).

With the proliferation of AI code generation tools like GitHub Copilot, Cursor, and Claude, mainstream open source projects are experiencing exponential growth in PR volume. GitHub's research data shows that AI-assisted code commits accounted for over 30% of platform activity in 2024. Maintainers of projects like the Linux kernel, React, and VS Code have all publicly expressed similar struggles: AI-generated PRs often lack context, ignore project conventions, or solve problems that don't exist. This trend has created a new dimension of "Maintainer Burnout"—it's no longer just about workload, but the cognitive burden of processing large volumes of low-quality contributions. The approach ACPX represents—"using AI to handle AI-generated content"—is emerging as a new paradigm for the open source community to address this challenge.

This article is based on a presentation by an OpenCLO maintainer at the AI Engineer conference, detailing how he built an automated PR processing Agent system using the ACP protocol, the ACPX workflow engine, and Kubernetes, while exploring future directions for enterprise-grade Agent orchestration.

From Discord-Driven Development to Multi-Agent Parallel Workflows

A One-Person Agent Factory

The speaker is a core maintainer of OpenCLO who began building AI programming toolchains months before ChatGPT was released. He initially built a coding assistant tool on Jupyter Lab using the DaVinci Code 2 model, which evolved into the current Agent system after multiple refactors.

His daily development workflow is quite unique: he opens 1 to 5 Agent channels simultaneously in Discord, each bound to a Codex session and communicating via the ACP protocol. He calls this "Discord-Driven Development" (or more precisely, "Telegram-Driven Development," since the abbreviation is TDD).

The core advantage of this approach is parallelization: when inspiration strikes, you can have different Agents working on different tasks across multiple channels simultaneously, turning weekend ideas into deliverable products. ACPX itself was built using this exact method.

The Difference Between ACP and MCP Protocols

Before diving into technical details, it's worth clarifying a common source of confusion. MCP (Model Context Protocol, proposed by Anthropic) provides models with tool-calling and context injection capabilities, focusing on interactions between a single model and external tools. ACP (Agent Communication Protocol, led by IBM Research) is an open protocol that standardizes Agent-client interactions, defining the complete interaction contract for how Agents, as independent entities, expose capabilities, accept tasks, and return results.

ACP's core abstraction is "Agent as a Service"—each Agent has standardized input/output interfaces, and clients (whether human users, IDEs, or other Agents) interact with them through the same protocol. This design allows Agents to be composed and swapped like microservices, without depending on specific model providers or runtime environments.

The speaker's reason for choosing ACP was practical: when he needed to build adapters for Codex and Cloud Code, only the Zed editor team had already built an ACP adapter. Different IDEs (VS Code, Cloud Code, Zed) each building their own plugins creates massive duplication of effort. ACP's philosophy is a unified interface—build once, use everywhere.

Currently, multiple competing standards exist in the Agent communication space: Agent-to-Agent Protocol for inter-Agent communication, and ACP Client Protocol for human-Agent interaction (though Agents can also use it to communicate with other Agents). In the long run, these protocols will gradually converge.

ACPX Workflow Engine: Encoding PR Processing as Standard Procedures

The Core Problem: Repetitive Mechanical Labor

Maintaining a large open source project like OpenCLO involves highly repetitive PR processing:

1. Understanding intent: Most PR descriptions are AI-generated, requiring follow-up questions like "What is this actually doing?"
2. Assessing implementation quality: "Is this the best approach?" The answer is usually no.
3. Processing feedback: Even if code quality is poor, the PR itself is a valuable user feedback data point.
4. Mechanical fixes: Resolving conflicts, passing CI, performing surface-level refactoring.

After observing project lead Peter's workflow, the speaker realized these steps could be fully programmatized. "You're automating the automator"—this was the motivation behind ACPX.

Workflow Design: Standard Operating Procedures (SOP)

ACPX is essentially an Agent-driven workflow engine that decomposes PR processing into standard operating procedures. Notably, ACPX's design philosophy sits between traditional workflow engines and pure Agent orchestration frameworks: traditional workflow engines (like Apache Airflow, Temporal) execute deterministic tasks based on predefined directed acyclic graphs (DAGs), while pure Agent orchestration frameworks (LangGraph, CrewAI, etc.) rely entirely on dynamic Agent decision-making. ACPX adopts a "deterministic skeleton + intelligent filling" hybrid architecture—the overall flow is a deterministic SOP, each step is completed by an Agent, and outputs are structured JSON for downstream programmatic processing. This approach is easier to debug and monitor in production environments because failure points can be traced to specific workflow nodes.

The specific flow includes:

• Intent recognition: Automatically analyzing the PR's purpose and context
• Implementation evaluation: Assessing code quality and solution soundness
• Conflict detection and resolution: Automatically handling merge conflicts
• Review-refactor loop: Performing shallow bug fixes and surface-level refactoring
• CI validation: Ensuring all checks pass
• Escalation mechanism: Handing back to humans when fundamental refactoring is needed

There's a key design principle here: running Agents in loops doesn't necessarily produce "code mud." The key is scoping—don't let Agents make design decisions; instead, have them discover and fix shallow bugs. Agents output structured JSON data, which is embedded into the workflow engine for programmatic decision-making.

Agent Orchestration on Kubernetes: From Personal to Enterprise-Grade Deployment

Why Agent Orchestration Needs Kubernetes

The speaker raised an important insight: there's a massive gap between personal Agents and enterprise Agents. In enterprise scenarios, Agents need to consume more inference resources, need to be created and destroyed on demand, and need isolated runtime environments.

Current chat platforms (Slack, Teams, Discord) have a fundamental limitation: creating one App gives you only one Agent instance. To create multiple Agents, you need to manually create multiple Apps with different names and avatars. This "multi-Agent configuration" approach doesn't scale.