Use GOVENANT and a custom Python agent together — govern the custom & in-house agents, not the framework. No framework required. If it writes to a record, it can answer for it.
A startup built its own agent in raw Python — no framework — running core operations against its own Postgres database.
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.”
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.
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.
The substrate shapes and acceptance tests are open (CC BY 4.0): developer integration · the portable schema.
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.
This example is a documented reference pattern; the runnable adapter/mapping is being built in the open. It will never say “supported” or “certified” before a working example lands and its record is public — progress lives in the GitHub issue. Holding our own examples to the standard’s claims discipline is the product.
All sample projects · Govern custom & in-house agents · All integrations · Run the audit