I’ve spent most of my career building software, not selling it in the field. As a former CPO and CTO, I thought about architecture, adoption, and whether the product we shipped solved the problem it promised to. Field selling, from where I sat, was the team that took what we engineered to market.
That vantage point has turned out to be useful in an unexpected way. Now that I lead a platform whose customers are field-selling revenue teams, I’ve been watching a specific decision play out across dozens of them.
The five-year cost of building agents yourself
The decision: Buy an enablement-native AI platform built for (and by) the revenue team or build custom agents on top of the enterprise foundation model your IT organization already licenses? It’s framed as a build-versus-buy choice. It’s actually an ownership decision. And most revenue leaders I’ve talked to are answering it before they’ve asked the right questions.
The pattern: A revenue leader gets pitched — sometimes internally, sometimes by a consultancy — on building “just what we need” on Claude or Copilot. The pitch is compelling. Full control. Custom to your data. No per-seat inflation. The team allocates a few engineers, a few months, a six-figure budget. Twelve months later, they have three agents in production, a growing list of integrations requiring maintenance, no analytics on whether any of it is influencing deals, and a data processing conversation with legal they hadn’t anticipated.
The build succeeded. The decision didn’t.
This isn’t new. I’ve been through a few generations of this same debate on CRMs, LMSs, ERPs. What I’ve learned across those cycles is that build-versus-buy is almost never about capability. It’s about ownership economics. Who owns this thing at year one, year three, and year five, and what does that ownership cost when you draw the full curve — not just the sticker price at year one?
For AI on the revenue team, seven questions influence that curve. If you’re the revenue leader in the middle of this decision, I’d go through them in this order.
1. How fast does a seller get value from this AI?
A general-purpose AI model starts every conversation with an empty prompt. Your seller has to know what to ask, in what order, with what context, and then judge whether the answer is worth trusting.
An enablement-native AI platform starts with a library of agents already configured for revenue work — product comparisons, competitive positioning, prospect research, follow-up drafting, deal prep. Reps get useful output on day one, without a runbook.
Time to value is not a soft variable. It’s the difference between showing up in this year’s numbers and showing up in next year’s pipeline.
2. Who can change an agent when your positioning shifts?
If your enablement lead has to file a ticket every time a competitor launches a product or your pricing changes, you don’t have an AI strategy. You have a queue.
The right platform gives your commercial team a no-code builder — ours is Agent Studio — so the people closest to buyers can tune and deploy new agents themselves. Positioning shifts on a Monday. Agents shift on a Monday.
3. Who owns this agent when the person who built it leaves?
This one gets skipped in most build-versus-buy debates, and it’s the one that costs the most later. Custom agents built on a general foundation model belong to the person who built them. When that engineer moves on — and they do — the agent doesn’t come with a manual. It becomes a black box no one is qualified to maintain. Right up until it breaks in front of a customer.
A managed platform means someone else keeps every agent current, tested, and improving. Through every reorg. Every departure. That’s not a feature. That’s an insurance policy on your original investment.
4. What does it take to connect your revenue data to your revenue AI?
Your CRM. Your content library. Your win-loss patterns. Your pricing. Your catalog.
A DIY solution means your team owns every connector — the build, security review, ongoing maintenance every time an API changes. Permanently.
An enablement-native AI platform already knows how to talk to your CRM and your content on day one. When you need to plug in the systems that make your business specifically yours — inventory, ERP, pricing tables, dealer portals — vendor support can build those connectors in weeks, not quarters.
5. Can you prove which agents are moving deals?
Building an agent is the easy part. Knowing whether it’s used, trusted, and influencing revenue is where the value gets extracted or lost.
Your team needs to see which agents each seller uses, which show up inside closed-won deals, and which need to be retired or retuned. Without that visibility, you’re guessing on your own AI investment.
A DIY build starts with zero analytics. Your IT team will know if agents are running. Your revenue team won’t know whether they changed a single deal. An enablement platform ships with the visibility built in.
6. Who owns compliance in every region you operate in?
If you sell in the US, the EU, the UK, Canada, Australia, or anywhere else with a serious data privacy regime, this is not optional.
Who guarantees that an agent built in Chicago is GDPR-compliant in Frankfurt? Who updates it when the AI Act shifts? Who produces the audit when a customer’s procurement team asks what data an agent touched?
With a managed platform, that’s the vendor’s responsibility — by contract. With a DIY build, it’s yours. And it gets bigger the moment you extend AI to partners, distributors, or dealer networks, where off-message becomes out of compliance very quickly.
7. When your agent breaks, who picks up the phone?
Agents are software. They slow down. They get exploited. They drift. The best-designed agent in the world will have a bad Monday morning at some point.
When yours does, at 7 a.m. before your team’s QBR, who owns it? A managed platform comes with the answer — an SLA, a named team, a phone number. A homegrown one comes with hope and a Slack channel.
Seven questions, one word: ownership
Every one of these is really the same question I introduced earlier: who owns your revenue AI, and what does that ownership cost when you draw the full curve from year 1 to year 5?
You can build it yourself. Plenty of strong engineering teams can, and they’re not wrong when they tell you so. But every one of those seven answers becomes your team’s ongoing job — integrations, compliance, analytics, tuning, incident response, migration when the underlying model changes, and the awkward conversation with a departing engineer about undocumented logic.
The revenue leaders getting real return out of AI right now are the ones who started with a platform already governed and built for revenue work. They customized the two or three things that make their business specifically theirs — like their pricing logic — and put the rest of their engineering budget on problems no vendor can solve for them.
Build-versus-buy always feels like a technological decision in the moment. But long-term it’s an organizational one. You’re not really choosing between two AI approaches. You’re choosing which team owns your revenue AI for the next five years, and how much of your engineering budget goes to keeping that AI alive versus building the things no vendor can build.
From the product-leader vantage point I spent most of my career in, the pattern is consistent: the build-it-yourself decisions that aged well were the ones that solved a problem only that company had — a matching algorithm no vendor understood, a workflow the industry didn’t have a name for yet. The ones that aged badly were the ones that recreated something already engineered for the job.
If you take nothing else from this article, remember this: You’re not simply buying software. You’re choosing who owns it for the next five years.
Your revenue AI deep dive
The case for enablement-native AI from our VP of Revenue Effectiveness Vanessa Metcalf.
Frequently asked questions
You can, and plenty of engineering teams are capable of it. The question isn’t whether it’s technically possible — it’s whether your team wants to own the maintenance, compliance, integrations, and analytics for that AI for the next five years. Most revenue teams underestimate what “owning it” actually costs after year one, which is why the build-versus-buy decision is really an ownership decision in disguise.
The initial build is the smallest line item. A few engineers, a few months, a six-figure budget will typically get you two or three working agents. The larger cost shows up over the next several years in the form of integration maintenance, compliance updates as regulations shift, analytics tooling to prove which agents move deals, incident response when agents break, and eventual migration when the underlying model changes. Most DIY business cases don’t include those line items — which is why the cost of ownership tends to look very different at year one and year five.
Build the two or three things that are genuinely proprietary to your business — like pricing logic no competitor has cracked. Buy the underlying platform, the standard revenue agents, the CRM connectors, the compliance framework, and the analytics layer. The revenue leaders getting real return out of AI are the ones who knew exactly which two or three things were worth the engineering investment.
