Since the transition to cloud two decades ago, we have Salesforce to thank for making it close to heresy for a typical company to consider building GTM infrastructure.
Teams could focus their energy not on building a CRM, but on optimizing the top 0.01% of their systems that most came in contact with their customers.
Think: customizing pre-built workflows. Ad and email creatives. Projects where their company DNA showed. This is where they found competitive advantage.
The last six months have felt different. With AI coding, leaders are asking whether to build, not buy, more of their GTM infrastructure.
Every week we talk to leaders who’ve tried to DIY their context storage infrastructure. Then they come to us because they can’t get it to be accurate enough, maintaining it is impossible, and they get no competitive advantage from it anyway.
Let's take a look at exactly why it doesn't work.
You wouldn’t design your own CRM, data warehouse, or call recorder software. That’s what we call your type 1 context. It’s the tracked events, data, and raw sources of your business.
Similarly, the architecture of your type 2 context isn’t something you should be optimizing on your own. Type 2 context is the description of your PMM-blessed GTM strategy, like personas, segments, product information, common objections and responses, etc.
When we meet folks who’ve tried, they basically realize they’ve pulled a thread that’s connected to a pretty big sweater.
The accidental DIY snowball
Let’s say you’re making Claude agents to generate account plans, write outbound messages, and qualify leads. You know they’ll perform better if you provide an ICP definition and other context.
You copy-paste your company’s ICP definition into an .md file and attach it. It works fine.
So you make another agent. It needs territory definitions. So you make put those in an .md file and create a folder to point Claude at. Works well too. After that, you add persona definitions. Even better.
All this context is getting great results out of your agents! Now your team wants to use it.
But it’s stuck on your local terminal. How do you share it? You put it in a git repo. That was a little annoying to learn, but Claude got you through.
Your teammate suggests embedding all your Gong transcripts and dumping them in a vector db. No one in the org knows exactly how that works, but Claude sets it all up for you! And then, heck, you decide to add all your CRM data too – you do a one-time export.
Your agents are cooking with all that rich info. But it decays as weeks go by.
Who will add the latest Gong transcripts? There were 40 in the last few days alone. You’re busy.
Who will update your personas and product description when PMs release new features? Your PMM doesn’t know how to push to a vector DB.
How can you link your repo to your CRM for the latest deal data? IT blocks you.
Now that so many people in your team are trying to use your context, it needs:
- Versioning
- Owners with access
- Rollouts
- Testing
- Evals
- Integration maintenance
- … and a slew of architecture decisions
Suddenly, you’re building real software to maintain.
And it's tied to your mission-critical revenue workflows, so it must always be production-ready.
Any staleness or errors in the context compound as more teammates and their agents use it.
Why is it so difficult to build context storage?
Creating the first version of your type 2 context graph — a static graph like a Karpathy wiki to hold your GTM strategy — is not a technically difficult task.
But to get it to be truly precise and accurate ... that just isn’t enough.
A good type 2 context graph needs to answer:
- 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?
- & much more
At Octave, we’ve baked 4 years of our accumulated judgment into an opinionated graph. Building the container is the easier part, filling it is the harder work.
You can’t compress years of learning. We needed to wait for exceptional deals to come along and break our logic, then building new logic, then wait for deals to come along and confirm it.
There's also the issue that, when you provide flat type 2 context, like an .md file or Google Doc or folder of files, you miss out on the relationships between entities. In robust type 2 context storage, there’s a Cambrian explosion of relationships to maintain.
One deal in your CRM might be attached to 5 personas, 2 segments, 15 pains, 8 use cases, 3 objections, etc. It’s attached to 8 calls with 300 unique findings about their current technologies, their struggles, and more.
Then, there’s the task of keeping it updated.
Octave’s secret sauce is that it compares your library with the conversations that are happening. This lets it suggest updates to your library based on evidence it finds in conversations.
(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 an aha-moment about a pain in a customer quote, that pain might already appear in your library. Octave can tell you that this CISO is talking about a pain that appears on the CISO persona entity. It links that persona entity, as well as the entity for that company's segment, and more. A
And Octave not only tags a finding with a matched entity, but also with the closest match entity. If many similar findings start skewing to the closest match entity, Octave can create a suggestion to link the pain to another persona.
But if CISOs keep speaking about a pain that’s not in your library yet, and Octave accumulates enough evidence, it can create a suggestion to consider adding it to your library. We've designed smart thresholds so that suggestions come only when they're warranted
That's a challenge to maintain. Octave has built this logic over time, informed by the broader context of your account activity. For example, if you process a high volume of calls every week, the threshold for suggestions may be higher than for an Octave user with fewer calls.
Keeping these machines running together is difficult. You need all of these to talk to one another:
- Integrations to ingest conversations
- Extractors to annotate the conversations & find meaning
- The ability to re-annotate with new labels when you change your library (like adding a competitor or persona)
- Resolving the identities of speakers on calls & connecting to deals in your CRM
- Linking conversations to deals and entities in your library (extreme permutations
- Learning loops and holding pens to keep an eye on discrepancies and potential suggestions if they meet an evidence threshold
- Learning loops that compare your context to the outside world – (e.g., what news is happening in your industry and your customers’ industries)
- MCP connectors so that Claude and any other agent can tap into your context when it’s producing answers for your sales reps, or content for your marketing team
- & more
Plus, there’s versioning, access control, evals, and other core software tasks needed for production-ready GTM software.
Do you really want to build all this?
It’s easier to answer the question when you think about whether your company’s core competitive advantage is context storage. It probably isn’t.
In 2015, Dropbox made a transition from “buying” to “building” that made perfect sense. It moved off AWS S3 to start hosting its customers’ files in its own data centers. By bringing storage in-house, it could optimize it from top to bottom, better delivering what Dropbox is known for: storage.
Netflix made the opposite move from building to buying. It shut down its last data center in 2016 for 100% cloud storage on AWS S3. By “buying,” Netflix could focus its “build” genius on what it’s known for: like optimized video delivery and world-class go-to-market. Like Neftlix, you can choose where to place your bets.
