Model for the token, not the table
Last edited on Aug 17, 2026
Gong is one of the highest-value AI context sources we own. When internal usage of Claude started scaling, teams wanted to connect Gong to start pulling from our large volume of call history. The shortest path for those requests flowed through a wrapper around the Gong MCP to the Gong REST API. Unfortunately, that also meant that the team was getting raw, unmodeled context that we couldn’t govern and improve.
A single customer-history question fans out through an MCP wrapping Gong’s APIs using list_calls to collect IDs, burning 8,300 tokens per call transcript or around 240,000 tokens in context for one account history of ~30 calls. Multiplying this across our entire sales department researching multiple accounts is exactly how you redline the Gong API’s per-second and per-day rate ceilings, which hit our cap very quickly.
Gong’s API constraints weren’t the real problem. Our core issue was using a transactional API as a high-throughput context layer for AI. Gong and other sources were never designed for these high-volume, operational use-cases. Databases are.
Compression, context engineering, and cost savings
We identified the root cause as the same historical problems that data teams face. Instead of going through our traditional data modeling and warehousing layer, users were hitting source data directly, going to Gong every time with the same "give me all my transcripts, now summarize them" request. Analyzing MCP connector usage showed us that Claude was reaching directly to sources that we already had in our data warehouse.
Fivetran was already funneling Gong into Snowflake continuously, where we could model data so people would never need the raw source. Serving Gong data from the warehouse through the dbt MCP server removes the API ceiling and lets us model the rich, but often verbose context into exactly the shapes an agent needs. We could even benefit from the broader data warehouse and join Gong data to everything else we know about the account, creating a rich context layer for our team as they used agents like Claude to help them work.
Higher-quality context at lower cost
By leveraging our warehouse and dbt, we took care of our API constraint issue and opened up significant potential token savings. Ingesting the raw Gong data into our data warehouse lets us use data modeling to summarize each call, eliminating noise and extracting only relevant signal. Given how valuable Gong data is at informing our business and how frequently it’s used, it made sense to set up pipelines on top of it that we could use for all the call transcript use-cases.
Actively compressing transcripts shrank data volume by 20x or more, slashing a 60-minute call from 10,000+ tokens to just a few hundred. The same transcripts, summarized, consume 74x fewer tokens and are now 99% cheaper to serve to AI agents while preserving or improving context quality. We can run hundreds or thousands more Claude sessions a day at the same cost, making ROI skyrocket.
The compression itself runs as an incremental dbt job as data enters the warehouse, with inference priced through Snowflake credits, Vertex batch pricing, or Databricks AI Function pricing, all materially cheaper than interactive API calls and paid once per call rather than every turn. The result is order-of-magnitude savings: the cost of compressing 1,000 calls in batch is in the low tens of dollars. Because compression is a one-time cost per call and the savings repeat on every read, the batch job pays for itself within the first meaningful agent session.
What token efficiency looks like at enterprise scale
| Direct connection (raw transcripts) | dbt + warehouse-AI compression 20x | |
|---|---|---|
Input tokens per turn (~12-call context) | 100,000 | 5,000 |
Input cost per turn | $0.30 | $0.015 (1/20) |
Output tokens/cost per turn | 5,000 / $0.075 | 5,000 / $0.075 |
Total cost per turn | $0.375 | $0.090 |
Per seller per year (50 turns × 250 working days) | $4,700 | $1,125 |
Human-in-the-loop cost 100-person sales team / year | $470,000 | $110,000 (savings: $360,000/yr) |
Agent cost always-on workflow / year (5K turns × 365 days) | $685,000 | $165,000 (savings: $520,000/yr) |
Based on Claude Sonnet 5 pricing as of August 2026, subject to change: $3 per million input tokens, $15 per million output tokens.
The pattern
This pattern is exactly the work dbt is built to do: model the transcripts in the warehouse, compress them with warehouse-native AI functions, and serve the compressed form to agents through the dbt MCP server. We just needed to dogfood things internally to show that dbt transforms data for AI as effectively as it does for BI:
- Fivetran delivers the Gong transcript into the warehouse when a call concludes using an existing connector, no new infrastructure required.
- A dbt model invokes a warehouse-native AI function (Snowflake Cortex COMPLETE, Vertex AI batch prediction, or Databricks AI Functions) to produce a structured summary, capturing deal-relevant points, named entities, sentiment, action items, and objection types. A 10,000-token transcript typically compresses to 500-to-1,000 tokens of structured summary without losing the signal an agent needs for deal context.
- The dbt MCP server serves the compressed form to the asking AI client. This is the same connection AI clients already use for any other dbt-modeled data, and the summary looks like just another well-modeled table.
Gong was our initial test case, but the pattern generalizes to any token-heavy, durable data source. The same architecture works for engineering context from sources like email archives, Slack channel logs, support tickets, contracts, or marketing collateral.
Three ways to serve Gong
Head-to-head, here’s how using the official Gong MCP, an MCP wrapping Gong’s APIs Gong MCP, and the dbt MCP server stack up against each other for serving unstructured Gong data as AI context:
| Official Gong MCP | Gong MCP wrapper | dbt MCP server | |
|---|---|---|---|
Key tools |
|
|
|
What it returns | Server-synthesized brief, no raw | Raw transcript text, speaker-segmented with timestamps stripped; slim variants trim fields but not words | Any tier the question needs: metadata, brief, snippet, or full transcript, plus governed metrics |
Gong API pressure | Light | Heavy; each question fans | None, reads hit Snowflake |
Content filter before pulling | No | No | Yes ( |
Joins to CRM, product, billing | No | No | Yes |
Verbatim | No | Yes | Yes |
Determinism | No; re-synthesized each call | Yes, raw is stable | Yes, computed from governed definitions |
Setup cost | None | None | Real modeling work up front |
Cost comparison: Gong vs MCP wrapper vs dbt
There's no single best tool for all queries, but there is a best tool per question type. Gong’s official MCP is efficient when all you want is a quick, server-synthesized, single-account summary; an MCP wrapper/gateway platform is good for pulling raw transcript text. Everything else—anything filtered, aggregated, joined, or trended, i.e. the majority of the analytical questions people actually ask—should go through dbt’s modeling and warehousing layer.
Note: Cost calculated using Opus pricing at $5/million tokens, anchored to 8,314 raw and 112 brief tokens per call.
| Question type | Official Gong | Gong MCP wrapper | dbt MCP server | Best choice |
|---|---|---|---|---|
Summary; "What's going on with Acme" | 30-call brief, ~1,200 tokens, $0.006 | No dedicated summary tool; | Brief column × 30, ~$0.017 | Official Gong, cheapest, and by an even wider margin without a wrapper summary tool |
One-off raw: "Pull the full May 14 Acme transcript verbatim" | Can't return raw |
|
| MCP wrapper ≈ dbt |
Filtered, verbatim: "What did Acme say about pricing" | Paraphrase only, unauditable, $0.004 |
|
| dbt, 20× cheaper, auditable |
Large-corpus call rollup: "Top 10 objections across all calls this year" | No aggregate tool | ~$21 even at brief tier, unreliable | One | dbt, ~8,600× cheaper, the only reliable path |
Join: "Do accounts that raise pricing 3+ times convert worse, by segment" | Not possible | Not possible | Salesforce join already exists, pennies | dbt, the only path |
Trend: "Is this competitor getting mentioned more, quarter over quarter" | No time-series primitive | Not practical |
| dbt, the only practical path |
Get started
If you want Gong context wired into your AI workflows, the path forward is to stop connecting directly to Gong's API, partner with the data team to get the Fivetran + dbt + warehouse-AI pipeline modeled. Any AI client (Claude, agents, whatever surface you’re using) connects to the dbt MCP server as a single governed entry point and gets access to dbt-modeled data through the same surface used for everything else in the warehouse.
Analytics engineers have always transformed structured data to build tables for humans and BI tools. Now we can apply the same general principles to unstructured data to build models and engineer context for AI agents. Modeling Gong (and similar sources) for AI is among the highest-impact data-team work available right now, with token efficiency as a first-class design constraint.
It’s time to expand beyond thinking what metrics can we serve and start treating call transcripts and other qualitative data as first-class, governed warehouse assets. Now the first question to ask of any source you wire to AI is what does the raw form cost per question, and what is the smallest modeled form that still answers it?
Get started in dbt
Join the analytics engineers building data infrastructure that actually scales.
Install dbt Wizard CLI
Get started with an agent purpose-built for analytics engineering. It knows which tool to call, which context to pull, and checks its own work before surfacing anything to you.
