Use case · Instrumented boundary

Govern your custom, in-house agents.

No framework required. If it writes to a record, it can answer for it.

The agent you built yourself — raw Python, a bespoke loop, your own orchestration — is the purest case for the standard. GOVENANT doesn’t need your framework, your prompts, or your model. It needs an observable substrate. If your agent’s actions land in a database or an API you can read, it can be measured today.

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. custom & in-house agents

a custom Python agenta bespoke orchestration loopan internal tool-using assistantanything with a database behind it

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 custom & in-house agents

The standard is the framework

You don’t adopt a runtime; you adopt shapes. The open schema (Parts 0–16) tells you what an action row, a duty, and a verified outcome look like — write those from your own code and you conform.

Nothing to “support”

Because GOVENANT governs the substrate, your agent doesn’t integrate with a vendor. It writes an append-only record and keys completion to verified outcomes. The audit reads that record — no SDK lock-in, ever.

Boundary-only, by design

The developer integration operates at the action boundary and needs no access to your reasoning loop, prompts, framework, or models. That architectural property is what makes it universal.

Where this bites — a real scenario

A startup built its own agent in raw Python — no framework — running core operations against its own Postgres database.

The challenge

It works, but there’s no governance story for the enterprise deals in the pipeline: no ledger, no ownership gates, no way to prove to a buyer that the agent delivers what it claims. And no vendor SDK to “adopt.”

What the record reveals

They adopt shapes, not a runtime: an append-only action row at the tool boundary, duties keyed to verified outcomes — straight from the open schema. The free audit reads their own Postgres and returns a Delivered-rung record they attach to the next security questionnaire. No framework, no lock-in.

How it works

The substrate: Whatever your agent writes to: your database, your queue, your APIs — the durable record of actions and their verified outcomes, in shapes the standard defines and your code already emits.

The path — Instrumented boundary: Add a thin hook at the action boundary — no access to prompts, reasoning, or models — so every action and its outcome is recorded.

  1. Adopt the substrate shapes from the open standard (Part 15 developer integration + the SCHEMA) — an append-only action ledger keyed to outcomes.
  2. Write an action row at your tool boundary: input, output, cost, and the verified outcome — not the trusted return value.
  3. Register your levers with named owners and gate the consequential ones; define your duties and key completion to outcomes.
  4. Connect the free hosted audit (it speaks MCP) or run the sweep over your own store — read-only, SELECT-only.
  5. Publish a self-assessed level to the registry with its probe log when the record is ready.

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

From day one of a real integration you can wear the Built-on GOVENANT badge under its four rules. The ladder — Logged → Gated → Delivered → Earned — is self-assessed against the open standard and published to the registry with probe logs, open to anyone’s challenge. No authority hands out stamps; a reproducible record is the point.

Stacks that build custom & in-house agents

Per-stack integration patterns for common ways to build custom & in-house 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 custom & in-house agents — FAQ

My agent uses no framework at all. Does GOVENANT still apply?
Especially then. The standard governs the record your agent keeps, not the code that keeps it. Emit the substrate shapes from your own loop and you’re conformant — no framework, SDK, or vendor required.
What’s the minimum to get a real result today?
An observable record. If your agent’s actions already land in a database or an API you can read, the free audit can measure delivery now; adding an append-only ledger keyed to verified outcomes is what unlocks the higher rungs.
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 use cases

All agent types · All integrations · Run the audit