The Build vs. Buy Decision for Systems of Action

Julia Nimchinski:
And next up, we’re excited to feature Terrence Ben-Kane-Williams, VP of Sales, and we will walk through the three stages of maturity and the build-by or both question. Ben, how have you been?

Ben Kain-Williams:
Hey, Julia, good to see you. Excited to be here.

Julia Nimchinski:
Yeah, great. Take it away.

Ben Kain-Williams:
Awesome. All right. Well, first and foremost, thanks for having me. I’m gonna share my screen quickly, and then we’ll jump in. All right, before I begin, I want to put a stake in the ground.
We have a thesis here that most AI projects that started in your company this year, and I know there are some because pretty much every company is trying to build right now. are going to be killed or quietly shelved by the end of next quarter. And it’s not going to be because the technology didn’t work, it’ll be for three very specific reasons.
that nobody’s thinking about until they’re 6 months into the build, a couple hundred thousand dollars in, and learning the hard way. That’s what we’re going to walk through today. I’ve spent the last 12 months in conversations with over 100 heads of sales and rev ops, and the question that is coming up from everybody is no longer, should we use AI?
I think everybody has passed that point. The question is now. What do we build, what do we buy, and how do we know the difference? So in the next 20 minutes, what I’m going to take you through are 3 real challenges that are killing these projects.
the actual cost of trying to build them yourselves, and the framework that you can use to evaluate any vendor in the space, including Terra. So, no sacred cows here, excited to walk through it, and let’s, let’s jump into the content. So here’s the thing that nobody’s telling you. Right now, the demo always works.
In the last year, I have never seen an AI or an agentic demo fail. You’ve got clean data, you’re working with a small data set, you’ve got a few hundred calls, a handful of reps, it performs beautifully. You show your leadership team, you get the green light, and you start to build for production.
This is where it gets challenging, and this is where we see companies start to stumble. It’s pretty… it’s pretty consistent across the challenges that we see. The pressure to move here is real, and it’s justified. You know, for companies that have adopted, we are seeing 4X productivity growth rates when AI is genuinely deployed.
61% of CEOs, according to IBM, say that they’re actively implementing agents at scale, and I know of one PE fund that I spoke to last month that’s committed over $50 million to AI transformation across their entire portfolio. That’s just with one fund.
So you’ve got board pressure, your CEO has a mandate to adopt these tools, and LinkedIn is telling you that all of this stuff can be vibe-coded over the weekend, and you can replace your entire BDR, organization. That’s… none of that’s wrong. The pressure is real.
What’s missing from the conversation is what happens between the demo and production, and that’s what I want to take you guys through today. There’s 3 walls, and surprisingly, it’s pretty consistent. They show up every time, and they usually show up in a similar order. accuracy, scalability, and security.
Each one of these seems like something that should be solvable in a one-week, two-week sprint, or potentially over the weekend. None of them actually are, so I’m going to explain a little bit more about some of the challenges that exist with each of these tenants. The first wall, your revenue data lives in a ton of different systems.
You’ve got CRM, you’ve got call data, you’ve got email data, you’ve got calendar, you’ve got data living in a warehouse, maybe Gong, maybe outreach. This is going to be different for every company, depending on the type of tech stack. that you have implemented. The problem is that no single system has the full picture of that data hierarchy.
The thing about LLMs that most people don’t realize is that they will never tell you, I don’t know. That’s not how they work. They’re designed to fill in the gaps, and they’re designed to fill in the gaps confidently. And in a revenue context, forecasts, deal summaries, coaching recommendations.
Confident and incomplete information is often significantly more dangerous than just being plain wrong. I was in a conversation a couple weeks ago with the head of RevOps at a large cloud company. They’re tracking north of $5 billion in ARR, and he described the problem really well.
He said that the Achilles heel of all of these different AI systems is that they’re great until they’re not, and you don’t know which it is until you actually get embarrassed. Which… I hate to admit, is a scenario that I have personally been in a couple times, and it is quite painful. So let me make that a little bit more concrete.
Imagine a rep asks their AI, who’s the economic buyer in this Acme deal that I’m working? AI comes back, based on the CRM, the primary contact here is Sarah Chen. She’s the VP of Finance. That’s great. But the actual economic buyer is a CFO who got pulled into a call 2 weeks ago and gave a verbal thumbs up to proceed with the deal.
The problem is, that conversation only exists in the call transcript, and it never made it into the CRM, so the AI never got it. Now, that in itself is a challenge, but the part that should keep you up at night is that the rep walks into their next meeting thinking that they still need to find budget authority.
As a result, they run a completely different sales play or sales tactic. The deal ends up slipping a quarter, and nobody, the rep. the manager, the rev op, ever connects that slip back to the fact that AI actually missed that call. because the rep doesn’t know the AI was wrong.
All the manager sees is the deal slipped, and they’re gonna chalk that up to a bad conversation or poor execution. The AI is never debugged, and the same failure happens on the next deal, and the next one. That’s the real danger here.
It’s not that the system is gonna fail, it’s that the system will fail silently, and the damage can then compound across your pipeline, quarter after quarter, with nobody knowing why. So just to be super clear, this is not a model failure problem. The model answered correctly based on what it could see.
The failure is that it couldn’t see that that conversation had happened in a call that was never recorded in CRM. the underlying issue here is, like, it’s really structural, right?
The model’s only as good as the context that it gets, so if you haven’t solved the data unification problem when you’re thinking about building in-house, and it’s a genuinely challenging problem, the agents are going to hallucinate, and you might not even know that it’s happening. That leads us to the next challenge, scalability.
And this is one that I think a lot of teams discover the hard way, because they’ve built a prototype that performs very well. When it’s in a limited environment or a limited deployment. So here’s the math. Everybody, I assume, on this call has used Claude or ChatGPT and is familiar with a context window, right?
That’s the working memory of an LLM, and it’s roughly 400 kilobytes of data.
So, if we look at a 200-person sales org, all of the data associated with that, email, calendar, call recording, data warehouse, that’s gonna usually be north of 10 terabytes of data, which is roughly equivalent to the amount of all of the text files that exist in the Library of Congress.
So basically what you’re doing here is you’re asking a system that has the working memory of a single email to reason across the entire Library of Congress, and it can’t. So naturally, it does what LLMs do, and it samples. It’s gonna go in, it’s gonna take snippets, it’s going to look at representative portions.
And then it’s gonna fill in the gaps, which is exactly the problem that we just talked about. The issue here is that this is now multiplied across every interaction in your business. This is why we see demos work and land incredibly well. It’s 20 deals, it’s a few dozen calls, it’s got clean inputs, it fits comfortably in the working memory.
But as soon as you take this thing into production and put it loose in the wild, you’ve got hundreds of reps working thousands of deals, you’ve got years worth of call recording, this is where you’re going to see latency start to break down, the accuracy is going to degrade, and the pipeline summary that looked great last week is now going to service a deal that was already closed.
So while the system is degrading, there’s a… there’s an invisible workaround tax. Your head of RevOps, every Friday afternoon is sitting down, pulling data from all of your systems, and reconciling it by hand, because the AI can’t hold that full picture.
This is a cost that never shows up in a demo, but it’s the actual cost of a half-built foundation.
So, if you’re building here, the lesson is… isn’t that you just need a working RAG architecture, you need one that performs across the entire dataset, and that’s a different engineering problem, and it’s the second wall that most teams run into when they’re taking the build-first approach.
The third challenge, and this is… this is one that scares me the most as a sales leader, honestly, because the consequences land directly on you as an individual. Here’s the situation. Your Salesforce instance has hierarchy and visibility rules baked in.
Reps can see their accounts, managers can see their teams, executives can see across the entire organization. Those rules exist for real reasons. You’ve got compensation concerns, there’s competitive sensitivity, there might be regulatory compliance issues, depending on what kind of an industry you work in.
When you connect an LLM directly to Salesforce via API or MCP, those rules are not going to transfer. The model queries the entire dataset by default. The consequences of this is pretty brutal. You know, I’ll give you an example.
If a rep asks AI a casual question about pipeline health, and the response includes contacts from deals and territories that they shouldn’t have access to, one, they don’t even know that they’re getting information that they shouldn’t have. Two, there’s no audit trail, right? There’s no way to see, you know, what was accessed and when.
Six months later, that information turns into a compensation dispute, a territory rules of engagement dispute, or worse, and you’re the one having to sit down with HR and legal and explain why your AI exposed compensation data across territories that people shouldn’t have access to. Now, this isn’t a hypothetical situation.
One of our customers deployed an AI capability to their European teams, like, 3 weeks ago. without giving advance notice to the security team, within, like, 3 hours, the EU team had put a hard stop on that and had rolled it back over GDPR concerns.
Now, this wasn’t because the tool was doing anything malicious, or they were doing anything intentionally wrong, but it was because the permissioning had not been thought through for the regional markets that exist within the EU.
The net effect of this was that they lost weeks of momentum and a significant chunk of internal credibility with their IT and legal organization. Another prospect had to convene a full cross-functional review of security, legal, rev ops, just to get a POC approved.
The first question in the room was, if a rep queries this, do we have a record of what they accessed? And they did not have a well-defined answer. You know, ultimately, the outcome was that the project got put on hold for almost 6 weeks, right? So the point that I’m trying to make here isn’t that security reviews are a blocker.
The point is that if you’re actually building agents, you’re not just engineering an AI agent. What you’re really doing is engineering role-based access that mirrors your CRM hierarchy and visibility rules. You need crystal clear audit logging and data residency compliance, and for every region that you operate in.
If you skip that step, the project doesn’t fail in production, it fails in a more serious conversation with your legal and HR team. Alright, so those are the three walls. Let’s say you still want to build internally. Here’s what you’re actually committing to.
You’re not just building an agent or a tool that interfaces with Slack that people can use to query data. Ultimately, you’re building a platform. You’ve got to have ETL pipelines into every revenue-facing system. You have to maintain those as those systems evolve.
You need to have a normalized data model that connects every account, deal, call, email into one schema. You need a semantic layer with governed metric definitions that finance will actually trust. You have to be hierarchy aware, and you need to make sure that that translates to access controls.
You do need to rag a layer that’s pre-indexed for performance at scale, and it needs to be self-learning, because if you’re not feeding new data to these models. They’re gonna be static, and they’re gonna get stale. So, each one of these tasks is a very non-trivial engineering project.
You know, if you put all these together, you’re looking at a platform. And to build that platform, you’ve got to hire 4 to 5 specialized engineers. You need data engineers who understand revenue systems, you need an ML engineer who can architect the RAG layer, an analytics engineer who can cover the semantic layer, plus security and product.
That’s the team, before you write a single line of code. You know. And candidly, I don’t know a lot of organizations that are fully resourced where these folks, even if they have them in-house, have the bandwidth to actually jump into these when you have the full picture of what you’re actually committing to.
This list… this slide just really, you know, illustrates the team. When I show this to… when I show this list of roles to people, I get one of two reactions. Either people say, yep, we’ve got those folks, great, and in that case, you actually might be in a position to genuinely build force.
Or the room goes quiet, because the folks that we’re talking to realize that, you know, one, this isn’t a side project for, you know, an existing data analyst or somebody on a RevOps team. The question I would pose to the audience is, do you have these rules, and what’s their availability for a 6-12 month build?
The timeline matches the team, right? You’re looking at 6 to 12 months before you have anything that is production, worthy. You know, you’re looking at $500 to a million dollars in run costs per year, if you include salaries as well as the underlying technologies. And the challenge here is that AI landscape is moving so quickly, right?
We’re, you know, we’re moving in 1 to 3 to 4 month cycles at this point, so whatever you spec as part of this project. in month zero is going to be partially outdated by the time you get to month 4. So, let me be super clear. I’m not telling you not to go build.
I’m telling that before you start building, you need to understand what you’re signing up for, because if you start, and then you discover this platform reality when you’re 6 months in, it’s not just gonna, you know, you’re not just behind, but you’ve invested a tremendous amount of time and money in a sunk cost.
They may or may not ever make it to production. Alright, so the question is, should we build or should we buy? And let’s say you decide to buy. I think that, candidly, this is the right option for most organizations, but the wrong buy can put you in a very tough spot as well.
You can end up with a better-looking version of the same problem that you set out to solve initially. So what I’m gonna walk through here are 5 questions that you should pressure test any vendor with, including Terret. The one question that matters more than the other four is this.
Does the vendor have a complete, unified data layer, or are they just querying fragments? Because if the vendor is just querying fragments, every other capability that they show you is going to be sitting on top of the accuracy problem we just talked about earlier. Just with a better UI, so always start with that question.
If the data layer is real, then the next four questions tell you whether the vendor has actually solved for the rest of the stack. Question 2. Are metric definitions governed and consistent? Because if win rate means three different things, depending on who runs a query in the tool.
You don’t have a system, you’ve got a very expensive way to have arguments with cross-functional partners. Question 3. Does it enforce your CRM hierarchy automatically, or do you have to build that? Because if you have to build it, you haven’t bought a solution, you’ve bought a bunch of work that’s going to take a long time to get through.
Question 4, can it analyze thousands of deals at scale, or just a handful? That’s the scalability question in the vendor form. And five, does it close the loop with insight to action? Let’s just be super clear about this. A document is not an action. If a rep can’t action.
The insight that’s provided as part of their workflow, you’ve actually added a step for that seller, not removed one. So if any of the answers to those questions is no, basically what you’re signing up for is a slightly prettier version of the problem that you already have.
And I would highly encourage everybody that’s attending this to take this list of vendor questions into any interaction that they’re having with vendors, you know, on a go-forward basis.
All right, so let me show you how we approach this at Territ with our Nexus product, and I want to walk through it specifically as an answer to the three walls that we just covered, not as a feature tour. At the foundation, we have our ingestion layer.
This is pre-built connectors to Salesforce, HubSpot, Gong, SalesLift, SalesLoft, Gmail, Outlook, Snowflake, Databricks. We’ve got real-time streaming pipelines. This is what solves the data fragmentation problem from the first wall. There’s no manual ETL on your side, and your data isn’t sitting in 6 disconnected systems anymore.
On top of that, this is what we call the revenue graph. This is our AI-powered entity resolution that joins all of your revenue data into one unified schema. This is what solves the hallucination problem. The model is never working off querying fragments. It’s also… it’s always working from a complete joined picture at the account level.
So if the rep is asking about the economic buyer on the ACMA deal, they’re going to get the right answer because the call transcript and the CRM record are joined at the opportunity and account level. Above this, we have the business ontology layer.
This is standardized, finance-trusted definitions of ARR, NDR, win rates, all of the key metrics that you actually use to manage and report out on your business. Every query runs, returns the same number for the same question, regardless of who’s actually asking the question. And then on top of that, we have the Nexus Query Engine.
This is the natural language to govern query. with role-based access that automatically mirrors your CRM hierarchy. This is what solves the security problem. Reps can see their data, managers can see team data, executives see the entire org. The audit trail is built in, and you don’t have to engineer any of it.
I talked about the three walls that exist for build versus buy. What I’ve just showed you are the four architectural layers that we’ve built specifically to handle them. That’s the picture of how Nexus addresses this, for our customers.
I think this is where the build versus buy conversation actually gets interesting, because the answer for most of you is going to be both. And that used to be a hard recommendation to make, because Connecting a buy decision to a build decision meant rebuilding integrations on top of the vendor, and that’s no longer true.
There’s a protocol called MCP, I’m sure most people on this call are familiar with it. It was introduced in late 2024, and it’s quietly become the standard for how AI agents talk to enterprise data sources, including ours.
What that means in practice is that if your team wants to build custom agents in Cloud, or ChatGPT, or whatever LLM environment they’ve standardized on. they can access all of that revenue graph directly via MCP.
There’s no re-architecture, there’s no rebuilt integrations, they get the unified data layer, the metric governance, the hierarchy enforcement for free on the build side. So here’s my actual recommendation. Buy the foundation.
The data layer, the semantic layer, the access controls, the RAG architecture, these are solved problems that you should not spend 12 months rebuilding. deploy that infrastructure in 24 to 48 hours, and then on top of that, build the things that are actually unique to your business.
Your specific workflows, your competitive moats, the agents that nobody else has. You know, one of our prospects who’s deep in the internal build process. put it this way. He said that the hardest part isn’t building the agent, the hard part is building the business context that makes the agent actually useful.
The connectors, the permissions, the joint data. And that’s where we see most teams get stuck. So, our recommendation, get unstuck on the front, the foundation side of things, and then spend your engineering capacity on the things that actually differentiate you. Alright, I’m not gonna walk you through every logo on the slide.
I’ll give you one example. Cloudflare, long-time customer of Terrant. They have a globally distributed sales org, multiple regions, multiple business units. And before they deployed Nexus, they had every region running a completely different forecast methodology with different definitions and different cadences.
Their CRO could not get a single trusted number to roll up. After we deployed, they had one unified forecast, they’d standardized across every region, and their head of RevOps told us that the machine forecast accuracy was effectively perfect from week one. That’s the kind of outcome that you can deliver when you have the data layer right.
Other names on the slide, Teradata, Carter, Mistral, GoTo, Udemy, they have the same story in different industries. The infrastructure works in production because we’ve spent years solving the three-wall problems that I walked you guys through before we built agents on top of it.
So, you know, in closing, Julia, and I know we have a couple extra minutes here, so I don’t know if we’re doing Q&A from the audience, but if anything came in, I’d be happy to take some questions.
I want to throw out an offer, and I want to be super specific about it, because I know you’re hearing this… a version of this from every other vendor that you’re going to hear from today, and that’s not what I’m offering.
What I’m at… what I’m offering today is to spend 30 minutes with you and walk out of that conversa… and let you walk out of that conversation with three things. One is a scorecard assessment of where you actually sit on the bill versus buy spectrum, because most teams don’t actually know that until they see it mapped out.
Two, a prioritized read on which of the three walls is hitting you the hardest right now, and give you the… and help define and give you the data to back that up.
And then three, the vendor evaluation rubric, the one that I walked you guys through on slide 10, that’s specific to your tech stack and your specific challenges, so that you can use it with us and any other vendor that you’re talking to in your evaluation. The idea here is that this would be a conversation, no slides, no pitch deck.
If that sounds useful, again, happy to, happy to find some time to connect. I’ll drop my email and my LinkedIn into the chat here, after we wrap up.

Julia Nimchinski:
Amazing. Thank you, Ben. We’ll make sure to share your contacts. We got a couple of questions here. And one of them is, were the internally built agents usually fail in production? I know that you addressed it a little bit in the governance and security Aspect, but yeah, if you can just speak to this.

Ben Kain-Williams:
Yeah, so where do most home-built agents fail in production?

Julia Nimchinski:
Yeah.

Ben Kain-Williams:
Yeah, I mean, I think… I think that really depends on the use case and the org. You know, I think the hallucination problem is a real one. You know, I can give you an example of a… An account that I was talking to a couple weeks ago, they had done a win-loss analysis, where they looked back at, you know, the previous quarter’s deal cycles.
The primary data source that they were indexing there were recorded calls from one of the leading CI providers. I think they were using Claude to run this. The RevOps leader there had analyzed something like 250, 300 calls.
They got a pretty good data set, they took that, they reviewed it with the CRO, and it, like, he immediately started poking holes in that data.
So, RevOps said, alright, let me go double check this, went back, dug into the chat, and what they found was that of the 250, 300 calls, what the… what the LLM had done was actually picked a sample of less than 10% of those. Within that 10%, it hadn’t actually analyzed the full transcripts. It had gone in and looked at the segments.
So what you end up with is a super confident-sounding answer, that’s based on a very, very limited data set. I mean, that’s one example. Again, depending on the, kind of, the use case and the complexity that exists in the orgs, there could be a whole bunch of challenges.
But I’m seeing that the completeness of the data that’s actually incorporated in any analysis that you’re trying to use is one of the real leading causes here.

Julia Nimchinski:
Ben, can you speak to Tara’s uniqueness in the marketplace? Because, we’re seeing a real proliferation of this category, and lots of alternatives, lots of solutions, and sometimes it’s really hard to make the ultimate decision, what do you actually operationalize, and not just, you know, experiment with.
And what tends to happen in our community, at least, it would get a couple of point solutions, or a couple of agentic platforms and experiment. So, what are you seeing based on your customer stories? Why you? Why now? And, yeah, let’s go.

Ben Kain-Williams:
I love it. Yeah, so I think… I think part of that depends on where a company is, you know, in their… to use a dated term, digital transformation journey, we could probably call it an AI transformation journey. You know, we have the pleasure of working with some of the most AI-forward companies in the world.
Mistral is one that I mentioned previously. They’re, you know, Europe’s leading LLM provider. And they are taking a very build-first approach. So the thing that is unique there, and that’s unique to Terret, I should say. is that we’re actually model agnostic, right? So our entire platform is a bring-your-own-model experience.
If you guys have standardized on Clod, on ChatGPT, on Gemini, on Mistral, we have the ability to plug in the model of your choosing, and then we can let you run that, and you can access the platform via MCP. Now, in Mistral’s case, they were very interested in solving some specific problems for the go-to-market teams.
The way that I frame this is we have a set of purpose-built, out-of-the-box agents in Nexus, everything from call preparation, meeting briefs, call feedback, and then rep coaching scorecards that get delivered to managers that make sense in platform. That being said, Mr.
All was also eating their own, or drinking their own champagne, and building a bunch of in-house agents using their data set. The problem that we solved on the build side for them was the infrastructure layer that I talked about in the previous presentation.
So, we were able to, one, get them a quick win for the five to six use cases that were top pain points for the go-to-market teams, but two, plug in via MCP into the stack that they were building on top of BigQuery in their infrastructure so that they could leverage the revenue graph and all the context that we’re providing into the go-to-market motion.
I would say that that’s one of the really unique things about us, is that we can support the model on both ends. It’s not an, you know, an either-or choice.
There’s things that we can do to help the sales teams out of the box, leadership, finance, but then for those orgs that are really AI-forward and are committed and down the build path, we have the ability to plug our infrastructure in, again, in, like, 24 to 48 hours without having to go rebuild any of those components that I just talked about in the presentation.

Julia Nimchinski:
And folks are asking, what does the deployment look like? Do you have forward, forward deployed engineers, or… yeah, CS? How does it work?

Ben Kain-Williams:
Yeah. Yeah, so we… so we take a… I mean, generally speaking, we take a crawl, walk, run approach to implementations. So, you know, Terra brings 3 different SKUs to the market. We have a forecasting product, we have a conversation intelligence product, and then we have Nexus, which is the agentic layer that I’ve been talking about.
in this presentation. The first thing that we want to do is align on what the high-priority use cases are. Assuming that it is agentic in nature, you know, the good news is that because most of this is pre-configured and we’ve built the infrastructure layer, we’re able to move very quickly on this.
So I would say deployment timeline from the time that we get installed can be anywhere from 1 to 3 or 4 weeks.
If we’re looking at incorporating some of the other things around forecasting that are much more process-oriented and are a core operating cadence within a business, we’re probably looking at a 4-6 weeks timeframe for implementation for some of those capabilities.
On the support side, we do have a forward-deployed engineer that will work with you closely on the Nexus deployment, any of the, you know, the specific agentic use cases that we want to work with. We also have a dedicated CS model, so you’ll have a single point of contact once you get through professional services.
To help work with you and, and manage the account on a go-forward basis.

Julia Nimchinski:
One more question here, how do you secure MCP access? It’s a big concern for our community.

Ben Kain-Williams:
Yeah, MCP access, so we… right now, we are… we will… we have an MCP client and an MCP server. So we will let customers access our entire revenue graph via MCP. Again, you think of club, you go in, you add a connector, you’d add a tarot, you can then pull in that data. The beautiful part here, though, is the security layer that I mentioned.
Because we already have your business definitions defined, your hierarchy, your visibility permissions. available from your CRM and the core implementation, all of that will flow through if somebody wants to access the tool via MCP in another LLM. On our end, we host all of the models in AWS Bedrock.
We don’t do any cross-model training or data sharing.

Julia Nimchinski:
Beautiful. And what’s the best next step?

Ben Kain-Williams:
Best next step, if you guys want to talk, we’d love to have a conversation. I’ve got my LinkedIn up there. I will socialize that, or I’m sure Julia will publish the deck after we get through this. But if you’re thinking about building, you’re not sure where to start, we’d love to have a conversation again.
Our thesis here is it’s probably a buy and a build. And just make sure that you’re asking the right questions of the, the different vendors that you’re engaging with.

Julia Nimchinski:
Amazing. Thank you again, Ben. Goodbye.

Ben Kain-Williams:
Lovely. Thanks, Julia. Great seeing you. Look forward to the next one.