Back to Research

Why agentic coding governance beats raw speed

Agentic coding governance beats speed: connector cards, child receipts, decision stubs, and scope ledgers that make agent diffs defensible after merge.

The ruins of the Khan's tomb and a small minaret in Bolgar, Shishkin (2022-12-06), landscape painting by Ivan Shishkin.
Rogier MullerMay 15, 20265 min read

Governance beats speed because a fast change you cannot explain stops being an asset the moment someone has to defend it. Agentic coding governance is the small set of written contracts, scopes, receipts, and review gates that make agent-produced changes traceable after merge. The expensive bug here is rarely slow output. It is permission drift nobody signed for, the kind that only surfaces during an incident review when "why did the agent touch this file?" has no answer outside a chat log.

Most teams reach for governance after the second or third merge they could not explain. You can skip that lesson. The four artifacts below are cheap to add, and each one answers a question a reviewer would otherwise ask too late.

Write a scope ledger before you delegate

A scope ledger is five lines that bound a delegated task before the agent starts. Goal, allowed paths, forbidden paths, verification command, merge owner. That is the whole thing.

The point is to move review away from arguing about what a prompt meant. Rules in a config file and intent in chat tend to drift apart, and reviewers end up reconstructing the gap by hand. With a ledger, review becomes a comparison: does the diff stay inside the allowed paths, did the verification command run, is the named owner the one merging.

You can keep one snapshot that works whether the team runs Codex, Claude Code, or Codex:

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Codex: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

If your repo cannot state its boundaries plainly, agents will guess at them, and guessing does not scale.

Give every MCP connector a card

Wire connectors fast and one of them quietly reaches data nobody put on the diagram. The fix is not better tools. It is a one-page operating contract per server: allowed actions, forbidden actions, owner, and rollback steps.

Keep it to a single markdown card and ground it in the MCP specification. The value shows up during incidents, because operators can see at a glance what "off" looks like and who turns it off. Blast radius stays small when reach is written down instead of discovered.

For setup details across tools, the Codex agent overview, Claude Code getting started, and the Codex quickstart are worth bookmarking.

Make agents return receipts, and PRs state decisions

Chained agents love to hand back tidy summaries that drop the paths a child actually edited. That is a game of telephone running at machine speed, and a parent agent will green-light a mystery diff with full confidence. Ask every child to return three things: paths touched, commands run, and tests that prove the regression guards held.

Pair that with a decision stub in the PR template. CI being green does not tell a reviewer why this approach won. Three short lines fix it: constraints considered, alternatives rejected, verification proof. The debate shifts from taste to written tradeoffs, which is the only kind you can revisit six months later.

Check the gate, not the vibes

When the change reaches the merge gate, the reviewer is checking lookups, not running an investigation. Here is the table I keep next to the PR template.

Gate Question
Receipt match Does the PR body list scopes + verification transcript?
Rules precedence Which .mdc, SKILL.md, or CLAUDE.md governed behavior?
Connector truth Which MCP servers fired, and were they expected?
Reviewer path Can someone unfamiliar trace intent without chat replay?

A four-line checklist makes the same pass paste-able into any review:

  • MCP connectors mentioned (if any) list owners.
  • Verification command output is pasted or linked.
  • Forked agent work lists parent + child responsibilities.
  • Red-folder paths received explicit human acknowledgement.

The fast team is not the one with the loosest gate. It is the one whose merges need no archaeology.

Common questions

  • What is agentic coding governance in practice?

    It is the written layer between agent output and merge: connector cards for MCP servers, child receipts for chained agents, decision stubs in PRs, and scope ledgers per task. Each artifact answers a question reviewers would otherwise ask in chat, after the diff has already landed and the context is gone.

  • Does governance slow agentic coding down?

    It slows the first task and speeds up every one after. The checks are lookups, not investigations: does the PR list scopes and a verification transcript, which rules governed behavior, which connectors fired. The genuinely slow path is the archaeology that follows an unexplained merge nobody wrote down.

  • Why is permission drift the expensive bug?

    Because nobody signed it. Approvals turn into muscle memory, connectors quietly gain reach, and the blast radius grows until an incident maps it for you. Cards with owners and rollback paths, plus explicit human sign-off on red-folder paths, keep that drift visible while it is still cheap to fix.

  • Which artifact should a team add first?

    Start with the scope ledger on your next delegated task. It is five lines, it needs no new tooling, and it immediately changes review from debating prompts to checking a diff against stated boundaries. Add connector cards next, since those tend to be where the quiet reach lives.

Start with one ledger

Add a five-line scope ledger to the next task you hand an agent, then run it past the merge-gate table above. We work these four contracts against live repos in our training sessions, so bring the diff nobody on your team could explain.

Related training topics

Related research

Continue through the research archive

Ready to start?

Transform how your team builds software.

Get in touch