Building vs Buying an AI Agent: A Decision Framework

Why this is harder than software build-vs-buy

Traditional SaaS build-vs-buy is about features and integration: does the off-the-shelf product cover the workflow our team needs, and how cheaply can we customise it? Agent build-vs-buy adds a different layer of considerations.

Model choice. Buying an agent product usually means accepting the vendor’s choice of underlying model. If the vendor has picked badly for your task, or if the vendor’s model selection is opaque, you have less control over a major quality lever.

Prompt ownership. The system prompt is where most of the agent’s personality and reliability lives. A vendor product’s prompt is the vendor’s asset; you may or may not be able to inspect it, modify it, or export it for migration.

Data residency. Agent products process the prompt and the conversation through the vendor’s infrastructure. Regulated data, internal documents, or customer information may not be allowed to traverse a third party regardless of the vendor’s contractual assurances.

Iteration cadence. Foundation models update faster than traditional software. A vendor that does not surface model changes (and the prompt revisions that often accompany them) leaves you with unpredictable behaviour shifts. A self-built system pins the model version and chooses when to upgrade.

Four decision axes

1. Task uniqueness

How bespoke is the task to your organisation? Generic tasks (transcribe a meeting, summarise a document, draft a basic email) are well-served by off-the-shelf products. Bespoke tasks (route a customer query through your specific service-tier rules, draft a response in your brand voice using your product knowledge base) reward a custom build because the customisation is the value.

2. Data sensitivity

Can the data leave your infrastructure? Regulated industries (healthcare, finance, defence), companies with significant trade-secret exposure in their corpora, and government deployments often cannot send prompts through a third-party agent product. The build option, possibly on a self-hosted or BYO-cloud model, becomes structurally more attractive.

3. Scale

At what volume does per-seat or per-token vendor pricing exceed the cost of a self-hosted alternative? The crossover point varies by task and by vendor; the question to answer is “at our projected volume, what is the unit economics” rather than “which is cheaper at zero volume.” Vendor products are often cheap at low volume and expensive at high volume; self-built systems are the inverse.

4. Internal capability

Does your team have the prompt engineering, evaluation, and observability capacity to own the system end-to-end? A built agent is a continuous engineering investment: prompt iteration, model upgrades, eval set maintenance, production monitoring. A team without that capacity may be better off buying, accepting the trade-offs, and revisiting in a year. A team with that capacity loses comparatively little by building, since they would need most of the same skills to operate a bought product seriously.

The middle path

Most production agents are not built from scratch and are not bought as a closed product. They are built on a framework, on top of a model API, with vendor-supplied observability and evaluation tooling. This hybrid is often the right answer: it captures the benefits of ownership (prompt control, model choice, data path) while reusing the parts of the stack that are not differentiating.

The decisions inside the hybrid are: which orchestration framework (see the orchestration reference); which model provider; which observability platform (see the observability reference); how much custom prompt engineering versus framework defaults. None of these has a clean recommendation; each turns on team and stack fit.

Questions to ask a vendor

• How is data handled, retained, and deleted? Where is it processed?
• Which underlying model is used, and how are model upgrades communicated?
• Can we inspect or export the prompts and configurations driving the agent?
• What is the SLA on model-change communication and any behaviour shifts that result?
• Can we add custom tools, or is the tool inventory fixed?
• What evaluation harness is the product tested against, and is the eval data available?
• What is the export path if we choose to migrate off the product later?

Questions to ask your team before building

• Do we have an evaluation framework, or will we need to build one before the agent itself?
• Can we keep up with monthly or quarterly model releases? Who owns the upgrade decision?
• What is our prompt-change review process? Are prompt changes versioned and tested?
• Who owns production incidents, and what is the on-call expectation?
• Do we have observability today, or will we need to add that infrastructure?
• Is the team genuinely interested in this work, or is the build justified by sunk cost?

When “no” is the right answer

Sometimes neither building nor buying is correct. The task does not actually need an AI agent. A SQL query, a scheduled job, a rule-based workflow, or a single LLM call (without agentic looping) might be cheaper, more reliable, and sufficient for the actual problem.

Working signals that an agent is the wrong tool: the task has predictable inputs and outputs; deterministic correctness matters more than flexibility; the cost of a wrong answer is very high; the existing non-AI solution works and the agent is being introduced because of pressure rather than need. Be willing to choose “no” even when there is organisational momentum to build.