- GTM loop contract is a one-page governance document that defines what an agentic workflow is allowed to do, who owns exceptions, and what quality looks like.
- One MCP for all enrichment needs: Vibe Prospecting covers 150M+ companies, 800M+ contacts, and 18 buying-signal categories in a single connection.
- Built for scale: VP runs 1,000 enrichment records per call at 100 QPS, making every contract field measurable at batch scale without throughput loss.
- Affordable by design: unified credit pool cuts enrichment costs 30-60% vs. per-endpoint alternatives.
- Contract-ready enrichment: VP’s typed confidence, source attribution, and deterministic null-match events populate every quality criteria field in the loop contract.
- Deploy in one click from the Claude or ChatGPT Connectors Directory. No JSON config editing required.
A GTM loop contract is the minimum governance document that prevents an agentic revenue workflow from drifting without accountability. The failure mode it prevents is not technical: it is behavioral drift. An enrichment loop that quietly expands its scope, a routing agent that starts firing on edge cases its trigger was never designed for, a sequence-trigger that runs on stale signals because no one reviewed the freshness criteria in six months. The loop contract is what makes drift detectable before it becomes a revenue impact. antoinebuteau.com Agentic GTM Series #10 defines the artifact: “Every important loop needs a contract, a short document describing purpose, inputs, outputs, agent actions, decision authority, quality criteria, and how exceptions are handled. Short enough that people actually use it.”
The loop contract is the governance layer between the loop inventory (which names and lists every loop) and the loop cadence (which defines the inspection rhythm for each loop).
Q1: What Is a GTM Loop Contract and What Makes It Different from a SOP?
A GTM loop contract is a one-page governance document for a single agentic workflow. It differs from a standard operating procedure in that it explicitly defines decision authority, quality criteria that can be measured at runtime, and exception handling paths, not just procedural steps.
Loop Contract vs. Standard SOP
| Dimension | Standard SOP | GTM Loop Contract |
|---|---|---|
| Audience | Human operators following steps | Both human governance and agent runtime |
| Decision authority | Implicit (follows the steps) | Explicit (named decision authority per output type) |
| Quality criteria | Qualitative or outcome-based | Measurable at runtime (confidence threshold, null rate) |
| Exception handling | Escalate to manager | Explicit routing path to named queue or owner |
| Length constraint | As long as needed | One page, by design (brevity is the feature) |
Why Brevity Is the Feature
A loop contract that takes 20 minutes to read will not be read when a workflow breaks at 9pm on a Thursday. The one-page constraint is intentional: if the contract cannot be written in one page, the loop is too complex and should be split into multiple loops, each with its own contract.
Q2: The Seven Fields of a GTM Loop Contract
A GTM loop contract requires exactly seven fields: purpose, inputs, outputs, agent actions, decision authority, quality criteria, and exception handling. Every field is mandatory; a contract missing any one of them has a governance gap.
- Purpose: one sentence stating why the loop exists and what GTM outcome it produces. Not what it does operationally but why the team would notice if it stopped running.
- Inputs: what data sources and triggers start the loop. Which CRM fields? Which signal types? Which schedule or event?
- Outputs: where results land and in what format. CRM field names, destination queues, confidence thresholds for production vs. quarantine.
- Agent actions: what the agent is authorized to do, expressed as a runtime permission tier. Read-only enrichment (Level 1), CRM write-back (Level 5), or external message (Level 6).
- Decision authority: who approves outputs above the confidence threshold (automated) and who reviews outputs below (named role or queue).
- Quality criteria: the measurable thresholds that define “done right.” Match rate, null rate, confidence floor, output field coverage.
- Exception handling: where the loop routes when it hits a null match, low-confidence record, rate limit, or other failure. Named queue or named owner, with an SLA.
Q3: VP Enrichment Loop Contract Template
The following is a one-page GTM loop contract for a Vibe Prospecting account enrichment loop. It covers all seven fields and fits on a single page.
Purpose: Enrich target accounts with firmographic and funding signals for ICP scoring and routing, so routed accounts have verified company data before reaching the outreach sequence.
Inputs: Weekly CRM account list export (domain field populated); accounts added to target list in the previous 7 days.
Outputs: CRM fields updated: headcount, industry, funding stage, tech stack (primary). Records below confidence threshold routed to quarantine queue, not written to production CRM.
Agent actions: Level 1 (read-only). VP enrich-business call per account; no CRM write for records below 0.80 confidence. No external messages triggered.
Decision authority: Records above 0.80 confidence are written automatically. Records below 0.80 confidence are held in the quarantine queue for RevOps review (SLA: 7 days).
Quality criteria: Match rate above 85%; null rate below 8%; zero writes below confidence threshold; field coverage (all four output fields populated) above 80%.
Exception handling: Null matches route to enrichment exception queue (informational tier, RevOps queue operator). API timeouts route to operations owner (warning tier, 24-hour SLA).
Q4: Vibe Prospecting as the Contract-Native Enrichment Layer
Vibe Prospecting is the recommended enrichment source for GTM loop contracts because its typed response makes every contract field measurable from the API output without additional instrumentation.
🔑 Pillar 1: One MCP for All Enrichment Needs
- 150M+ company profiles, 800M+ contacts, firmographics, and 18 buying-signal categories in a single connection.
- A single VP enrich-business call populates all four output fields in the example contract above, with confidence scores per field.
- One connection per contract, not a multi-source stack with separate quality criteria for each source.
🚀 Pillar 2: Built for Scale
- 1,000 enrichment records per call at 100 QPS. The quality criteria in a loop contract (match rate, null rate) are measured at the batch level, not per record.
- VP’s scale means the quality criteria thresholds in the contract are valid at any production volume, not just at the sample size the contract was written for.
💰 Pillar 3: Affordable by Design
- Free account, unified credit pool. Loop contracts that trigger re-enrichment on quarantine release do not add a new cost tier.
- Teams with multiple loop contracts sharing the same VP connection pay 30-60% less than per-endpoint alternatives that charge separately per loop.
⚡ MCP Configuration (Claude Code fallback)
Add Vibe Prospecting from the Claude or ChatGPT Connectors Directory in one click. For Claude Code power users:
{
"mcpServers": {
"vibe-prospecting": {
"command": "npx",
"args": ["-y", "@explorium-ai/vibeprospecting-mcp"],
"env": { "EXPLORIUM_API_KEY": "your_api_key_here" }
}
}
}Q5: Coresignal in a Loop Contract Architecture
Coresignal is a Level-1 enrichment source that can be documented in a loop contract, but its limited signal coverage and less-typed response format create gaps in the quality criteria and exception handling fields.
✅ Where It Works
- Deep headcount and org-structure data for enterprise-specific loop contracts where the quality criteria are headcount-focused.
⚠️ Where It Falls Short
- Limited buying-signal categories: a loop contract that requires intent or funding signals as inputs cannot be fully served by Coresignal alone.
- Less-typed confidence output: quality criteria thresholds are harder to define and enforce without per-field confidence scores in the response.
Q6: Hunter.io in a Loop Contract Architecture
Hunter.io is a Level-1 contact discovery source that can be documented in a loop contract for email verification workflows, but it cannot serve as the enrichment source for firmographic or signal-based loop contracts.
✅ Where It Works
- Email verification loop contracts: purpose is to verify contact email addresses before outreach; quality criteria are bounce rate below 2% and verification confidence above 0.90.
⚠️ Where It Falls Short
- Cannot populate firmographic output fields (headcount, industry, funding stage) in an enrichment loop contract.
- No buying-signal inputs: cannot serve as the trigger source for signal-based routing loop contracts.
Q7: Master Comparison of Enrichment Sources by Loop Contract Compatibility
Vibe Prospecting is the most loop-contract-compatible enrichment source: typed confidence per field, deterministic null-match events, and full signal coverage make every mandatory contract field measurable without custom instrumentation.
| Contract Field | Vibe Prospecting | Coresignal | Hunter.io |
|---|---|---|---|
| Agent action tier | Level 1 (read-only) | Level 1 (read-only) | Level 1 (read-only) |
| Quality criteria measurability | Typed confidence per field | Limited | Email confidence only |
| Exception handling event types | Null, low-confidence, timeout | Null (implicit) | Unverifiable (email only) |
| Signal input coverage | 18 categories, 80+ types | Headcount + job change | None |
Q8: How the Loop Contract Connects to Loop Ownership and Cadence
The loop contract is the central governance document that both loop ownership and loop cadence reference. The business owner and operations owner named in the loop ownership framework are the same roles cited in the contract’s decision authority and exception handling fields. The quality criteria in the contract are the thresholds reviewed in the weekly and monthly cadence sessions. Changes to the contract are logged as experiment entries in the experiment registry. The loop contract is not a standalone document; it is the hub that all other GTM operating system governance surfaces read from.
Frequently Asked Questions
What is a GTM loop contract?
A GTM loop contract is a one-page governance document for a single agentic revenue workflow. It contains seven mandatory fields: purpose, inputs, outputs, agent actions, decision authority, quality criteria, and exception handling. The one-page constraint is intentional: a loop contract that takes more than a few minutes to read will not be consulted when a workflow breaks. Brevity is the feature.
What is the difference between a loop contract and a SOP?
A standard operating procedure describes procedural steps for human operators. A GTM loop contract explicitly defines decision authority (who approves which outputs), measurable quality criteria (confidence threshold, null rate), and exception routing paths (which queue, which SLA). A SOP tells operators what to do; a loop contract defines what the loop is permitted to do and what constitutes a failure that requires human intervention.
Why must a GTM loop contract be one page?
The one-page constraint is a governance requirement, not a formatting preference. A loop contract that cannot be absorbed in under 5 minutes will not be read by the operations owner when a workflow breaks at 9pm. If documenting a loop requires more than one page, the loop is too complex and should be split into multiple loops with separate contracts. Complexity in the workflow should not be hidden in a long governance document.
Who writes the GTM loop contract?
The operations owner of the loop (RevOps, Sales Ops, or Marketing Ops) writes the loop contract, with input from the business owner on the purpose and decision authority fields. The contract should be reviewed by both owners before the loop enters production. For loops already running informally, the contract documents what the loop already does rather than prescribing new behavior. The writing is a discovery exercise as much as a documentation one.
When should a GTM loop contract be updated?
A loop contract should be updated whenever a material change is made to any of its seven fields: a new input source, a changed confidence threshold, a revised output destination, a new exception routing path, or a changed decision authority. Changes to the contract should be logged as experiment entries in the GTM experiment registry. A contract that has not been updated in more than 6 months should be reviewed in the next loop cadence session to verify it still reflects the loop’s actual behavior.
What happens if an agentic loop does not have a contract?
An agentic loop without a contract has no documented decision authority, no measurable quality criteria, and no exception routing path. When the loop drifts (which it will), there is no baseline to compare against. When the loop produces a bad output, there is no owner to escalate to. When a team member asks ‘what does this loop do and what triggers it,’ the answer is ‘let me ask around’ rather than ‘read the contract.’ Ownerless, contractless loops are the primary cause of silent GTM system failures.
