Build vs Buy an AI Agent: A Decision Tree

Buy the agent when the work lives inside a tool you already pay for, or moves between common apps that all have connectors, and a wrong step is cheap to catch. Build it when the agent has to sit inside your own product, act with each user's permissions, carry rules that are your business, or run at a volume where per-use fees outgrow a one-off build. Most businesses land in between: they buy the platform and build the parts that are specific to them. The build vs buy AI agent decision comes down to four questions and ten factors. This post sets out both, with a worked three-year cost comparison and the mistakes that make either choice expensive.

What "buy" and "build" mean for an AI agent

"Buy" and "build" are the ends of a scale, not two boxes. In practice there are four options, and the decision is which one your job needs.

1. Buy the agent inside a tool you use. Your helpdesk, CRM or office suite sells an agent that works on its own data. Intercom's Fin lists $0.99 per outcome with a minimum of 50 a month; Salesforce lists Agentforce at $2 per conversation, or Flex Credits at $500 per 100,000 with a standard action costing 20 credits.
2. Buy a builder. A no-code or low-code platform where you write instructions, pick connectors and arrange steps. What a no-code AI agent builder can do covers that kind in detail.
3. Hybrid. You buy the platform, runtime or model, and build the parts that are yours: custom actions, the rules around them, the integration with an internal system, the screen your team approves things on.
4. Build. Your own code calls a model API, runs in your infrastructure and appears in your own app. How to build an AI agent shows what that code contains.

Every agent has the same parts whoever supplies them: a model, a loop, tools, instructions, an interface, logs and permissions. Buying gets you the generic parts finished. The parts that depend on your business (your systems, your rules, your users, your screens) are your work under every option. AI agent platforms: what they do and where they stop goes through that split part by part.

One question comes before all of this: whether the job needs an agent at all. If the steps are the same every time, a plain workflow is cheaper to buy and cheaper to build. Do you need an AI agent? is a five-question test for that.

The build vs buy AI agent decision tree

Four questions settle most cases. Take them in order and stop at the first leaf you reach.

1. Does the agent live in your product, or act as your users? If customers or staff will use it inside software you own, and it has to do things with their login and their permissions, build. A platform's chat window with one service account behind it cannot act as each person, and it cannot show a proposed change on the record the user is looking at. This is the one question that sends you straight to build.

2. Does the work live inside one tool you already pay for? Support replies in your helpdesk, deal updates in your CRM. If so, the vendor's own agent starts with the data, the screens and the permissions already in place. Nothing you build will start that far ahead.

3. Does that tool's agent take every action you need? Check the actual list of actions, not the demo. If it covers them, buy, and price it at twice your current volume before you sign. If it covers most but not all, you are in hybrid territory: keep the vendor's agent and give it custom actions you own, through the vendor's API or an MCP server.

4. If the work spans several tools: does every system have a connector, and is a wrong step cheap? If both are true, a no-code builder is the sensible buy. If a system has no connector, or one wrong action costs money or a customer, you need tools and rules you can test. Build those parts and keep the platform for the rest. Build the whole agent outright when the gaps are most of the job.

The tree is deliberately short. It decides the direction; the ten factors below decide the detail and show where the answer might flip later.

Ten factors that tip the decision

Every agent project touches the same ten things. For each one, there is a version of your situation that points to buying and a version that points to building.

They fall into three groups.

What the agent has to do

• Business logic. If the process is standard (answer from the help centre, route the ticket), the vendor has already built it better than you would. If the rules are how you compete, such as how you price, qualify or schedule, they belong in code you own and can test.
• Integrations. A connector count tells you a platform can talk to an app, not that it can perform your action with your checks around it. Internal databases, industry software and old systems without a modern API push you towards building at least the integration. AI integrations covers where each connection method breaks.
• Interface. Chat is fine for questions. For actions on records, people need to see the change before it is saved. That screen is product work in your codebase whichever agent sits behind it.

What you need to control

• Data and privacy. When you buy, you accept the vendor's answers on where conversations and tool results are stored, for how long, and which model provider processes them. Often those answers are fine. When they are not, self-hosting or building is the only way to choose your own.
• Security. An agent should act within the requesting user's rights, with the narrowest access the job needs. AI agent tool calling explains how to enforce that in code rather than in the prompt. Platform connectors are often authorised once, by one person, and then act with that access on every run.
• Control. Buying means the vendor picks the model, the release schedule and what changes underneath you. Building means you pick, and you also own the testing when you change anything.

What it costs over time

• Scale. Per-outcome and per-action pricing is cheap at low volume and grows with every run. A build costs more upfront and less per run.
• Cost. Compare three years, not the first month. The next section works one example through.
• Maintenance. A built agent needs an owner: someone who watches the logs, keeps a set of test cases, and updates the prompts and integrations when the systems around them change. If nobody will do that, building is the wrong answer however good the economics look.
• Vendor dependency. Ask what happens if the product changes price, changes shape or disappears. The answer matters more the closer the agent sits to work that cannot stop.

You will rarely get ten answers pointing the same way. That is normal, and it is why the hybrid exists.

What it costs over three years: a worked example

The cost comparison that misleads people is month one, where buying always wins. Run it over three years at your real volume and the answer can change. Here is one example with the arithmetic shown. The buy side uses a published list price; the build side uses assumed figures you should replace with your own quote.

The job: a support agent that resolves customer questions.

Buy: Fin at $0.99 per outcome, outcome fees only.

Build (assumed): $25,000 to build, then $600 a month for hosting, monitoring and upkeep, plus $0.10 per outcome in model calls. The $0.10 is in the range our AI agent running costs example works out for a five-step support agent on a mid-tier model.

At 500 outcomes a month:

• Buy: 500 × $0.99 = $495 a month, or $17,820 over 36 months.
• Build: $600 + 500 × $0.10 = $650 a month. $25,000 + 36 × $650 = $48,400.
• Buying is cheaper every month. The build never pays back.

At 2,000 outcomes a month:

• Buy: 2,000 × $0.99 = $1,980 a month, or $71,280 over 36 months.
• Build: $600 + 2,000 × $0.10 = $800 a month. $25,000 + 36 × $800 = $53,800.
• The build saves $1,180 a month, so it repays the $25,000 after 25,000 ÷ 1,180 = 21.2 months, in month 22.

Three things this example leaves out, and you should not:

• What the bought product includes. A bought support agent comes with setup screens, reporting and a vendor that keeps improving it. A fair comparison counts what you would have to build to match the parts you actually use.
• Time to live. A bought agent can be answering this month. A build takes weeks, and those weeks are months of manual work you still pay for.
• The pricing model, not just the price. Agentforce's two published options show how much the unit matters. For 3,000 conversations a month at $2 each, that is $6,000. If each of those conversations took four actions on Flex Credits, it would be 12,000 × 20 credits = 240,000 credits, or $1,200. Same work, a five-fold difference, depending on which unit you are billed by and how many steps your agent takes.

For what a build involves at each size, custom AI agent cost breaks it down by tier, and AI agent development cost covers the drivers.

Vendor dependency cuts both ways

The usual argument for building is that you stop depending on a vendor. That is only half true. A custom agent still depends on a model provider, and providers retire things too.

Two examples from OpenAI's own deprecations page. On 3 June 2026 it notified developers that Agent Builder, its visual agent canvas, is being deprecated, with shutdown on 30 November 2026. People who bought into the canvas have to move. And on 26 August 2025 it gave developers using the Assistants API a year's notice of its removal on 26 August 2026, with the Responses API as the replacement. People who built in code against that API had to move as well.

So the useful question is not "build or depend on someone?" It is "when this dependency changes, how much do I have to redo?" Three habits keep that small:

1. Keep your business rules and integrations in your own code, behind your own API or an MCP server, whichever platform or model calls them. They are the expensive part, and they survive a change of platform.
2. Keep a set of real test cases for the agent. When you change model, platform or prompt, you rerun them, and you know within a day whether the new setup behaves.
3. Ask every vendor about exit before you sign: can you export the logic, the logs and the conversation history, in a form you can use elsewhere?

There is a counterweight on the build side. MIT's 2025 study of enterprise AI deployments, as reported by Fortune, found that "purchasing AI tools from specialized vendors and building partnerships succeed about 67% of the time, while internal builds succeed only one-third as often." That figure covers generative AI projects in general, not agents alone, and it puts partnerships with outside builders on the buy side. The lesson is not "never build". It is that a build with no experienced team behind it is the riskiest option on the list.

The hybrid most businesses end up with

For most agents that do real work across real systems, the answer is to buy the parts nobody gets an advantage from building and build the parts that are yours.

TeamOS, one of our own projects, is a version of this. It is built on Kaneo, an open-source project manager, rather than from nothing. Its assistant runs on Claude Code or any OpenAI-compatible provider, so the company chooses which model sees its data. The part we built is the part that is specific to the business: the assistant reads the workspace through 53 tools, each request gets a temporary key that is deleted afterwards (read-only while proposing, task scope when applying), and the user ticks which proposed changes to apply. The model and the base product were bought or borrowed. The permissions and the review step were built.

How you approve an agent's actions is its own design problem; human-in-the-loop AI covers what the reviewer should see.

Mistakes that make either choice expensive

• Judging on the demo. Demos show the generic parts working. Test the platform on your three hardest real cases and your least friendly system.
• Comparing month one. Model the cost at today's volume and at twice that, over three years, including the people who will run it.
• Building the generic parts. Writing your own chat widget, connector library or agent framework rarely pays. Anthropic's guidance on building agents suggests developers "start by using LLM APIs directly: many patterns can be implemented in a few lines of code", and warns that frameworks can "obscure the underlying prompts and responses, making them harder to debug." Build little, and build it where it matters.
• Building with no owner. An agent nobody watches drifts as the systems around it change. Budget for upkeep from the first day, or buy.
• Buying with no exit. If the platform holds your rules as canvas nodes and nothing else, leaving means rebuilding them. Keep a written copy of what the agent must and must not do, and keep the hard parts in code.

Start with the tree, then price the leaf

Write down four things before you talk to a vendor or a developer: every action the agent must take, system by system; the screen where a person sees the result; who will own it after launch; and your monthly volume today and in a year. Run them through the tree. Then price only the option you landed on, at both volumes, over three years.

If you land on build or hybrid, that is the work we do: we build custom software with the agent inside it, and AI agents and automations that connect to the tools you already run. If you land on buy, buy, and keep the exit questions above in the contract.