Build vs buy vs orchestrate is a question about where your durable advantage lives, not about cost.
Most "build vs buy" debates argue the wrong axis — they compare a one-time engineering quote against a per-seat license and pick the cheaper number. The real decision is which layer of the agent you must own to have a defensible product, and which layers you should rent because owning them buys you nothing a competitor cannot also buy. Get that wrong and you either rebuild a commodity at great expense, or you outsource the one thing that was supposed to be your moat.
The decision tree has three branches, not two.
Buy a finished agent product when the workflow is generic (support triage, meeting notes) and your differentiation is elsewhere. Build when the agent's behavior is the product, or when it touches data and judgment no vendor can see. Orchestrate — the branch teams forget — when you own the workflow, the data, and the evals, but rent the model and the runtime: you assemble a foundation model, a framework, and managed tools into a system that is yours, without writing the parts that are now commodities. In 2025–2026 practice, orchestrate is the default for serious internal agents; pure build is reserved for the narrow core where you have proprietary signal.
Every path has hidden costs that the headline number omits.
The visible price is the smallest line. Buy hides integration, the data you must expose to the vendor, and the ceiling on customization when their roadmap diverges from yours. Build hides the eval harness, the on-call rotation, model-upgrade churn, and the safety/observability stack that a vendor amortized across all customers. Orchestrate hides framework lock-in and the glue code that quietly becomes a second product. The honest comparison is fully-loaded total cost of ownership over the asset's life, not the quote.
# fully-loaded TCO, not the sticker price buy_tco = license + integration + data_exposure_risk + customization_ceiling build_tco = eng_build + eval_harness + oncall + upgrade_churn + safety_stack orchestrate_tco = model_usage + framework_lockin + glue_maintenance + eval_harness # the eval harness is NOT optional on any branch — you always pay it
The eval harness appears on every branch. If you cannot measure whether the agent works, you cannot safely buy, build, or orchestrate — so build the evals first, regardless of the path. That cost is not a tiebreaker; it is a prerequisite.
Own the layer that compounds; rent the layer that commoditizes.
Stack the agent into layers: model, runtime/framework, tools and integrations, workflow logic, evals, and proprietary data. The bottom layers are commoditizing fast and getting cheaper every quarter — owning them is a depreciating asset. The top layers — your evals, your workflow encoding, your data — compound: every incident makes them better and they are not portable to a competitor. Buy or rent what is becoming a commodity; build only what gets more valuable the longer you run it.
Lock-in is a cost you pay later, priced today.
Three lock-in surfaces dominate. Model lock-in: prompts and tool schemas tuned to one provider's quirks that silently regress on any other. Framework lock-in: agent state, memory, and control flow expressed in a vendor's abstractions you cannot lift out. Data-gravity lock-in: traces, eval sets, and fine-tuning corpora that live in the vendor's format. The mitigation is not "avoid vendors" — it is to keep the portable assets (eval suite, prompts as data, an abstraction seam at the model boundary) under your control so switching is a project, not a rewrite.
Reversibility should weight the decision more than price.
A buy decision you can exit in a quarter is cheap insurance even if it is more expensive per month; a build decision that takes two years to undo is expensive even if it is cheaper per month. Weight each branch by how fast you can reverse it if you were wrong, because you frequently will be — the workflow, the model frontier, and the vendor landscape all move under you. Prefer the path that keeps the most future decisions open at acceptable cost, not the path with the lowest number this quarter.
- Cheap to reverse, cheap to run — buy and learn; revisit when you have signal.
- Expensive to reverse — only build if the layer is genuinely your moat and the workflow is stable.
- Unknown workflow — orchestrate first; the assembly cost buys you optionality.
When building is the wrong answer even though you can.
Engineering teams systematically over-choose build because building is legible and fun and the hidden costs land on a future quarter. If the layer is commoditizing, if you lack a proprietary data or workflow advantage there, or if you cannot staff the permanent eval-and-on-call burden, build is the most expensive way to acquire a commodity. Build only the thin core that is your durable advantage; renting the rest is not technical debt, it is focus.