What can AI agents do with Gong call data?

AI agents can summarize calls, extract deal-risk signals with transcript evidence, capture next steps, and flag competitor mentions or MEDDIC gaps. The key distinction is interpretation versus action: an agent can propose a signal, but writing it to Salesforce or notifying a team should run through a governed, logged workflow.

Can an AI agent update Salesforce from Gong transcripts?

Yes, with a supported integration and a call matched to the right opportunity. Require a cited transcript excerpt, limit writes to an allowlist of Salesforce fields, and route uncertain or material changes to a human reviewer before anything is written.

Does Gong provide an API for call transcripts?

Yes. `POST /v2/calls/transcript` returns transcripts filtered by date range or call IDs, requires a transcript-read scope, and pages results with a cursor. Transcripts are only available once Gong has processed the call, so recheck calls that ended recently.

How do you govern an AI agent that reads Gong calls?

Use least-privilege credentials, with read-only Gong access and a narrow, allowlisted Salesforce write. Assign role-based approvals for reviewers, retain the transcript evidence behind each signal, and log every decision and external write in an audit trail so actions can be inspected and attributed.

AI Agents for Gong: Turn Call Signals Into Governed Sales Work

Gong captures what happens on sales calls. A governed agent can turn those signals into reviewed deal updates and follow-up across Gong, Salesforce, and Slack, without asking a model to reinvent the same workflow on every call.

Jose GironOctober 28, 2026

Major x Gong: governed AI agents turn sales-call signals into reviewed CRM work.

What Gong agents can do, and where cross-tool work begins

Gong's own agents work on call data inside Gong: they summarize conversations, surface deal signals, and run automated actions on triggers you configure in its AI agents documentation. The cross-system part starts when a signal has to become a reviewed Salesforce update and a Slack decision, with evidence and history that outlive the call.

That is where Major fits. Major is the enterprise platform where agents build the software they run on. You put the repeatable routing, storage, and approvals in a deterministic app, and the agent reasons only about the one thing that needs judgment: does this transcript actually support a risk or next-step signal? Reason once. Run forever.

Here is how the two approaches differ in practice:

Gong-native agent: state lives in Gong, judgment happens in the model on each run, and the output stays in Gong's own surfaces.
Major app plus agent: state lives in the app's managed database, judgment is limited to the ambiguous interpretation step, and routing, approvals, and writes to Salesforce and Slack run as code.

Neither replaces the other. Gong remains the system of record for conversations. The app layer owns the work that follows.

Post-call workflows sales ops can operationalize

Four workflows come up in nearly every Gong and Salesforce rollout.

Deal-risk evidence. The agent reads a transcript, quotes the lines that suggest a stalled champion or a budget objection, and attaches them to the opportunity. The quote matters more than the label, because a reviewer can verify it in seconds.

Next-step capture. Verbal commitments ("send the security questionnaire Thursday") become structured tasks tied to the opportunity, instead of living in a rep's memory.

Competitor mentions. A mention is logged with the excerpt and call ID so competitive intelligence is searchable rather than anecdotal.

Coaching and MEDDIC follow-through. Gaps in qualification criteria are flagged for the manager with the supporting excerpt.

We have no outcome numbers for these workflows to quote, and invented ROI figures would not help you. Measure your own baseline before you ship.

What Gong access and transcript data require

Gong's API supports OAuth and key-based access. Request only the scopes you need. Reading call details and transcripts is a read-only job, and it should stay that way.

Transcripts come from POST /v2/calls/transcript, documented here. You filter by date range or by call IDs, and results page through a cursor. The calls API returns call metadata, with extensive details available on request.

Three constraints shape the design:

Transcripts are not instant. A call that just ended may not be processed yet, and AI-generated call details can be absent. Treat "not ready" as a normal state and recheck.
Rate limits. Gong documents defaults of 3 requests per second and 10,000 per day, with HTTP 429 and a Retry-After header when you exceed them. Check your account's actual limits.
Duplicates. Event triggers can fire more than once. Key every record on the Gong call ID.

Pipedream's Gong integration offers a New Call trigger and read actions, including a call details action. That trigger tells you a call exists. It does not promise the transcript is ready.

How to build a Gong deal-signal agent on Major

Here is the build, using three connectors and one app. If you want to start in the platform while you read, open Major here.

Connectors: Gong for call and transcript reads, Salesforce for opportunity context and approved updates, Slack for review cards.
The app: a managed database with three tables. call_events holds the Gong call ID, timestamps, and processing state. deal_signals holds the signal, evidence excerpt or reference, opportunity ID, confidence, and status. approvals holds reviewer, decision, timestamp, and rationale.
Views: New signals, Needs review, and Ready for CRM, so a RevOps lead can manage the queue without touching the agent.
The agent: it reads the transcript and the matched opportunity, decides whether the evidence supports a signal, cites the excerpt, and marks it ambiguous when it is not sure. That is the only model call in the loop.
The trigger: a Gong new-call event starts processing, and a 15-minute scheduled reconciliation catches missed events. Both write to call_events, and the unique call ID prevents duplicates.
Governance: scoped credentials per connector, RBAC roles for RevOps reviewer and app admin, and an audit trail for every decision and external write.

Here is the permissions checklist:

Gong: read access to calls and transcripts. No write.
Salesforce: read on opportunities, plus update permission limited to an allowlist of fields.
Slack: post only to the designated review channel.

The agent builds the app once. After that, the routing and writes are code, which is the point. For background on the pieces, see how to build an agentic workflow, AI agent access control, and agent observability.

Make call intelligence repeatable, not opaque

The example below is an illustrative build, not a customer deployment, and it makes no claim about measured results. Call it the Post-call Deal Signal Desk.

The Gong New Call event arrives and the app inserts a call_events row, or ignores it if the call ID already exists.
The workflow waits and rechecks until the transcript is ready, backing off on a 429 per Retry-After.
The app pulls the call and transcript from Gong and fetches the matched opportunity from Salesforce.
The agent judges whether the evidence supports a risk or next-step signal and writes a deal_signals row with the excerpt and a confidence level.
Clear, low-stakes signals move to Ready for CRM. Ambiguous or material ones go to Needs review, and Slack delivers an approval card to the review channel.
A reviewer approves or rejects. The decision lands in approvals, and only an approved, allowlisted update is written to Salesforce. The write is logged.

My position: transcript-derived CRM changes should not be automatic when the evidence is ambiguous. Require the quote, and require a human for anything material or low-confidence. An agent that overwrites seller judgment on a hunch will lose the team's trust in a week.

Compare that with a model re-reading the same transcript and re-deciding the same routing on every run. The app version is cheaper to repeat, easier to audit, and picks up where it left off, because the state is in the database and not in a context window. Teams that want the Salesforce side in more depth can read about Salesforce AI agents.

The model still reasons here. It just does less, and only where judgment is needed.

Start building on Major

Build a Gong deal-signal app that keeps transcript evidence, review history, and approved Salesforce updates in one governed workflow. Major's agent handles judgment calls while deterministic app code runs repeatable follow-through.

Frequently asked questions

What can AI agents do with Gong call data?: AI agents can summarize calls, extract deal-risk signals with transcript evidence, capture next steps, and flag competitor mentions or MEDDIC gaps. The key distinction is interpretation versus action: an agent can propose a signal, but writing it to Salesforce or notifying a team should run through a governed, logged workflow.
Can an AI agent update Salesforce from Gong transcripts?: Yes, with a supported integration and a call matched to the right opportunity. Require a cited transcript excerpt, limit writes to an allowlist of Salesforce fields, and route uncertain or material changes to a human reviewer before anything is written.
Does Gong provide an API for call transcripts?: Yes. `POST /v2/calls/transcript` returns transcripts filtered by date range or call IDs, requires a transcript-read scope, and pages results with a cursor. Transcripts are only available once Gong has processed the call, so recheck calls that ended recently.
How do you govern an AI agent that reads Gong calls?: Use least-privilege credentials, with read-only Gong access and a narrow, allowlisted Salesforce write. Assign role-based approvals for reviewers, retain the transcript evidence behind each signal, and log every decision and external write in an audit trail so actions can be inspected and attributed.