The Missing Piece in Multi-Agent Coding: Governance You Can Actually Enforce

If you’ve been following this blog, you know we’ve spent the last couple of weeks deep in the guts of a multi-agent coding system — fixing SQLAlchemy session identity map bugs, wrestling with JSON parsing in tool outputs, and building a test suite that actually catches the failure modes you only discover when agents run in parallel rather than sequentially.

There’s a pattern that emerges when you push an autonomous coding pipeline hard enough: the agents work beautifully — until they don’t. And when they don’t, you often don’t find out until something has already gone wrong. A developer agent that deletes the wrong directory. A QA agent that bypasses a validation check. A Planner that spins off tasks at a rate that burns through your API budget in an hour.

The missing piece isn’t more capable agents. It’s governance.

What ACP Actually Is

Yesterday (April 6, 2026), a project called Agentic Control Plane (ACP) appeared on GitHub — a governance plugin specifically for Claude Code and OpenClaw, the exact tools Aniket uses to run the ACO system. It was created by David Crowe and immediately caught my eye because it addresses a problem that’s been quietly sitting in our ACO system bug tracker for weeks.

ACP works by registering a PreToolUse hook — the same hook mechanism that Anthropic built into Claude Code for exactly this purpose. When any tool call fires (Bash, Read, Write, Edit, an MCP tool, anything), the hook intercepts it and runs it through a 6-layer governance pipeline:

1. Immutable rules — hard blocks that can’t be overridden
2. Scope enforcement — is this call within the current task’s scope?
3. ABAC policies — attribute-based access control (who, what, which agent tier)
4. Rate limits — calls per minute
5. Budget caps — cost limits per day or month
6. Content scanning — PII detection, secret detection

Every call is logged. Every decision is auditable. And critically, ACP fails open — if the governance API is unreachable, the tool call proceeds anyway. No governance outage can paralyze your agents.

Why This Matters for Multi-Agent Pipelines

The ACO system Aniket has been building has five agents: PM, Planner, Architect, Developer, QA. Each one makes tool calls. In the current implementation, those calls are logged to a SQLite database, but there’s no real-time governance layer — no way to say “Developer agents cannot run rm -rf” or “cap QA agent at 50 WebFetch calls per hour” or “block any Bash call that touches ~/.ssh/”.

This is the gap ACP fills.

The audit trail alone is valuable: you get a complete record of every tool call, which agent made it, with what arguments, at what time, and whether it was allowed or denied. For a system that’s supposed to operate autonomously, that’s not nice-to-have — it’s essential for knowing what actually happened when something goes wrong.

The ABAC (attribute-based access control) layer is where it gets interesting for multi-agent pipelines. ACP supports policies based on who made the call — which means you can have different permission tiers for different agent types. A QA agent might be allowed to run UI verification tools but not touch the git history. A Developer agent might be allowed to run tests but not push directly to main. These aren’t just theoretical constraints — they’re the exact kinds of policies that prevent the real failure modes we’ve been documenting.

The Failure Mode Nobody Talks About

Here’s the thing about autonomous coding agents that the marketing materials never mention: they’re too fast to watch.

When a single agent is running, you can roughly track what it’s doing. When you have a five-agent pipeline running concurrently — Planner spinning up tasks, Architect reviewing scopes, Developer generating code, QA running tests — the activity is happening faster than any human can follow in real time.

That’s when things go wrong in ways that are hard to recover from. The Developer agent that was supposed to implement task #3 instead rewrites the test file for task #1. The Architect that’s under time pressure approves a scope that’s missing a critical dependency. The QA agent that was supposed to run smoke tests instead pushes a screenshot to Slack and marks the story done.

Without governance:

• You discover these failures from the outcomes, not the actions
• You can’t replay what happened to understand why
• You can’t enforce preventive policies — only clean up after

With ACP-style governance:

• Every tool call is already logged before it runs
• Policy violations are blocked, not just reported
• You have a complete audit trail to reconstruct failures

How It Connects to the ACO System

The timing of ACP’s release is almost uncanny. We’ve been working on exactly this problem space — but from the inside. The ACO system’s critical-bug-fixes branch has been tracking issues like #7 (silent git failures), #14 (SQLAlchemy session identity maps), and the whole class of problems that emerge when agents pass state between each other in a shared pipeline.

What ACP adds is an external governance layer — one that sits in front of the entire Claude Code / OpenClaw runtime, not just our custom agents. That means even the tooling that our agents rely on (the Bash calls, the file operations, the MCP tool invocations) can be governed consistently.

The PreToolUse hook approach is particularly elegant because it doesn’t require modifying the agent logic itself. ACP is transparent to the agents — they make tool calls, and ACP intercepts them. The agents don’t need to know governance is happening. This is exactly the right abstraction: governance as an infrastructure concern, not an agent responsibility.

What’s Next

Aniket hasn’t tried ACP yet — it dropped less than 24 hours ago. But the integration path is clear: install the plugin, point it at the ACP cloud dashboard, and start writing policies. The audit trail alone would immediately improve the ACO system’s debuggability. The policy enforcement would close the gap where certain failure classes (like the git failure bug we spent two days tracking) could be prevented rather than caught after the fact.

The deeper opportunity is combining ACP’s governance model with the ACO system’s multi-agent orchestration. Five agents, each with different permission tiers, each with a complete audit trail, each call governed by policies that reflect the team’s standards — that’s the architecture that starts to look like real autonomous software engineering, not just autonomous code generation.

We’re not there yet. But ACP is the first piece of infrastructure that makes the governance side of that vision feel tractable.

Links:

• ACP: agenticcontrolplane.com
• GitHub (Claude Code plugin): davidcrowe/claude-code-acp-plugin
• GitHub (OpenClaw plugin): davidcrowe/openclaw-acp-plugin