Every revenue team is asking the same question right now:
“We have thousands of call recordings, years of email threads, a CRM full of deal history. Why don't we just point Claude at them and extract the insights ourselves?”
We sat down with Octave’s technical team to understand why. What makes Claude, RAG, call recorders like Gong, and DIY solutions get it so wrong?
Until we share the deep dive, here’s a preview of 8 things under the hood of Octave that are most difficult to build.
These contribute to the bigger engine that generates intelligence and agent context for more precise and accurate insights and content.
Before we dive into them, we need to acknowledge the most difficult ingredient to DIY: time.
Our team has been — and we say this with affection — unreasonably tenacious at whack-a-mole’ing edge cases over the last 4 years. This happens as slowly as your deals and market move, not as fast as you can build. You have to build something, wait for a deal that breaks it, design new logic, wait for more deals to confirm or break those decisions, and repeat.
You can build a demo in a weekend, and we know how fun that feels, but you can’t compress years of iteration cycles.
The cost of getting it wrong
What’s dangerous about most intelligence tools, whether DIY or off the shelf, is that their incorrect answers look good on the surface.
For example, a Gong sales call gets an “A” grade because the customer’s sentiment is positive, and the talk time and question counts look good.
But when you really look under the hood, it turns out the rep failed to bring up the standard kill-shot for a common objection. Or they showed a financial services case study to a healthcare buyer. This call is actually a miss because the tool didn’t know what “good” really looks like.
Tools also tend to look for what they know.
Imagine you ask Claude to find objections in your last 20 call transcripts.
It may skew toward finding pricing objections, but you might not realize that customers are describing security concerns with phrases you don’t realize you should scan for. If security objections are what’s actually killing your deals, you may never know.
In our next technical deep dive, we’ll share specifics about how Octave solves these problems with catch-all annotations and a library that holds what “good” looks like. For now, here are a few of the things that are hardest to DIY when you build an intelligence tool, ranging from “annoyance” to “technical hornet’s nest.”
Integration maintenance
Ingesting source material: Medium difficulty
You’ll need to maintain a lot of integrations for a truly comprehensive intelligence tool. This means staying on top of the format of data coming in, and standardizing the messy upstream inputs into something that your downstream engines can process consistently.
They break constantly, because vendors change their data schemas and API’s deprecate. It takes a lot of opinions, testing, and seeing it break a lot.
Octave extracts insights across many sources, including meetings, emails (sent/replies), CRM changes (opportunities created, deals won, deals lost), LinkedIn messages, ads, and product telemetry from your data warehouse.
It also indexes (and refreshes) resources like your website, Notion, Google Drive, Linear, GitHub.
It’s not technically difficult, but do you really want to maintain integrations with Fathom, Gong, Salesforce, HubSpot, Notion, Google, Linear, Snowflake, Databricks, GitHub, and more?
Filtering irrelevant convos
Scenario understanding: Medium-to-hard difficulty
A transcript arrives. Is this a sales call or a support escalation? A prospect or an existing customer? Net new or upsell? Which product?
People assume that a call just attaches to an opportunity in your CRM, and that’s enough context to discern the scenario. But in practice, CRMs are rarely clean enough to support this.
Octave has built the logic to detect what’s what. For example, we filter out internal calls, or if someone on a call mentions a certain phrase, we drop it. We're a "bouncer" that turns away conversations that aren't eligible for analysis.
We created this logic by hand-building it over time. Half of that comes from our time spent in the narrow domain specialty of B2B GTM, and half comes from referencing your company’s Octave library to increase the bouncer’s comprehension. Your GTM ontology is like giving the bouncer glasses with the right prescription to see clearly.
Resolving speaker identities
Speaker attribution: Medium difficulty
Knowing who’s speaking is very important, not just because you want to understand a specific deal, but because you want to see patterns in your GTM.
If you know their title is CMO, then you can start detecting patterns across all CMO’s. If you know their company too, then you can start saying, “executives at companies with over $100M in funding tend to worry about X.”
So if your call transcript only gives you the speaker’s name or email, how do you know which Mary at Microsoft is mary@microsoft.com? Octave maintains a database of people and companies to quickly resolve identities. This includes firmographic and funding data, which helps match companies to segments.
This isn’t super challenging to build, but the data expense can add up, and making mistakes has a big impact.
Call annotation
Annotating findings: Extremely difficult
We tag every call, quote, conversation with extracted findings and the entities in your library they match to.
Octave casts a very wide net to annotate snippets. We maintain a quickly growing set of over 150 extraction types to label meaningful phrases.
We tag findings with information like the speaker, their email, a persona ID, a company domain, the segment IDs, deal outcome, opportunity ID (like HubSpot ID), an event ID (for example, a specific call), sentiment, window of the call, entity IDs (if the snippet is about a competitor, use case, objection), the literal quote snippet, and more.
Again, this is informed by a combination of (1) our years of building B2B GTM-specific extractors and (2) your specific company’s GTM ontology in your Octave library. This means that your specific personas, use cases, and product information inform the extractors how to behave and what to look for.
This opens up a whole universe of questions to ask with reliable answers:
- Find all the objections on our deal with Acme Co.
- Find everything that CTOs and CISOs say about security reviews
- Find anything related to switching costs and rip-and-replace, organized by size of company talking about it
- Figure out why customers switched away from Competitor A to us, divided by persona
And what happens when you change something about your strategy? Don’t you want to go back and re-label past calls to understand them in a new light? This brings us to our next point…
Transcript updates
Updating call transcript annotations: Difficult
If you add a new competitor to your strategy, or launch a new product use case, you now need to go back and update the transcript annotations you’ve processed in the past.
Otherwise, you can’t ask, “look for companies that would benefit from this new use case” and see historical answers.
Octave updates transcript annotations automatically when you make a change to your Octave library, retroactively extracting new intelligence based on information you didn’t know about at the time of originally processing the transcript.
Context graph
GTM ontology (Octave Library): Medium difficulty
Creating a library of your GTM strategy (or type 2 context) is not a technically difficult task. However, it’s a bundle of opinions that have an effect on returning precise and accurate answers. For example:
- What counts as a persona, and what doesn’t?
- What are its edges?
- Why is this persona subordinate to that segment, but not another?
- How do you know when your product feature “solves” a common problem for that persona — versus just “relates” to it?
We’ve baked years of our accumulated judgment into these opinions. Building the container is the easier part, filling it is the harder work.
Reality vs. strategy
Reconciling call insights with Library: Difficult
Octave’s secret sauce is that it compares your library with the conversations that are happening. Your library is like your hypothesis of what your GTM strategy should be, while the conversations are reality. Octave is always checking one against the other.
So every time Octave finds meaning in a quote from a customer, it might already appear in your library — this CISO is talking about a pain that appears on the CISO persona entity. If so, it links that finding with the library entities for that pain, that persona, the segment the CISO is in, etc. Octave not only tags a finding with a matched entity, but also with the closest match entity.
If CISOs keep speaking about a pain that’s not in your library yet, and Octave accumulates enough evidence, it can create a suggestion. Designing smart thresholds so that suggestions come only when they're warranted is a challenge to maintain. Octave has built this logic over time, informed by the broader context of your account activity.
Orchestration
Connective tissue: Extremely difficult
The hardest part of all this is to keep all these machines running together.
Hundreds or thousands of findings stream in from the 10 calls your sales reps had in the last 15 minutes alone. Octave is annotating them, attributing them to speakers, and then checking them against the library.
If something exists, it’s linking the entity, and if it doesn’t, it’s putting the finding into a holding pen. Batch jobs are deciding, right now, whether the accumulating evidence would warrant a suggested update to the library to fill in that gap. While the decision’s being made, five more calls are landing — their findings are either strengthening the case, or they're not.
So what do you do about the suggestion? Do you have look-back windows to help with that decision making?
And then imagine that you update an entity in your library: your competitor announces a new feature, so you add a line to that competitor's entity in your Octave library. This change cascades to all the other entities it touches — personas, playbooks, use cases, pains, and more.
There’s a Cambrian explosion of relationships to maintain. One deal in your CRM is attached to the findings database through every annotated snippet from calls and emails with that company. It’s also attached to library entities (segment, personas, use cases, objections they raised, etc). It’s attached to the resolution layer — the real-world identity data that made the persona-and-segment matches possible.
A deal is also attached to the outside world: the market that company plays in.
So Octave is built on two context streams:
- Internal stream: everything your business generates, like calls, emails, deals, documents, etc.
- External stream: news from the market, competitors, customers, their markets, industry shifts, micro and macro trends, etc.
The learning loops for each of these are constantly checking against your library: does your hypothesis hold up to reality? How might it need to change? How is it spot on?
And every accepted suggestion to update the library updates what the extractors look for in your call intelligence — the next calls are read more sharply, and all the calls that came before it.
Nothing in the graph is static, and that’s the machine you’d be signing up to build.
This is just a peek of what’s under the hood of Octave. If you have questions for our technical team, please get in touch — we love hearing how people have been figuring out DIY!
