Build or Buy: The Real Math on In House Healthcare AI Agents

Almost nobody is deciding whether to train a model. Foundation models are bought or accessed by API in either scenario, and the difference in output quality between a good vendor product and a competent internal build using the same underlying model is usually small.

What you are deciding is who owns the twenty or so things around the model: the integration into the EHR, the retrieval layer, the evaluation harness, the monitoring, the audit log, the access controls, the incident process, the on call rota, the change management when the model provider ships a new version, and the person who answers at seven in the morning when a clinic cannot document. That list is the product. The model is a component of it.

Framed that way the question becomes tractable. You are choosing between renting a platform with a service level commitment and an indemnity, or standing up an internal one and carrying both yourself, permanently. The right answer depends on whether the workflow is differentiating, whether a vendor serves it adequately, and whether you already have the engineering function rather than intending to build one.

The failure mode is a build justified on the cost of licences alone. Licence cost is the most visible number and the least complete one, and comparing it to a build estimate that stops at first release is the single most common way this decision goes wrong.

A realistic scope, based on what we see teams discover in sequence rather than in advance.

• The agent itself. Prompting, tool definitions, orchestration, retries, guardrails. This is the part teams estimate accurately and it is a minority of the work.
• Integration. Authentication, context passing, reading clinical data, and writing structured data back under clinical governance. Write back is consistently the largest single item and consistently the last one scoped. It varies enormously by platform, which is why our Epic and Oracle Health integration notes read so differently.
• Evaluation harness. A held out set of real cases with expected outcomes, run automatically on every change, including the adversarial and edge cases. Without it you cannot safely change anything, which means you will stop changing it.
• Monitoring and drift detection. Per action outcome tracking, alerting on anomalous action mixes, and periodic quality sampling by a clinician.
• Audit log. An exportable record of inputs, actions, systems touched, outcomes and escalations, retained per your policy and queryable by people who are not engineers.
• Controls. Action allow lists, volume and spend caps, escalation triggers, a reversal path per action type, and a kill switch somebody has tested. All of these are required for anything acting autonomously, as we set out in agents, copilots and automation.
• Model lifecycle management. Providers deprecate versions and change behaviour. Somebody has to re run the evaluation harness, decide, migrate and communicate, on the provider's schedule rather than yours.
• Support and on call. Clinical hours coverage at minimum. This is the item most often assumed to be absorbed by an existing service desk that has no ability to debug an agent.
• Documentation and governance evidence. Everything your own governance committee would demand of a vendor, produced by you, about you.

Read that list as a product roadmap rather than a project plan, because it does not end. The evaluation harness, the monitoring and the model lifecycle work continue for as long as the agent runs.

This is where most build cases quietly fail, and it fails on retention rather than on hiring.

A minimum viable standing team for one production agent, in our experience, is a technical lead, one or two engineers who can work across the model layer and the integration layer, a data or evaluation engineer who owns the harness, and a fraction of a clinical informaticist who owns quality review. Security, privacy and platform infrastructure are drawn from existing functions but consume real capacity from them. That is roughly three to four full time equivalents of dedicated engineering before you have a second agent, and the second agent adds less than the first because the platform is shared.

Two structural problems follow. The first is compensation: health systems compete for these people against technology employers, and the gap is wide enough that the successful hires are usually motivated by mission, which is a real but fragile retention strategy. The second is the bus factor. A two person team that built an agent nobody else understands is an operational risk that will be discovered at the worst moment, and documentation does not solve it because the knowledge that matters is tacit.

Ask the question directly before committing: if the two people who build this leave in eighteen months, what happens to the system? If the answer is that it freezes, the build is a project rather than a capability, and projects that cannot be changed cannot be governed, because governance requires the ability to act on what monitoring finds.

We do not publish dollar figures here because they vary by an order of magnitude with scale, and a made up number is worse than none. What is stable is the shape: which cost lines exist in each option, who carries them, and which are routinely underestimated.

The honest summary is that buying front loads a recurring, predictable cost and caps your downside, while building converts that into a large capital cost plus a smaller but permanent operating cost plus unbounded liability. Organisations with strong engineering functions and long time horizons can win that trade. Most health systems do not have the second condition even when they have the first, because the leadership that approved the build is rarely the leadership that inherits year four.

One more asymmetry worth naming: vendor pricing in this category is still moving, and mostly downward per unit as competition increases. A build case justified against today's licence prices is competing against tomorrow's, and that is not a favourable comparison. Current published pricing, where it exists at all, is collected in our AI scribe pricing comparison.

You do, entirely, and this is the line that should carry the most weight and usually carries the least because it does not appear in a spreadsheet.

When you buy, the vendor signs a business associate agreement, carries insurance, indemnifies you within negotiated limits, and has a security programme that has been examined by other customers' auditors. When something goes wrong there are two parties, a contract and a documented allocation of responsibility. Your HIPAA obligations do not transfer, but the operational and financial exposure is shared.

When you build, you are the developer. Every question a vendor would have to answer becomes a question about your own engineering: how the model was evaluated, what the failure modes are, what testing was done on the populations affected, whether you monitored for drift, whether you acted on what you found. You are also the party that has to determine whether what you built meets the definition of a medical device and, if so, what that requires. See FDA oversight of AI enabled devices for where that line sits, and take regulatory advice before you assume it does not apply.

State law is moving in the same direction. Several states have enacted AI statutes with obligations that attach to developers as well as deployers, and building makes you both. Colorado, California, Texas and Utah have each taken different approaches, and organisations with European exposure face the developer obligations in the EU AI Act as well. Structuring your programme against the NIST AI Risk Management Framework helps here, because it gives you a recognised structure for the documentation you will now have to produce yourself.

None of this makes building unacceptable. It makes it a decision that legal and risk should be in the room for, at the point of the decision rather than at the point of the incident.

Rarely, and the cases share a shape. All four conditions should hold, not two.

1. The workflow differentiates you. It is something you do that peers do not, and doing it better is part of why patients, clinicians or payers choose you. A build that replicates a commodity workflow is paying a premium for a worse version of something you could rent.
2. No vendor serves it adequately. Verified by actually looking, not assumed. The most common justification for a build is a requirement nobody tested against the market, and the category moves fast enough that a scan from eighteen months ago is out of date.
3. You already run platform engineering. Not intend to. If you do not currently operate internal software with an on call rota, an evaluation practice and a release process, the agent will be the forcing function for building all of that, and that programme is much larger than the agent.
4. You can carry the liability and want the option value. Explicitly, with legal and risk having said so in writing, in exchange for the genuine benefit that you are not dependent on a vendor's roadmap or survival.

In practice the cases that meet all four tend to be narrow orchestration layers on top of bought components rather than whole products: routing logic that encodes your own clinical protocols, a triage policy specific to your population, an internal referral pathway that reflects a network structure no vendor models. These are small, they are genuinely yours, and they sit above vendor products rather than replacing them.

The cases that meet none of the four and get built anyway are usually driven by one of three things: a licence cost that looked large in isolation, an engineering team looking for a strategic project, or a belief that internal control equals lower risk. That last belief is the most expensive, because internal control without an evaluation harness and a monitoring practice is not control, it is opacity with a familiar logo on it.

Most sensible programmes end up here, and it is worth naming the options rather than treating this as a binary.

The second row deserves particular attention because it is where the market is moving and where the marketing is loosest. A vendor platform that lets your team configure agents is not the same as building, and it is not the same as buying a product. You get real control over the workflow and you inherit real responsibility for its behaviour, while the vendor retains control of the substrate. Be precise in your governance about which side of that line each obligation falls on, because the ambiguity will otherwise be resolved during an incident.

A pragmatic sequence for a system with genuine engineering capacity: buy for everything commodity, use the bought deployments to build internal competence in evaluation and monitoring, and only then consider building the one or two workflows that are actually yours. The competence transfers; starting with the hard build does not.

A sequence that takes a few weeks and produces a defensible answer rather than a preference.

1. Write the workflow down as performed. Not as designed. The differentiation question cannot be answered against an idealised description.
2. Scan the market properly. Include vendors your EHR partner integrates with and vendors it does not. Score against your requirements before seeing demos, using something like our pre demo compliance checklist, and record what you could not verify.
3. Size the build honestly. Every line in the table above, including maintenance at a realistic annual percentage, model migration and on call. Have an engineer who will carry the pager review the estimate.
4. Get legal and risk to state the liability position. In writing, for both options, before the decision.
5. Test the talent assumption. Can you hire the team at your compensation bands, and what happens if the two key people leave.
6. Decide against a written threshold. Which is a decision, not a preference, and can be revisited on evidence later.

Run that sequence and the answer is usually clear, and usually buy, with one or two genuine exceptions worth doing properly. That clarity is worth more than the decision itself, because a build entered with clear eyes and a funded maintenance line succeeds far more often than one entered on optimism about licence savings.

If you would rather have the market scan and the build estimate produced by someone with no stake in either answer, that is what our vendor selection and deployment roadmap engagements are for. We take no vendor commissions or referral fees, which is the only reason a build versus buy recommendation from an outside party is worth reading at all. Where the decision is buy, the failure patterns that follow are covered in why AI pilots fail in healthcare.