Build vs buy for AI agents

The build versus buy conversation in AI is usually held at the wrong level. People ask whether to build "an agent", as if that were one thing. It is four or five layers, and the right answer differs per layer.

Decompose before deciding

A working agent system has roughly these layers:

1. Models and inference.
2. Perception: transcription, OCR, extraction primitives.
3. Orchestration: triggers, retries, approvals, scheduling.
4. Domain logic: your rules, your qualification, your exceptions.
5. Data and memory: your records, your history, your entitlements.

Layers one and two are commodities with strong vendors and falling prices. Buy them. Layer three is a platform decision, covered in n8n vs Make vs Zapier. Layers four and five are yours, and outsourcing them is the mistake that costs the most later.

Four factors that decide it

• Differentiation. Does this capability affect why customers choose you. Undifferentiated work should never consume engineering attention.
• Data gravity. Where does the data have to live for the system to work. If a vendor needs a copy of your core dataset to function, you are making a strategic commitment, not a purchase.
• Switching cost. How long to move off it in two years. If the answer is a quarter, negotiate accordingly or keep your own copy of everything.
• Ownership. Who maintains it on Monday. Building without a named owner produces the systems described in why AI pilots die at handoff.

Buy, confidently

• Model inference. Nobody should be training a foundation model here.
• Speech, voice, and transcription.
• OCR and document layout parsing, as a primitive.
• Vector indexes and search infrastructure.
• Observability and eval tooling, once you outgrow simple traces.
• Orchestration platforms, hosted or self-hosted.

Build, deliberately

• Your qualification and exception rules. These are the accumulated judgment of your business and they are the product.
• Your tool surface, because tool design is where agent quality is decided. Detail in shipping a production MCP server.
• Your data and memory model, per AI agent memory.
• Your eval suite. Nobody else knows what correct looks like for you.

Two years of process knowledge lived in a configuration screen we could not export.

The hybrid that usually wins

Bought perception and inference. Bought or self-hosted orchestration. Your own domain logic behind a small internal API. Your own database as the system of record, always. That shape gives you vendor leverage, because any single layer can be swapped without rebuilding the business logic.

Concretely, in client work: a bought voice provider calling my tools, an n8n instance holding triggers and approvals, and a code service holding the rules and the data. Nothing exotic. Very hard to get stuck in.

Three rules regardless of which way you go

1. Own your data from day one. Even when buying, write a copy of every record and transcript into your own store. This single habit preserves every future option you have.
2. Keep the evals in-house. Vendor quality claims are marketing. Your suite is measurement.
3. Time-box pilots. Sixty days, with a written success metric agreed in advance. Pilots without an end date become budget lines nobody defends.

If you want it decided in an afternoon

List the layers. Mark each as differentiating or commodity. Mark each for data gravity. Buy every commodity layer, build every differentiating one, and put a boundary you control between them. That exercise takes an hour and it is most of the decision.

The AI production readiness audit ends with exactly that map for your situation, and services covers the build side once the boundary is set.

Frequently asked