Use case · Instrumented boundary

Govern your AI sales agents.

A pipeline full of activity isn’t a pipeline full of deals.

SDR and sales agents that draft, send, and “follow up” are this decade’s busiest performers — and the easiest to fool yourself about. GOVENANT measures what verifiably happened in your CRM against what each agent owed: meetings actually booked, records actually updated, opportunities actually advanced.

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. AI sales agents

a custom SDR agentAgentforce sales agentsRelevance AI / Lindy sales workersa LangGraph outbound 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 AI sales agents

Activity is not attainment

Emails sent and tasks “completed” are the vanity metrics of agentic sales. The standard keys completion to the CRM outcome — a real meeting, a real stage change — not the agent’s own report that it did the work.

Attribution you can defend

When a sales agent claims a booked meeting or an updated opportunity, the action row cites the CRM object that proves it. Revenue attribution stops being a story and becomes a query.

Catch the quiet failures

The follow-up that never sent, the lead that silently dropped, the “nurtured” account with no touch in 30 days — coverage math over the duty roster makes silence itself raise an alarm.

Where this bites — a real scenario

A revenue team deploys AI SDRs that send 20,000 emails a month and “book meetings.” The activity dashboard is glowing; the VP forecasts off it.

The challenge

Sent is not booked; a task marked “followed up” is not a follow-up that happened. Pipeline attributed to the agents is a story told by the agents’ own logs — and the follow-ups that silently never sent are invisible.

What the record reveals

Keyed to CRM outcomes — real meetings booked, real stage changes — the record shows agent-attributed meetings are 40% of what the activity dashboard implied, and flags 900 accounts marked “nurtured” with no touch in 30 days. The forecast finally rests on a number sales ops can defend.

How it works

The substrate: Your CRM and outreach system of record: emails sent, calls logged, meetings booked, opportunities advanced — the outcomes a sales agent claims, checked against the objects that prove them.

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. Map the CRM/outreach record: sent emails, logged calls, booked meetings, and stage changes become verified outcome rows.
  2. Register the agent’s levers — who may email, update records, or book — with named owners; unowned actions stop at the gate.
  3. Define duties: the recurring work each sales agent owes (follow-ups, enrichment, hand-offs), keyed to CRM outcomes, not activity.
  4. Run the free read-only audit over your own CRM data; review delivery ratios and the miss log with sales ops.
  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 wears the Built-on GOVENANT badge under its four rules, and level claims (Logged → Gated → Delivered → Earned) are self-assessed against the open standard and published with their probe logs — never “certified.” For a sales org, a verified delivery record is the difference between “our AI is crushing it” and a number the CFO can trust.

Stacks that build AI sales agents

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

Does GOVENANT read our customer or prospect data?
No. The audit is read-only and aggregate-only — counts, ratios, outcome verdicts computed over your own store. Contact records, email bodies, and call content never leave your environment.
Our sales agent is custom-built. Does it need to “support” GOVENANT?
No. If the actions land in a system of record you can read — your CRM, your outreach tool, your database — the work can be measured. GOVENANT governs the evidence trail, not the agent’s framework or model.
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