Buy when the bottleneck is time-to-a-governed pilot and the connectors already exist. Build when data boundaries, eval hooks, and audit fields are the product differentiator—not a hobby framework bake-off. For regulated teams the default is hybrid: purchase the runtime, own the policy packs and eval sets.
This is a procurement decision, not a developer-preference contest. If tool sprawl is already the problem, freeze net-new buys first—see The AI Procurement Freeze. If the workflow is still unnamed, stop here and finish How to Design an AI Agent Workflow before either path.
Decision frame
Name three things on one page before anyone opens a vendor deck or a repo:
- Outcome — which business step the agent changes, and the metric that proves it.
- Risk class — internal assist vs customer-facing send vs money/movement in a system of record.
- Ownership — who owns context, eval cases, and the audit log when a run is wrong.
Northline B2B (composite) treated “build vs buy” as a risk-class question. A renewal-draft assistant with a human send gate could sit on a vendor runtime in thirty days. A claims classifier that had to replay every tool call for audit could not: the audit fields were the product, so they owned that slice even when the orchestrator was purchased.
If you cannot fill those three lines, you are not choosing a stack. You are shopping for a demo.
Buy when
Buy the runtime when delay costs more than license fees and you can put your own gates around the vendor:
- Connectors you need are already certified (identity, ticketing, mail) and writing them would delay the pilot past the decision window.
- You can attach your eval set and a human send gate; the vendor is not the policy owner.
- Uptime, regional residency, and vendor SLA matter more than owning every orchestration primitive.
- Your team can operate the platform’s logs well enough to replay a failed run.
Do not buy because the demo was fast. Fast demos hide missing evaluation hooks. Score the vendor on whether you can reject a prompt or tool change without a support ticket.
Build when
Build (or keep a thin internal orchestrator) when the control plane is the differentiator:
- Data boundaries, tenancy isolation, or existing SOA contracts dominate latency and residency.
- Audit fields, promotion gates, and rollback are what Legal will ask for—not a chatbot UI.
- You already run CLEAR (cost, latency, efficacy, assurance, reliability) as an operating cadence, not a slide.
- A vendor’s tool protocol would become a second permission surface you cannot allowlist.
Building first is the wrong move when you have no workflow canvas, no owners, and no eval cases. That path recreates vendor lock-in inside your own git history.
Hybrid pattern
Regulated default: bought runtime + owned context/eval.
| Layer | Buy | Own |
|---|---|---|
| Runtime / schedulers | Vendor orchestrator or agent host | — |
| Connectors | Vendor or MCP allowlist | Permission policy and secret handling |
| Policy packs | — | Versioned system/policy; changelog |
| Eval sets | — | Pass/fail cases; promotion hooks |
| Audit | Vendor export if complete | Fields Legal actually queries |
MCP can be the connector contract on either path; it does not replace eval or RACI. Pair this table with Model Context Protocol for enterprise when the question is protocol vs custom APIs—not when you still lack owners.
Northline bought the host, kept policy packs and eval YAML in a repo they promoted like application code, and refused production until a failed eval could block a release.
30-day procurement gate
Nothing ships to production—bought, built, or hybrid—until all of the following exist:
- One named workflow with a metric and a risk class.
- RACI for context, eval, and incident replay.
- An allowlisted connector surface (MCP or custom) with injection and logging checks.
- Eval cases that can fail a change; a human send gate on external actions.
- A written hybrid split: what the vendor runs vs what you version.
If a vendor cannot meet items 3–4, you are not buying a stack. You are buying a chat window. Keep the freeze until the canvas is real.
After this gate, the next comparison is usually protocol-level: MCP vs custom tool APIs. That playbook is queued; do not start it until this decision frame is in use.
