Buying vs Building Agent Capability as a Company

The question gets framed as a technology decision and answered as one, which is why it goes wrong. The useful framing: what part of the value depends on knowledge only you have?

The layers, and who should own each

The model. Buy. Nobody outside a handful of labs should be building one, and the arguments for fine-tuning are much narrower than they appear.

Generic infrastructure — serving, tracing, eval runners, replay harnesses. Buy or use open source, unless you have unusual requirements. This is engineering with no domain value and it's where teams most often build unnecessarily.

The tool layer over your systems. Build. Nobody else's connector fits your schema, your auth, your error semantics, or your business rules. This is where a large share of agent quality comes from and it's irreducibly yours.

Context assembly for your domain. Build. Which information matters for which task is domain knowledge.

Evaluation cases. Build, and keep them in your repository. They're your specification.

The application — the workflow, the interface, the permission model. Build if it's differentiating; buy if it's a commodity function like a generic support agent.

→ The pattern: buy the parts that are the same for everyone, build the parts that encode what you know.

When buying a complete solution makes sense

• The function is genuinely generic and not differentiating — an off-the-shelf support agent for standard queries.
• You have no engineering capacity for the ongoing maintenance, which is real and permanent.
• Speed matters more than fit, and you accept the fit compromise deliberately.
• The vendor has data or integrations you can't replicate.

⚠️ The failure mode: buying a complete solution for a differentiating function. You end up with the same capability as your competitors, configured slightly differently, and you've outsourced the part that was supposed to be your advantage.

When building makes sense

• The function is differentiating.
• Your data, systems, or rules are unusual enough that fit is the binding constraint.
• You have engineering capacity for maintenance — not just for the build. This is the check most often skipped.
• The requirement is stable enough to justify the investment.

💡 The middle that most companies land on

Buy the infrastructure, build the domain layer:

model, serving, tracing, eval runner   → bought / open source
tool layer over your systems           → built
context assembly                        → built
eval cases and prompts                  → built, in your repo
application                             → depends on differentiation

This captures the leverage of not rebuilding commodity infrastructure while keeping the parts that encode what you know.

✅ It also requires the portability discipline — tools behind a standard protocol, cases and prompts in your repository, one seam for the model — so the bought layer can be replaced without touching the built one.

🔍 The question that settles it

For any capability, ask: if a competitor bought exactly what we're buying, would they have what we have?

If yes, you're buying commodity infrastructure, which is correct and efficient. If yes and it's supposed to be a differentiator, that's the problem.

The corollary: the parts worth building are the parts where the answer is no — and those are almost always the parts that encode your domain, your data, and your rules rather than the parts that encode agent mechanics.

The takeaway

Buy the model and the generic infrastructure; build the tool layer, the context assembly, and the eval cases, because those encode knowledge specific to you. Buy complete solutions for genuinely commodity functions and never for differentiating ones. Check that you have capacity for ongoing maintenance rather than just for the build, and keep the seams portable so the bought layer stays replaceable.