What is an Agentic Control Plane?

An Agentic Control Plane is a governance layer that sits between AI coding agents and their tools. It logs every tool call, enforces permissions and policies, and provides audit trails — giving teams visibility and control over what their AI agents are doing.

How does ACP work with Claude Code?

ACP installs a PreToolUse hook in Claude Code that fires before every tool call (Bash, Read, Write, Edit, WebFetch). The hook sends the tool name and input to ACP's governance API for policy evaluation and audit logging. Round-trip is approximately 200ms.

How do I install ACP?

Run one command: curl -sf https://agenticcontrolplane.com/install.sh | bash. This auto-detects Claude Code and OpenClaw, installs the appropriate hooks, and opens your browser to set up your workspace.

Governance for Zed Parallel Agents

Zed shipped Parallel Agents on April 22, 2026 — “multiple agent threads at once, each working independently with its own agent, context window, and conversation history” (Zed docs). Threads live in a sidebar grouped by project; each thread can run Zed’s built-in agent or an external agent (Claude Agent, Gemini CLI, Codex CLI). Open source, fast, genuinely good UX for multi-project agentic engineering.

This page is the honest read on governance for Zed’s new surface: what Zed gives you natively, what’s missing when agents go parallel, and how ACP plugs in at the LLM layer.

TL;DR. Zed’s folder-and-repo scoping per thread is solid filesystem governance. What it doesn’t cover: cross-thread audit (what has my IDE actually done today, across all threads?), per-agent policy beyond filesystem (e.g. which APIs each thread’s agent can call), and rate-limit / budget cascade when one thread fires hundreds of tool calls in parallel. ACP adds those by intercepting at the LLM-provider boundary — no Zed plugin required.

What Zed provides natively

Zed’s Threads Sidebar is a real governance surface, not a UX afterthought:

Per-thread folder scoping — the sidebar lets you “control exactly which folders and repositories agents can access” (Zed docs). For multi-folder work, select multiple folders; for isolation against concurrent edits, start a thread in a new Git worktree.
Agent choice per thread — “Each thread can use a different agent, so you can run Zed’s built-in agent in one thread and an external agent like Claude Code or Codex in another.”
Thread lifecycle controls — new (cmd-alt-t), stop (double-enter or stop button), archive (shift-backspace), restore / delete from Thread History (cmd-g).
Open source — you can read the code, audit it, fork it.

For a single-developer IDE, this is already ahead of most agent tools. Filesystem scoping is the thing that matters most in a coding agent, and Zed does it well.

Where parallel agents change the governance surface

“Parallel” is the word that matters. One agent running in one window is easy to understand. N agents running in N threads, each spawning subagent actions, all landing tool calls against your filesystem, your git remotes, your LLM provider at once — that’s a different shape.

What Zed’s native controls don’t cover:

Cross-thread audit. The sidebar shows what each thread is doing. There’s no unified log of “here’s every tool call every thread made today, sorted by time.” If three threads ran in parallel and one of them edited a secrets file you didn’t notice, reconstruction depends on per-thread scrollback.
Cross-thread policy. Folder scoping is per-thread. But “don’t let ANY thread run rm -rf” or “block all HTTP POSTs to external domains from any agent” is a cross-thread property — and has to live outside the editor to hold across threads.
Rate-limit and cost cascade. Parallel agents mean parallel LLM calls. Four threads running at once, each with a 50-turn conversation, each calling 5 tools per turn, is 1,000 tool calls an hour. Without a per-user or per-workspace ceiling, an accidental infinite-loop in one agent becomes a real bill (or a real API rate-limit hit on the downstream provider).
Provenance for subagent delegations. If a Zed agent uses its own tools to spawn another agent (e.g., via an MCP-backed sub-agent tool), the chain isn’t recorded as a chain — it shows up as independent calls.
PII and secret scanning on agent outputs. The agent reads a file, summarizes it in chat, sends it upstream. If the file had an API key in it, the key is now in your LLM provider’s logs.

These gaps are structural, not Zed-specific. Any IDE-resident agent system will face them as soon as agents go parallel.

How ACP fits

The cleanest integration is at the LLM provider boundary, not as a Zed plugin. Zed lets you configure the base URL of your AI provider — point it at ACP:

Anthropic (Claude)

In your Zed settings (settings.json via the command palette → “Open Settings”):

{
  "language_models": {
    "anthropic": {
      "api_url": "https://api.agenticcontrolplane.com/anthropic"
    }
  }
}

The default api_url is https://api.anthropic.com and Zed’s client appends /v1/messages itself — so your ACP gateway needs to respond at /anthropic/v1/messages, which it does.

Set ANTHROPIC_API_KEY in your environment to your ACP API key (gsk_...). Every LLM round-trip from every Zed thread now flows through ACP — audit, policy, rate limits, PII scanning on outputs, cross-thread visibility in one place.

OpenAI / OpenAI-compatible

{
  "language_models": {
    "openai": {
      "api_url": "https://api.agenticcontrolplane.com/v1"
    }
  }
}

Same shape. ACP’s OpenAI-compatible proxy captures the full request envelope — messages, tool definitions, handoff metadata — on every LLM round-trip. Scored 45/48 on AgentGovBench under the Proxy integration pattern, the highest structural ceiling of the four interception patterns.

What you get after pointing the provider

Unified activity log across all threads, all agents, all projects. Sortable by time, filterable by tool and decision.
Cross-thread policy — “deny any tool call that hits a file outside git-tracked paths” applies to every thread, not just one.
Rate limit and cost caps — per-user, per-workspace, or per-model.
PII/secret scan on tool outputs — before content goes back to the LLM, scrub it.

Zed doesn’t currently document an outbound header for attribution back to the thread name, so audit today attributes to the user who minted the ACP key, not the specific Zed thread. Per-thread attribution would require upstream support we’re tracking.

Install:

curl -sf https://agenticcontrolplane.com/install.sh | bash

The installer detects Zed, writes the provider config, and sets your environment. Restart Zed.

What’s still open

Zed supports MCP natively under the config key context_servers (Zed MCP docs) — remote servers with url + headers are supported, and per-tool permissions can be set to confirm / allow / deny. When a Zed agent calls a tool via MCP, ACP can run as the MCP server — the same pattern as Cursor.

What’s not documented: a PreToolUse/PostToolUse hook at the Zed layer. Zed’s external-agents page explicitly notes that for Claude Agent, “agent teams and hooks are currently not supported.” Until Zed exposes a hook surface, the LLM-proxy path above is the stronger pattern for full-surface governance — every model call routes through ACP regardless of which tool the agent reaches for next.