How does Octave learn from your conversations?

​

A self-improving GTM system

Most GTM knowledge lives in static documents that drift from reality within weeks. Octave closes that gap by continuously ingesting your real customer interactions, extracting structured signal, and feeding it back into the Library — creating a loop where your strategy informs your agents, your agents drive conversations, and those conversations refine your strategy. The pipeline is built on four layers:

1. Events — the raw stream of things that happened (emails sent, calls held, deals won, opportunities created).
2. Findings — structured extractions from those events (a pain point mentioned, an objection raised, a competitor cited).
3. Insights — aggregated metrics across findings (win-rate lift per entity, library health, competitive landscape).
4. Reports — narrative analyses synthesizing findings and insights on a schedule or trigger.

Each layer is independently addressable via the API and the dashboard.

​

Events

Every customer touchpoint Octave processes becomes an Event in your workspace timeline. Event categories include EMAIL, CALL, CRM, SOCIAL, ADS, RESOURCE, and REVISION. Common event types include:

• EMAIL_SENT, EMAIL_REPLY_RECEIVED
• CALL_TRANSCRIPT
• DEAL_WON, DEAL_LOST, OPPORTUNITY_CREATED, MEETING_BOOKED
• SOCIAL_MESSAGE_SENT, SOCIAL_MESSAGE_RECEIVED, SOCIAL_CONNECTION_SENT
• RESOURCE_INDEXED, RESOURCE_REINDEXED
• ENTITY_CREATED, ENTITY_UPDATED

Events are queryable through GET /api/v2/event/list and can be filtered by category, type, and time range. Most events arrive through a connected provider (Salesforce, HubSpot, Gong, Outreach and the rest). Two API surfaces take the same four kinds of activity — email, call, CRM, social — from anywhere else:

• Generic events — POST /api/v2/analytics/webhook/receive/generic/{emails|calls|crm|social}, one event per request, for n8n, Clay, Make or your own code. See Send events from any source and the Log Event reference.
• Bulk import — POST /api/v2/event/import, up to 1000 events per request with mixed types, ingested asynchronously behind a job you poll on GET /api/v2/event/import/status. See Load events from your data warehouse and the Bulk import reference.

Events from either surface behave exactly like events from a native integration: they extract findings, match to the Library, attach to deals and feed outcomes.

​

Findings

A Finding is a structured extraction from an event — a specific signal Octave detected, tagged with a type and linked to the Library entity it relates to. Findings are the atoms of conversation intelligence. Findings are queryable through GET /api/v2/finding/list and can be filtered by type and time range. POST /api/v2/finding/search takes a natural-language description instead (for example “security concerns raised by buyers”) and can narrow by event type, company, deal outcome, call purpose, linked entities, or who said it. Findings from a Custom Extractor are ordinary findings; filter to them with customExtractorOIds. To go from a finding back to the conversation, GET /api/v2/event/get returns the event with its participants, findings, and optionally the full transcript or email body.

​

Call transcripts

Two endpoints read recorded calls directly, returning verbatim, speaker-attributed quotes with recording links and timestamps:

• POST /api/v2/transcript/search: semantic search across calls, filterable by company, Library entity, speaker side (the customer’s words or the rep’s), persona, deal outcome, sentiment, and date. Results are grouped with their CRM opportunities, so they read as won-deal or lost-deal precedents.
• POST /api/v2/transcript/entity-evidence: the best customer quotes backing a specific Library entity, such as a persona pain or a competitor claim.

​

Insights

Insights aggregate findings into the metrics that drive day-to-day GTM decisions. The Insights API surfaces six views, each scoped to a period (week, month, or quarter): These power the dashboard charts directly and are designed to be embedded in your own BI tools.

​

Event analytics

Insights are precomputed per period. The event analytics endpoints answer ad hoc questions instead: each one takes a date window plus the same filters as GET /api/v2/event/list (channel, event type, company, deal stage, linked Library entities, and more) and computes over exactly the events that match.

​

Comparing cohorts

POST /api/v2/event/compare tests whether deals in one cohort (for example, deals where a specific competitor came up) outperform deals in another, or every other deal. It compares win rate or a leading outcome: whether the deal advanced within a set number of days, moved faster than the stage median, or had a positive next conversation. The response is built to keep conclusions honest. It gives each cohort’s rate with a 95% interval, the gap between them with its own interval, and a verdict: insufficient_evidence, no_material_difference, difference_to_watch, or difference_to_investigate. It also defines every number, lists caveats, and when the answer is unsettled, says how large a sample would settle it. POST /api/v2/event/cohort-deals lists the exact deals counted on either side, so you can check the comparison deal by deal. Each of these endpoints has a matching tool on the Octave MCP server that takes the same inputs.

​

Reports

Reports turn findings into narrative analyses on a schedule or in response to a trigger. The reporting system has three layers:

• Report Group — a recurring schedule or push-triggered analysis (scheduled or push, aggregating day / week / month).
• Report Config — one analysis within a group: the prompt, system prompt, logic version, and the filter selecting which events and findings flow in.
• Report Run — an individual execution producing a titled, summarized report with ordered sections and an optional comparison against the previous run.

Each Report Run returns AI-generated title and summary text plus an array of Report Sections — topic, narrative details, and the count of supporting findings each section is grounded in. Report Groups can be triggered on schedule, on cluster creation, on outcome creation, or when specific event types are processed. API surface:

• GET /api/v2/report-group/list and GET /api/v2/report-group/get — manage and inspect report groups
• GET /api/v2/report-config/list and GET /api/v2/report-config/get — manage individual report configs
• GET /api/v2/report-run/list and GET /api/v2/report-run/get — list and read report runs and their sections

​

How findings feed back into the Library

When Octave detects a recurring pattern in findings — a new objection appearing across multiple calls, a competitor gaining mention frequency, a value prop landing in won deals — it generates a suggestion to update the Library. Suggestions can propose creating a new entity (a new Objection, Competitor, or Buying Trigger) or refining an existing one (adding a newly discovered pain point to a Persona, updating a Motion ICP narrative, attaching a new proof point). Motion ICPs consume these findings directly as learnings — KEY_LANGUAGE, INDUSTRY_TREND, PAIN_POINT, VALUE_PROP, OBJECTION — each carrying a confidence score and evidence count. Your team reviews and decides suggestions from the dashboard, via the API, or through an AI assistant. Accepted suggestions update the Library — which immediately changes what every agent and workflow sees on the next run — and every applied change is recorded as a Revision. See Suggestions and Revisions for the full learning loop.

​

The result

Every conversation makes your system smarter. A call where a prospect raises a new objection today becomes a structured Objection entity tomorrow, attached to the right Motion ICP, and pre-handled in every relevant outbound email going forward. A lost deal against a new competitor becomes a competitive Motion Playbook within days, not quarters.