Build vs buy is the oldest dilemma in software engineering. We have argued it over build servers, over cloud vs on-prem, over every framework. The fundamentals never changed. AI only amplified them.
The conversation still starts with cost and speed. I have spent two years on the build side of the agent version. Cost is the second question.
The first question is simpler and harder: is this capability core to how your teams work, or is it plumbing?
The differentiator test
Core looks like this. Your review standards. Your compliance gates. The domain knowledge that lives in your prompts and your evals. I have seen this directly. Our backlog-management agent works because it knows how our teams actually work: persona-based agents tuned to our scrum workflow, our boards, our conventions. A vendor can sell you a generic agile bot. It cannot sell you that. It is yours or it is nobody's.
Plumbing looks like this. Generic summarization. Generic chat over documents. Commodity pieces every vendor does the same way. Building those distracts from the work that actually differentiates you.
Build what makes you different. Buy what makes you the same as everyone else. The hard part is being honest about which is which.
The curated experience
Right now the tempting version of "buy" is a generic chatbot wired to your MCP servers. It demos beautifully. Ask anything, it calls tools, it answers.
But a chatbot answers questions. A curated experience does the job. Our backlog agent doesn't chat about scrum. It runs the workflow: triage, assignment, follow-ups, with our opinions about how we work encoded in. That curation is the differentiator. The generic bot is plumbing with a friendly face.
The costs that stay with you either way
Here is what the buy pitch leaves out. A vendor sells you the capability. It does not sell you the accountability. Integration, evals, data plumbing, owning the failures. Those stay in-house whether you build or buy. The buy decision is often priced as if ownership transfers with the contract. It does not.
Then there is lock-in. The deeper a vendor's agent embeds into your workflow, the harder it gets to customize around your edges or to leave. Slowly your process starts shaping itself to their product. That is the wrong direction. So price the bid in the currency you will actually pay: your own on-call hours.
This is where pilots die. The demo works. Production has owners, evals, and edge cases. Nobody budgeted for the second list.
The teams that catch this early ask their questions before the demo ends. Who owns it in production? What is the eval? What happens when it fails, and who gets paged? What does it cost per run? If those answers do not exist yet, you are not evaluating a product. You are watching a demo with a budget.
The phased path
There is also a timeline version of this. Buy for the scale you need today, build in parallel for what will differentiate you tomorrow. Run the vendor for speed now, staff the build track from day one. That way you learn your own domain instead of renting someone else's understanding of it. Best of both worlds, as long as you are honest about which track each piece belongs on.
A reply to the original post sharpened this into something testable: keep the vendor running as the control group while you build, so your evals have a real baseline to beat. The phased path stops being a hedge and becomes a measurement. Your build has to beat the thing it replaces, on your own workloads, or the honest answer is to keep buying.
The platform is the moat
Underneath all of this sits a pattern. Build the platform, then make the build-or-buy call one vertical at a time. The platform is the general layer every agent needs: memory, tool access, guardrails, evals. The agents layered on top of it, each tuned to one job, are individual decisions. Some you build. Some you buy. The call gets easier, and cheaper to reverse, once the layer underneath is yours.
Our own version of this grew out of an orchestrator: one control plane where agents get discovered, routed, and governed, instead of every team wiring its own point-to-point version and calling it a strategy. Sprawl is what happens when every team answers the build question alone. A platform is the answer given once, properly.
The eval layer is where this gets decided. Another reply to the original post framed it as renting the truth layer: whoever defines "this run was good" owns the agent. Own the definition of good, rent everything else. Evals are where that definition lives, which is why the eval layer stays in-house even when almost everything around it is bought.
The platform is the moat. Everything on top of it is a procurement decision.
For the teams running agents in production: what is one thing you built that you now wish you had bought, and one thing you bought that you ended up rebuilding anyway? I am collecting the patterns.