Use GOVENANT and an AI SDR + your CRM together — govern the AI sales agents, not the framework. A pipeline full of activity isn’t a pipeline full of deals.
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.
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.
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.
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.
| GOVENANT shape | an AI SDR + your CRM source |
|---|---|
| Action row | The agent’s outreach log: emails sent, calls logged, records touched |
| Verified outcome | CRM state that proves it: a booked meeting (Event/Activity), an Opportunity StageName advance — not “task complete” |
| Duty | Recurring work owed: follow-ups, enrichment, hand-offs, keyed to CRM outcomes |
| Miss | Accounts owed a touch with none in N days; “nurtured” with no activity row |
-- A booked meeting is an Event that exists; a real follow-up is an activity row.
-- Sent != booked. Keyed to CRM outcomes, not the agent's own "done".
create or replace view gov_sales_delivery as
select 'book_meeting' as duty, o.id as subject_ref,
exists (select 1 from event ev where ev.opportunity_id = o.id
and ev.created_by_agent) as delivered
from opportunity o where o.owner_is_agent; The substrate shapes and acceptance tests are open (CC BY 4.0): developer integration · the portable schema.
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.
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 AI sales agents · All integrations · Run the audit