Agent class · Native substrate

Govern your voice and customer-facing agents.

Every call verified. Misses included.

A voice agent acts in real time, in your brand’s voice, with no human between the model and the customer. GOVENANT measures resolution against the record — “answered” is not “resolved” — and writes down the misses, which is what makes the hits believable.

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. voice & CX agents

RetellVapiElevenLabs AgentsSierraDecagonIntercom FinLiveKit Agents

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 voice & CX agents

The highest-stakes class of agents

A wrong customer call is a lost customer or a compliance event. Voice agents act in real time, in your brand’s voice, with no human between the model and the customer — exactly where a verified outcome record matters most.

“Answered” is not “resolved”

The gap between a completed call and a verifiably resolved need is precisely the performed-autonomy gap. GOVENANT measures resolution against the record — and writes down the misses, which is what makes the hits believable.

The trust stack, completed

Controls certifications and insurance tell buyers the vendor is responsible; a GOVENANT record shows the agents deliver, continuously, in production. They certify the brakes; we measure the odometer. Enterprise buyers increasingly want both.

Where this bites — a real scenario

A support org routes 40,000 calls a month through a voice agent. The platform reports a 82% resolution rate; the CFO wants to expand the deployment.

The challenge

“Resolution” is the platform grading itself: a call that ends without a transfer is scored resolved. Nobody is checking how many “resolved” customers called back within 48 hours about the same issue — the exact gap between answered and resolved.

What the record reveals

With resolution keyed to the record and reopens logged by an independent watchdog, verified resolution lands at 63%, with a reopen cluster in billing. The honest number is lower — and it’s the first number the CFO trusts enough to actually expand on.

How it works

The substrate: The conversation record: transcripts, end reasons, and a verified outcome row per call — resolution, not mere completion.

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

  1. Map call/conversation records to duty-runs: transcript reference, end reason, and a verified outcome row per conversation.
  2. Define resolution criteria as the deterministic validation gate — what counts as “handled,” decided in advance, checked against the record.
  3. Stand up the watchdog: missed, failed, and abandoned conversations get written down independently of the platform’s own reporting.
  4. Run the sweep over real traffic; review delivery ratios and the miss log with CX leadership.
  5. Publish what you can defend — internally first, then to the registry 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

A real integration can wear the Built-on GOVENANT badge under its four rules, and publish level claims to the registry with probe logs — self-assessed, open to challenge, never “certified.” For CX buyers, a public delivery record with the misses included is the strongest trust asset there is, because it is the one thing a vendor cannot fake comfortably.

Stacks that build voice & CX agents

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

Do transcripts or customer data leave our environment?
No. The sweep is read-only and aggregate-only: counts, ratios, verdicts. Transcripts, audio, and customer records never leave your store, on any tier.
We already track CSAT and resolution rate. What does this add?
Independence and reproducibility. Your resolution rate is your platform grading itself; the standard requires outcomes verified against the record, misses logged by a watchdog the reporting layer doesn’t control, and numbers anyone can recompute. That is the difference between a metric and a record.
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