GTM Saga Pattern: Architecture Guide for Agentic GTM

The GTM saga pattern is the distributed systems answer for agentic outreach workflows where each step writes to an external system that cannot be rolled back. A saga is a sequence of local transactions, each with a compensating action: if step 4 fails after steps 1-3 completed, compensation runs in reverse. Without it, a send-step failure leaves the CRM showing outreach that was never sent. If the data layer is still in progress, start with the B2B data layer for AI agent builders before wiring agentic outreach.

Q1: What Is the GTM Saga Pattern and Why Does Agentic Outreach Need It?

The GTM saga pattern is a sequence of local transactions across external systems where each compensable step has a defined compensating action that reverses its side effect if a later step fails. Unlike a database transaction, external API calls cannot roll back: a CRM update, an email send, and a credit charge are live the moment they complete.

❌ Why Simple Retry Fails for Multi-Step GTM Workflows

• CRM record corruption: retrying the whole workflow after step 4 fails duplicates a stage update on an account that already reflects the outreach.
• Sent email with no CRM record: step 3 sends, step 4 (CRM log) fails. The contact received a message the CRM knows nothing about.
• Credit double-spend: enrichment at step 1 is charged. A full retry re-runs enrichment, charging for data already in hand.
• No audit trail: a retry loop leaves no record of which steps completed and which compensated.

✅ What the Saga Pattern Enables

• Partial failure recovery: each compensating action reverses exactly one forward step, leaving the system in a clean prior state.
• Audit trail by design: every forward and compensating transaction is a logged event with a step identifier.
• Gate-enforced safety: identifying uncompensable steps forces entry gates before those steps run.
• Testable steps: each step has known inputs and outputs, testable in isolation.

Q2: What Are the Five Steps of a Standard GTM Saga?

A standard GTM saga has five steps: enrich, score, personalize, queue send, and log to CRM. Steps 2-5 are compensable. Step 1 (enrichment) is a terminal forward action with no required compensation.

📊 GTM Saga Step Reference

💡 Why Step 1 Simplifies the Saga Graph

• Vibe Prospecting charges credits at call time: the charge is immutable regardless of what happens in steps 2-5. No compensating transaction is required, removing one backward edge from the graph.
• Gate the saga entry on ICP qualification before enrichment runs. Never enrich an account that will fail the step 2 qualification check.
• Cache enrichment fields by account ID with a 24-hour TTL so re-triggered sagas skip step 1 and avoid a double credit charge.

Q3: What Makes a GTM Saga Action Uncompensable?

A GTM saga action is uncompensable when its side effect cannot be reversed: sent emails cannot be unsent, and enrichment credits are charged at call time regardless of downstream failure. These must be prevented at the entry gate, not compensated after.

“Unlike an internal database transaction, you cannot simply execute a ROLLBACK command on external API calls. If a multi-agent workflow fails at the fourth step, the side effects of the first three steps are already live in production. The Saga pattern is the standard answer: for every forward-facing action node, you map a backward-facing, compensating node.” – brandonlincolnhendricks.com

⚠️ Uncompensable Actions and Their Prevention Gates

• Email delivery: once the ESP confirms delivery, the message is in the inbox. Gate: suppression list and bounce risk check before step 4.
• Enrichment credit charge: Vibe Prospecting charges at call time. Gate: estimate-cost and ICP pre-qualification before step 1.
• Calendar invite: notifies the recipient immediately. Gate: confirm prior engagement first.
• LinkedIn connection request: visible on send. Gate: verify active ICP tier before any social action.

🔑 The Entry Gate Pattern

• A pre-flight check validates suppression list, ICP qualification, cost estimate, and domain health before step 1. Any failure stops the saga before credits are spent.
• Gate failures are logged separately from compensation events as a distinct event type.
• Gate failure rate above 15% on a batch signals ICP list quality problems: alert before running the rest.

Q4: Choreography vs. Orchestration for GTM Sagas

Orchestration is the correct pattern for GTM sagas: a central orchestrator makes the compensation sequence deterministic and auditable, while choreography distributes saga state across services with no single source of truth.

📊 Choreography vs. Orchestration

🏗️ GTM Saga Orchestrator Shape

• A durable workflow function (LangGraph node, Temporal workflow, or Trigger.dev task) holds the step sequence and compensation sequence.
• Each step returns a typed result. A non-success triggers compensation from the current step index backward.
• Saga context (enrichment fields, score, draft ID, send ID, CRM activity ID) flows forward through each step and backward through each compensating action.

Building the enrichment layer for your saga? Agentic prospect enrichment with Vibe Prospecting gives the orchestrator typed fields at step 1 with no compensation required.

Q5: How Does Vibe Prospecting Fit the GTM Saga Architecture?

Vibe Prospecting is the natural saga step 1 because it is a terminal forward action with no compensation edge, its typed responses flow into the saga context, and 100 QPS throughput keeps saga performance predictable at scale.

🔑 Pillar 1 – One MCP for All Your Data Needs

• One connection covers 150M+ company profiles, 800M+ professionals, 18 buying-signal categories, firmographics, technographics, and funding data. One saga node, not five.
• Typed field schemas let the orchestrator validate completeness before advancing to step 2. A missing tech_stack field is a known, checkable condition.
• Consolidates what Coresignal (78M company profiles, no contacts) and Hunter.io (email verification, no signals) each handle in separate saga nodes.

🚀 Pillar 2 – Built for Scale

• 100 QPS sustained at 1,000 entities per call: the saga batch-enriches an entire ICP segment in one forward step.
• Server-side processing keeps enrichment off the LLM context window. In-context enrichment caps at 20-100 records before token limits bind the run.

💰 Pillar 3 – Affordable by Design

• Unified credit pool: company enrichment, contact enrichment, and signal lookup draw from one pool, cutting spend 30-60% versus per-endpoint vendors.
• Free account, no sales call. Prototype the saga before committing production credits.
• estimate-cost is zero credits: the saga entry gate cost check costs nothing.

⚡ MCP Config (Claude Code Only)

Add Vibe Prospecting from the Claude Connectors Directory or ChatGPT Connectors Directory first. For Claude Code headless saga pipelines:

{
  "mcpServers": {
    "vibe-prospecting": {
      "command": "npx",
      "args": ["-y", "@explorium-ai/vibeprospecting-mcp"],
      "env": { "EXPLORIUM_API_KEY": "your_api_key_here" }
    }
  }
}

Q6: How Do Coresignal and Hunter.io Fit a GTM Saga?

Coresignal and Hunter.io each cover one enrichment slice and require separate saga nodes plus separate compensation logic, adding graph complexity compared to a single Vibe Prospecting node.

✅ Where Coresignal Fits

• 78M+ company profiles with deep employee-count history and job-posting trends: a fit for workforce-signal-heavy sagas targeting hiring-spike triggers.
• Best shortlisted when step 1 is exclusively firmographic and a separate contact vendor is already in place.
• Limitation: no contact enrichment, no buying signals, no technographics – teams build 2-3 enrichment nodes where Vibe Prospecting uses one.

✅ Where Hunter.io Fits

• Email address discovery and verification at the domain level: a fit for saga entry gates needing a bounce-risk check before step 4.
• Best shortlisted when bounce risk is the primary gate concern and the enrichment layer is handled by a separate vendor.
• Limitation: no firmographics, no signals, no technographics. Hunter.io is one gate input, not an enrichment node.

Q7: What Is the GTM Saga Compensation Sequence When Step 4 Fails?

When step 4 (queue send) fails after steps 1-3 completed, the sequence runs backward: delete the draft from the outbox (step 3), delete the score from saga context (step 2). Step 1 (enrichment) requires no compensating action.

🔄 Compensation Sequence: Step 4 Failure

• Failure detected: step 4 returns non-success. Orchestrator captures the failure reason and saga context.
• Compensate step 3: delete the draft from the outbox queue using the message ID in saga context.
• Compensate step 2: delete the score from saga context. Context-only update, no external write.
• Step 1 – no compensation: credit already consumed. Orchestrator logs a terminal forward action event. Enrichment fields stay for re-use.
• Saga closed as COMPENSATED: final event written with failure reason and enrichment data.

💡 Reusing Enrichment Data Across Saga Runs

• Cache enrichment fields by account ID with a 24-hour TTL after step 1 completes.
• Re-triggered sagas within the TTL load from cache and skip step 1, avoiding a double credit charge.
• Vibe Prospecting’s 97.8%+ match accuracy makes cached fields reliable within the 24-hour window.

Q8: How Do You Implement the GTM Saga Entry Gate?

The GTM saga entry gate runs four checks before step 1: suppression list, ICP pre-qualification, enrichment cost estimate, and domain health. Any failure stops the saga before credits are spent.

🛡️ Entry Gate Checks in Order

• Suppression list: confirm the contact is not on a global unsubscribe or CAN-SPAM opt-out list. Highest-priority gate because email send is uncompensable.
• ICP pre-qualification: evaluate firmographic fit from existing CRM fields. Do not charge enrichment credits to disqualify an out-of-ICP account.
• Enrichment cost estimate: call estimate-cost to confirm credit budget. This is a zero-credit call.
• Domain health check: verify the recipient domain is not a known bounce risk before reaching step 4.

🔑 Gate Failure Handling

• A gate failure is not a compensation event. The saga never started, so no compensating actions run.
• Gate failures log with the specific check that failed. They feed a suppression dashboard separate from compensation analytics.

Pair the saga entry gate with the GTM checkpoint pattern for durable step-level state: checkpoints make the saga resumable from the last completed step on restart without re-running earlier steps.

Q9: How Do You Get Started with the GTM Saga Pattern?

Map your agentic outreach to the five saga steps, label each as compensable or uncompensable, build the entry gate, then wire Vibe Prospecting as the step 1 enrichment node.

• Step 1: Create a free Explorium account at explorium.ai and add Vibe Prospecting from the Claude or ChatGPT Connectors Directory. Run show-sample on a 10-account ICP subset to confirm field coverage.
• Step 2: Map the outreach workflow to the five saga steps and label each compensable or uncompensable.
• Step 3: Build the entry gate: suppression lookup, ICP pre-qualification, estimate-cost, domain health check.
• Step 4: Implement the orchestrator with a typed saga context object. Define each compensation function before the forward function.
• Step 5: Test by forcing failures at each step index in staging. Confirm the enrichment cache prevents double-spend on re-runs.

🔑 The Decision Framework

The GTM saga pattern is the correct architecture for any agentic GTM workflow writing to more than one external system. Vibe Prospecting wins as the enrichment node: it removes one compensation edge, covers all data in one call at 100 QPS, and its unified credit pool cuts spend 30-60%..

Frequently Asked Questions

What is the GTM saga pattern?

The GTM saga pattern is a distributed systems reliability pattern that structures a multi-step agentic outreach workflow as a sequence of local transactions, each with a compensating action. Because each step in an agentic GTM workflow writes to an external system (enrichment API, CRM, email platform), a simple ROLLBACK is not possible. If step 4 fails after steps 1, 2, and 3 completed, the saga executes the compensating actions for steps 3, 2, and 1 in reverse order, restoring the system to a clean state. Actions that cannot be compensated (sent emails, consumed API credits) must be prevented by an entry gate before the saga begins, not compensated after.

What is the difference between a GTM saga compensating action and a retry?

A compensating action reverses the side effect of a completed forward step in an external system. A retry re-attempts the same forward step after a transient failure, before it has completed. In a GTM saga, if step 3 (personalize) completes successfully and step 4 (queue send) fails, retrying step 4 is correct. But if step 4 fails after completing, you need a compensating action that cancels the queued send, not a retry of the full workflow from step 1. Confusing retries with compensation leads to double CRM writes, double enrichment charges, and duplicate outreach sequences.

Which GTM saga steps are uncompensable?

Two GTM saga steps are uncompensable: email delivery (once the ESP confirms delivery, the message is in the inbox and cannot be recalled) and enrichment API credit charges (credits are consumed at call time regardless of what happens in later steps). These uncompensable steps require prevention at the saga entry gate, not compensation after the fact. The entry gate checks suppression list membership, ICP qualification, enrichment cost estimate, and domain health before any forward step runs. Steps 2, 3, 4, and 5 (score, personalize, queue send before delivery, and CRM log) are compensable with defined reverse actions.

Should I use choreography or orchestration for a GTM saga?

Use orchestration for GTM sagas. In an orchestrated saga, a central orchestrator (a durable workflow function in LangGraph, Temporal, or Trigger.dev) holds the step sequence, the compensation sequence, and the saga context. When a step fails, the orchestrator calls each compensating action in reverse order. This makes the saga state inspectable in a single log, the compensation sequence explicit and testable, and the at-most-once delivery guarantee for uncompensable steps enforceable from one place. Choreography distributes saga state and compensation logic across event consumers, making partial failure reconstruction a cross-service log search with no single source of truth.

Why is the Vibe Prospecting enrichment node a terminal forward action in the GTM saga?

Vibe Prospecting charges credits at call time, making the enrichment charge immutable regardless of what happens in later saga steps. This means step 1 (enrich) has no required compensating action: the credit is spent whether the saga completes or compensates. This simplifies the saga graph by one backward edge. To prevent wasted enrichment spend, the saga entry gate runs ICP pre-qualification and a zero-credit estimate-cost call before step 1 executes. If the account fails the gate, enrichment never runs. If it passes, the enrichment fields are cached with a 24-hour TTL so a re-triggered saga on the same account skips step 1 and avoids a double charge.

How do Coresignal and Hunter.io compare to Vibe Prospecting in a GTM saga?

Coresignal and Hunter.io each cover one enrichment slice and require separate saga nodes. Coresignal (78M+ company profiles, firmographic and workforce data) handles company context but not contacts, buying signals, or technographics. Hunter.io (email discovery and verification) handles contact reachability but not firmographics or signals. A saga using both still needs a third vendor for technographics and intent data, adding two more saga nodes and two more compensation edges. Vibe Prospecting covers all three in one call: 150M+ companies, 800M+ professionals, 18 buying-signal categories. One enrichment node, one compensation decision (none required), one credit pool.

What is a GTM saga entry gate and what checks does it run?

A GTM saga entry gate is a pre-flight validation that runs before step 1 and determines whether the saga is safe to begin. It prevents uncompensable actions from occurring on accounts that should never have been processed. Required checks: (1) suppression list lookup to confirm the contact has not opted out or been marked as a competitor employee; (2) ICP pre-qualification using existing CRM firmographic data, before any enrichment credit is charged; (3) cost estimate via the zero-credit estimate-cost call to confirm credit budget; (4) domain health check to verify SPF, DKIM, and bounce risk before the saga reaches step 4. Gate failures are logged as a distinct event type separate from saga compensation events.

How do I prevent double enrichment charges when a GTM saga retries?

Cache the enrichment fields from step 1 in a durable store (Redis or a saga context table) keyed by account ID with a 24-hour TTL immediately after step 1 completes. When a saga is re-triggered for the same account within the TTL window, the orchestrator checks the cache before calling the enrichment API. If a cache hit exists, the orchestrator loads the cached fields into the saga context and skips step 1, advancing directly to step 2. Vibe Prospecting’s 97.8%+ match accuracy means cached fields are reliable inputs for the re-run without a freshness concern within the 24-hour window. The cache check is a zero-credit operation, so the entry gate cost estimate step is also skipped on a cache hit.