ACP: The AI Agent Escape Hatch

The Walled Garden Problem

Modern AI agents are powerful — but deliberately caged.

Tools like NemoClaw run AI subagents inside sandboxes: isolated environments where internet access is blocked, your local files are untouchable, and nothing persists between sessions. This is great for security. It's terrible when you actually need your AI to do things.

That's where ACP — the Agent Control Plane — comes in.

What Is ACP, Really?

ACP stands for Agent Control Plane. It's not a feature inside your sandbox. It's an architectural layer that runs outside it — on your actual host machine.

Think of it as a supervisor that lives in the real world, while your main agent is locked in a glass box. When the glass-box agent hits a wall, it calls the supervisor. The supervisor steps out, does the work, and hands back the result.

Here's the key difference in plain terms:

Why Does This Exist?

Sandboxed agents — like NemoClaw's main subagent — simply cannot:

• Listen for Slack events or respond in threads
• Access your local project files directly
• Run long background processes
• Browse the web on your behalf

These aren't bugs. They're design decisions. Sandboxes exist to contain risk.

But real workflows need more. ACP is the sanctioned way to break out of those constraints — not by breaking security, but by routing work to an agent that was designed to run with more power.

The Architecture (Visualized)

┌──────────────────────────────────────────┐
│  YOUR MAC (Host)                         │
│  ┌──────────────────────────────────┐    │
│  │  OpenClaw Gateway                │    │
│  │  ┌──────────┐  ┌──────────────┐ │    │
│  │  │  ACPX    │  │  ACP Agents  │ │    │
│  │  │  Plugin  │  │  (codex,     │ │    │
│  │  │          │  │   claude)    │ │    │
│  │  └──────────┘  └──────────────┘ │    │
│  └──────────────────────────────────┘    │
│               │                          │
│  ┌────────────┴─────────────────────┐    │
│  │  NemoClaw Sandbox                │    │
│  │  ┌──────────────────────────┐    │    │
│  │  │  Subagent "main"         │◄───┼────┤
│  │  │  (asks ACP for help)     │    │    │
│  │  └──────────────────────────┘    │    │
│  └──────────────────────────────────┘    │
└──────────────────────────────────────────┘

The flow looks like this:

1. You ask your main agent to do something complex
2. main recognises it can't do this alone
3. main sends a request to the host gateway
4. The gateway spawns an ACP agent (like codex or claude)
5. The ACP agent does the work — browses, edits files, runs scripts
6. Results flow back to main

Simple. Elegant. Powerful.

The Catch (There's Always a Catch)

NemoClaw sandboxes block ACP dispatch by default. For security reasons, a sandboxed agent can't just call out to the host whenever it wants.

This means:

• The ACPX plugin may be loaded inside your sandbox
• But it does nothing unless the host OpenClaw gateway is running
• Config changes inside the sandbox don't affect ACP — you must configure it on the host before the sandbox starts

This trips up a lot of people. The plugin looks installed. The commands seem to work. But nothing actually happens.

How to Get ACP Working: Three Paths

Option 1 — Run ACP Agents Directly on Your Host

# On your Mac (not in sandbox)
openclaw gateway

This starts the host gateway with ACP support. Your sandbox can then dispatch to it.

Option 2 — Install the Real OpenClaw CLI

If your openclaw binary is actually NemoClaw (common after default installs), you need the standalone CLI:

npm install -g @openclaw/cli
openclaw plugins install @openclaw/acpx
openclaw config set acp.enabled true
openclaw gateway

Option 3 — Check If It's Already Working

Some NemoClaw versions include ACP passthrough in the sandbox gateway. Run this from inside your sandbox:

/acp doctor

If it returns healthy, you're already set. Just configure your agents and go.

The Broader Lesson for AI Engineers

ACP represents a broader design philosophy worth understanding:

Containment + Escape Hatch = Practical Security

You don't give all agents all powers. You give minimal-trust agents minimal access, and you provide a well-defined channel for escalating to more capable agents when needed.

This is the same thinking behind: - Docker containers that call external APIs - Lambda functions invoking step functions - Browser extensions messaging native apps

It's not a new idea. Applied to AI agents, it's just new enough to feel like magic.

Quick Reference

ACP Agent  →  Runs on host, full access, persistent
Subagent   →  Runs in sandbox, isolated, ephemeral
ACPX       →  Plugin that connects the two
Gateway    →  The host-side listener that routes requests

Final Thought

The most capable AI setups aren't the ones with the most powerful single agent. They're the ones with the smartest architecture — knowing which agent should handle what, and how they talk to each other.

ACP is how you bridge the isolated and the capable. Once you understand it, building robust multi-agent workflows gets a lot cleaner.

Have questions about multi-agent architecture or ACP setup? Drop them in the comments.