The fastest way to stall an AI program is to start it with the words "we want to build an agent." I've watched this happen across health systems, payers, and device companies, and the pattern is always the same: a year later there's a demo that impresses the board and changes nothing about how the work actually gets done.

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027 - on cost overruns, unclear value, and weak governance. The teams that ended up there weren't short on talent or ambition. They were short on a way to decide what to build, what to buy, and how to decide between the two.

So let me reframe the question. 

"Build vs. buy" sounds like a binary, and it isn't. It's a question about layers.

It's layered, not binary

Every agent sits on three layers. At the bottom is the foundation model - the reasoning engine. In the middle is the orchestration and workflow layer: how the agent connects to your systems, takes multi-step actions, retains context, and stays observable. On top is the application itself, plus the one thing no vendor can sell you: your proprietary data and your workflow logic.

Almost nobody should be building the bottom two layers. The model layer changes roughly every eight weeks; betting your roadmap on a snapshot of it is a maintenance treadmill, not a strategy. You don't build your own cloud provider, and you shouldn't build your own agent infrastructure either. The strategic fight is at the top layer and the data and logic underneath it, the parts that are tied to how you make money or stay compliant.

This is why most enterprises have stopped choosing sides. The majority are already running a hybrid: buying the platform and the commodity scaffolding, building the logic that differentiates them. MIT Sloan has popularized a cleaner version of the same idea: buy, boost, or build. Buy when the workflow is common and speed matters. Build when the capability depends on proprietary data or is core to your edge. Boost when a platform gets you 70% of the way there and you add the retrieval, integrations, evaluation, and human-in-the-loop controls that close the gap. In regulated work, boost is usually the right answer, and almost no one frames their decision that way up front.

The business problem drives the architecture

The principle I keep coming back to is simple: the business problem should drive the architecture, not the other way around. If AI is the answer, what was the question?

Asked honestly, that question rarely points to the flashy use case. It points to the operational layer everyone finds boring: intake, verification, documentation QA, prior authorization, claims and appeals, call-center triage. That's where the hours are, and that's where the return is. Using StackAI, LifeMD ran more than 2.5 million agent actions on this kind of work and recouped roughly 475,000 hours, with patient support wait times down to about 12 seconds. It's the unglamorous middle of the operation, automated well.

In regulated industries, "buy" is not surrender

The objection I hear most from healthcare and financial-services leaders is that buying means giving up control. It's the opposite, if you do it right.

Buying the platform means not rebuilding the compliance scaffolding every regulated deployment needs anyway: environment separation between development, staging, and production; automatic versioning so every change to an agent is captured; audit trails that can show who approved what and when; identity and data-access controls; human oversight on the decisions that warrant it. That scaffolding is the part that's already solved. Rebuilding it in-house doesn't make you more compliant, it makes you slower, and it puts your scarce engineers on plumbing instead of on the thing that matters.

What you keep is the decision logic. The reimbursement rules, the risk models, the clinical or claims criteria, the proprietary data, that's the moat, and that's worth owning. 

Where teams lose time

The gap between a pilot and production is a discipline gap. Teams lose time boiling the ocean: twenty use cases scoped, none shipped. They lose it to pilots with no named owner and no quantitative success metric, so nothing ever graduates. They lose it underestimating data readiness and integrations while over-indexing on which model to use, a choice that's obsolete in two months anyway. And they lose it treating security review as the last gate instead of the first design input.

The move from idea to production is almost mechanical once you commit to it. Start from a real bottleneck. Score your candidates on value, effort, and team readiness, and pick three. Give each one an owner, a number it has to hit, and acceptance criteria. Scope the pilot narrowly and review it on a cadence. Ship the boring thing first.

Three years from now, the organizations that lead in their industry won't be the ones that built the most. They'll be the ones that decided clearly, rented the commodity, owned the logic, and got a narrow, measurable agent into production while everyone else was still arguing about whether to build.

Shani Fargun leads healthcare AI go-to-market at StackAI. She has worked on both sides of the build-vs-buy decision - in medical devices, health insurance, and digital health - before moving to the platform side. Learn more about StackAI for healthcare here.