Agent class · Native substrate

Govern your coding agents.

“Done” lives in the database, not in the model’s mouth.

Coding agents produce the most verifiable outcomes on earth — PR merged, tests green, deploy live. GOVENANT keeps “done” in the repo and CI, not in the model’s mouth. Any coding agent, any model.

Agent-agnostic by design

GOVENANT does not govern “Claude agents” or “OpenAI agents.” It governs the evidence trail of autonomous work. Keep the runner (the tool you audit from) separate from the system under audit (your agents):

What runs the audit

ClaudeChatGPTClaude CodeCursorCodexVS CodeWindsurfCline

An AI client you already use reads the open instrument and drives the read-only sweep. This is the runner — not the thing being judged.

What gets audited — incl. coding agents

Claude CodeCursorGitHub CopilotDevinCodexWindsurfa home-grown coding agent

Any agent system with an observable record of actions and outcomes — whatever built it. The agent never has to "support GOVENANT."

Ground truth: the database + actions + outcomes + duties + gates — the substrate, never the logs’ self-report.

Why govern coding agents

The most verifiable agents on earth

PR merged, tests green, deploy live — coding agents produce terminal outcomes the record can verify. That makes this the easiest class of agents to govern honestly, and the least excusable to leave ungoverned.

Trust the fleet, not the transcript

When agents write your code, the question is not what they said they did — it’s what shipped, verified against CI and the repo record. Motion is not delivery.

Audit today, govern this quarter

Most tools in this class speak MCP, so the free hosted GOVENANT Audit connects now. The governed substrate then turns agent output into a standing, sweepable delivery record.

Where this bites — a real scenario

A platform team runs a fleet of coding agents that open ~300 pull requests a week across forty repos. The dashboard is green; velocity is up and to the right.

The challenge

Leadership can’t answer a board question: of everything the agents “shipped,” how much actually merged, passed CI, and stayed green — versus PRs that were opened, auto-approved by another agent, and quietly reverted three days later? Velocity counts motion; nobody is counting delivery.

What the record reveals

Keyed to merged-and-green, the sweep shows 71% of agent PRs delivered — and surfaces a cluster of “completed” tasks whose deploys never went out and two repos where the agent was reviewing its own PRs. The number is lower than the dashboard, and for the first time it’s defensible.

How it works

The substrate: The repository: commits, pull requests, CI results, deploys — a terminal, verifiable record of what actually shipped.

The path — Native substrate: The platform already produces records that map to the standard — the sweep reads what it already keeps.

  1. Where the tool is an MCP client, connect the free hosted GOVENANT Audit — one URL, no API key.
  2. Make the repo the substrate: branch protections and required reviews are ownership gates; CI is the deterministic validation gate.
  3. Assign agent work as duties with outcome-keyed completion — merged and green, not “task marked complete.”
  4. Ledger agent sessions: what was asked, what was changed, what it cost, what verifiably landed.
  5. Sweep on a schedule and put the delivery record — misses included — where the team can see it.

The full requirements live in the open standard (CC BY 4.0) — the substrate shapes, the acceptance tests, and the conformance ladder your record is measured against.

What you can claim

A real integration can wear the Built-on GOVENANT badge under its four rules from day one. The ladder — Logged → Gated → Delivered → Earned — is self-assessed against the open standard and published to the registry with probe logs, open to challenge. For coding agents the Delivered rung has teeth: it means the record shows verified shipped work, not activity.

Stacks that build coding agents

Per-stack integration patterns for common ways to build coding agents — each with its own natural hook into the substrate:

Building it a different way? Browse all integrations — or run the free audit from any MCP-capable tool.

Governing coding agents — FAQ

My coding agent already shows me diffs and test results. What does this add?
A durable, queryable record across the fleet and across time: which duties exist, what delivered, what missed, and whether the misses are being written down by an independent watchdog rather than smoothed over. One session’s output is visibility; the substrate is governance.
Does this slow the agents down?
The gates run at chokepoints you already have — branch protection, CI, review. GOVENANT makes them count as governance by recording outcomes against duties; it adds accounting, not latency, to the inner loop.
Do my agents have to “support” GOVENANT?
No. GOVENANT governs the substrate — the record of what agents did and whether it verifiably delivered — not the agent. If the system of record around your agents can be read, or you can instrument the action boundary, they can be measured, whatever framework, model, or vendor built them.
What is “performed autonomy”?
Agents that look busy — fluent plans, satisfied logs — but don’t verifiably ship. Motion is not delivery. GOVENANT measures verified outcomes against the record, never the logs’ self-report.
What is GOVENANT, and who controls it?
An open standard for provable AI agent governance: three laws, a conformance ladder, and acceptance tests any implementation runs against its own record. Free to all under CC BY 4.0, with a citable companion paper (DOI 10.5281/zenodo.21440225), conformance self-assessed and published openly — no certifying authority.

More agent classes

All agent types · All integrations · Run the audit