Some of the most expensive AI mistakes in professional services don't look like mistakes at all. They look like wins.
Imagine your team spends a weekend building an AI agent—the kind that doesn't just draft an answer, but actually does the work. By Sunday night it's running, and you feed it notes from a sales call. In minutes, it creates a solid first draft of an SOW, a task that usually takes an entire afternoon.
By Monday, the conclusion feels obvious: why pay for tools when you can build your own?
It's easy to understand why. When something this useful comes together in two days, buying software starts to feel like paying tax for not building it yourself. The prototype feels like proof you made the right decision.
But look closely, and it isn't that simple. It's the first line on a much bigger bill, one that most companies don't see coming.
That weekend project is a small version of a bigger decision playing out in PS meetings: should we build our own agent, or buy it?
Most teams treat this as a question of cost, speed, and control. But that distracts from the question that actually matters: where your firm's advantage really lives, and whether the AI you're weighing has anything to do with it.
Build vs. buy isn't one decision anymore

For years, the 'build or buy' debate was about weighing cost against control, and speed against customization, then choosing a side. People still use this checklist in meetings, but it doesn't really fit today's AI landscape.
If you build your own, you get control. Your data stays in-house, no vendor to set your roadmap or raise your price, and the tool fits exactly how you work. For anything touching sensitive client data or a genuinely proprietary method, that control is worth a lot.
If you buy instead, you get speed and someone else's expertise. You're up and running in weeks instead of quarters, with upkeep being handled by a company whose whole business is keeping it reliable.
Both cases hold up, which is exactly the problem. As long as the question is "build or buy," both sides are right, and nobody moves.
Here's what's missing from the debate: that weekend prototype wasn't a waste, even if you never run it in production. Building something forces you to learn what your workflow actually is, where it breaks, what data matters, and where a human has to step in. That's genuinely valuable knowledge.
The mistake isn't building to learn. It's assuming that because you built it, you now have to keep it forever.
Build to learn, but buy to scale. The first agent you create might be the one you're happy to let go, because its real purpose was to teach you what you actually need to buy.
Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027, due to rising costs, unclear business value, and poor risk controls. That's what your weekend prototype doesn't reveal.
'Build AI' and 'buy AI' are too broad to be real choices. There are actually two layers: the AI engine that does the reasoning, and everything you build around it to make it useful and reliable in your business. The old checklist tries to cover both at the same time.
A better question is which layer you should own and which you should rent. If you get this right, the whole decision becomes clearer.
The hard part isn't building intelligence from scratch
Most teams think the hardest part of building an agent is making sure it's smart enough to handle real work, like sorting out complex client situations or drafting useful documents. While reasoning quality is still important, building the core intelligence from scratch isn't the main challenge anymore.
The models are increasingly something you can rent. Making that intelligence reliable inside your business is the challenging part.
In professional services, the brutal part is feeding the agent the right information. To flag that an implementation is slipping, it needs the project plan, the hours logged against it, who's allocated next week, what the client said on Tuesday's call, and how similar projects went last quarter.
In most firms, those five things live in five places. The call recording is in Gong. The account history is in Salesforce. Delivery status is in the PSA. Resource plans are in a spreadsheet. Financials are somewhere else entirely.
A homegrown agent might access one or two of these sources through an API. But it usually can't connect all five in real time, with the right permissions and identifiers, to know that this project in the PSA matches that account in Salesforce.
And an agent working from half the picture doesn't give you half an answer. It gives you a confident but wrong answer, which in client-facing delivery work is far worse.
We built a set of delivery agents at Rocketlane, and the behavior that took the most work wasn't the intelligence; it was restraint. When the agent spots a migration discrepancy overnight, it doesn't just apply the standard fix. It surfaces what it found and asks if it should resolve it or wait for your review.
Teaching an agent when not to act takes real context about the account, the stakes, and who owns the call. This is the part a weekend build rarely reaches, because that judgment isn't in the model. It's in the scaffolding around the model, and that layer always needs ongoing attention.
Industry estimates say it costs 15–20% of the original build cost each year just to keep a custom agent running. Control you can't maintain isn't an asset; it's a standing cost.
The firms getting real value aren't the ones with the most advanced AI agents. They're the ones whose delivery data was already connected, clean, and governed enough that an agent had a solid foundation to stand on.
If intelligence is the rentable part, the question that matters is what's actually worth owning.
Core versus context

Strategy writer Geoffrey Moore split everything a company does into two categories. Core is the work that makes clients choose you; it's your differentiation. Context is everything else you have to do competently just to stay in business, but that no client picks you for. His rule: own your core, and rent your context.
That's the answer to what's worth owning.
An agent that drafts an SOW, updates a project record, or flags a slipping timeline is context. Every firm needs it, but none of your clients choose you because you built your own version, and a competitor could just as easily get the same capability.
Your core is your judgment, your relationships, and the methods you've built up over years to turn a signed contract into real outcomes, repeatedly, better than anyone else.
Your core was never the software running underneath the work. It was the knowledge the software was executing. An agent can have every data point about a project and still get it wrong, because knowing everything about a project isn't the same as knowing what a good one looks like. That's the knowledge worth owning.
This leads to an uncomfortable realization: the AI you're most tempted to build is usually the AI you should buy.
The tools that feel most exciting to build, like delivery agents and automation inside your own workflow, are actually part of your context. They feel like a core because they sit so close to your real work.
Proximity isn't differentiation, and building context is how firms quietly bleed their best resources into work that can't distinguish them.
The person with the judgment to build a genuinely good delivery agent is usually one of your senior experts, the same person your clients pay the most to have in the room.
Every month they spend perfecting an internal agent is a month they're focused on plumbing more than solving client problems. SPI found billable utilization fell to 66.4% in 2025, compared to a benchmark of over 70%. Pulling senior people onto an internal build is a utilization decision as much as a technology one.
So the real question was never "can we build this?" Your best people probably can.
The question is whether they should.
So which situation are you in?
Core and context is only useful if you can practically apply it. But here's the trap: up close, everything looks like the core, so "is this differentiating?" is exactly the question you'll likely answer wrong. You need sharper tests; here are three that work:
Do clients pay for it, or notice when it's good? If not, it's probably context, no matter how clever it is.
Could a competitor rebuild it from public information? If yes, owning it isn't protecting much.
Does your own proprietary data make it materially better? If it only works because of your unique history or judgment, that's a real sign at its core. It's the layer worth owning.
Run any AI capability through these three questions, and most of them sort themselves into one of three paths.

Buy it—most of the time
Status reports that pull from live project data, migrations that run and validate themselves, timesheets suggested from the calendar for approval—if a competitor down the street needs the same capability and would use it much the same way, it's context, and you should buy it.
You already saw why: the intelligence is rentable, and the expensive part is the scaffolding around it—the connections, the guardrails, and the maintenance as the technology shifts underneath. None of that is where your differentiation lives, so it's the wrong place to put your best people.
Buy, then build on top—the path most people miss
This is the answer for the team that already built something over a weekend, or wired up a few Claude agents, and doesn't want to throw that away.
You don't have to.
Rent the foundation (the engine, the data model, the maintenance) and build the thin layer on top that captures how your company delivers. Your agents don't get scrapped. Instead, they plug into a system that can actually see across your project data, and you stop asking a homegrown tool to carry more weight than it can hold.
OneSource Virtual did exactly this. Rather than build a platform from scratch, they bought one and built a custom risk-scoring app on top of it, and tuned it to how they define a healthy project, pulling go-live confirmation from live payroll data rather than a static spreadsheet.
None of their expert time went into rebuilding the foundation everyone shares. All of it went into the part that was defensibly theirs. That's not a compromise between build and buy; it's the best of both.
Build it—rarely, but honestly
If the AI itself is what clients pay for, or your data is truly unique, or no vendor can meet a real compliance need, then build. That's your core. The mistake isn't building. It's building something from the first category while telling yourself it belongs in this one, because the work sits so close to home.
We sell a platform, so it's only fair to be upfront about where we stand.
This is the part of the framework that costs us. If you apply it honestly, it will sometimes tell you to build something we would rather have sold you, or to buy nothing at all. That's the test working. It looks for where your advantage really is.
What this is really asking of your firm

The delivery agents that feel impressive today, that can draft SOWs, run migrations, and flag risks, are commoditizing fast. Soon, every serious platform will have them, just like every tool eventually got search features.
Building your own agent now is a race against the clock. You're spending your best people to own something that gets cheaper to rent every quarter.
What won't commoditize, however, is the layer above the AI: knowing which client is about to go quiet, which scope conversation to have in week two instead of week eight, and which implementation needs your best architect.
Agents will get better at surfacing those judgment calls. They won't make them for you. So the important question isn't whether your firm should have AI agents. It's what your firm should own in a world where intelligence is a commodity.
The firms that pull ahead won't be the ones with the most AI. They'll be the ones who own what makes AI invaluable: their data, their methodology, their hard-won judgment, and the feedback loops that make all three better with every project.
None of that comes from a model. It comes from the years your firm has spent learning how to deliver, and from the people who carry that knowledge.
Rent the intelligence. Own the context that makes it valuable.































.webp)