Build vs buy AI agents: a CTO decision framework
There are three options, not two: buy a product, configure a platform or build custom. A decision matrix, a three-year cost model and a checklist.
Listen to the summary ·
Read the transcript
At 2,000 support outcomes a month, Intercom’s Fin costs about $71,000 over three years at its listed starting price, less than a custom agent. At 10,000 a month it costs about $356,000, roughly three times the custom option’s three-year cost in the guide’s model.
There are three options, not two. You can buy a finished product, configure an agent builder inside a suite you already use, or build custom code on model APIs in your own cloud.
Buy when the agent does a job every company has, per-use fees stay modest at your volume, and a product already works with your systems. Build when the workflow is part of how you win, when the agent must act inside your own systems, when your data must stay under your control, or when usage fees would outgrow a one-off build.
In the worked example, the build and the people who maintain it are the real cost. Model tokens come to about $1,300 over three years. On the guide’s assumptions, the break-even is about 3,200 outcomes a month.
Buying is the right answer more often than development shops admit. Most teams end up buying the commodity layers, such as models and telephony, and building the workflow on top. The guide below has the decision matrix and a checklist for your own agent.
AI-generated voice summary of this guide.
At 2,000 support outcomes a month, Intercom’s Fin costs about $71,000 over three years at its listed starting price, less than a custom agent. At 10,000 a month it costs about $356,000, roughly three times the custom option’s three-year cost in our model. Same job, same agent; volume alone flipped the answer.
Product vendors will tell you building is slow and risky. Development shops, us included, will tell you buying locks you in. Both are sometimes right, so what follows is a way to decide for one specific agent, including the cases where the right answer is not to hire a studio like ours.
Build vs buy AI agents: the short answer
Buy when the agent does a job every company has, at a volume where per-use fees stay modest, and a product already works with your systems. Build when the agent’s workflow is part of how you win, when it must act inside your own systems, when your data must stay under your control, or when usage fees would outgrow a one-off build within a few years.
Most companies end up in between. They buy the commodity layers, such as the models, telephony, vector search and observability tools, and build the workflow that is specific to them on top. The decision is less “build or buy” than “which layers do we own”.
The three real options: buy, configure or build
There are three ways to get an agent into production, and they differ in time to value, cost model and who owns the result.
| Buy a product | Configure a platform | Build custom | |
|---|---|---|---|
| What it is | A finished agent for one job, such as a helpdesk’s AI agent | An agent builder inside a suite you already use | Your own code on model APIs, in your cloud |
| Example pricing | Intercom Fin from $0.99 per outcome | Copilot Studio credit packs of 25,000 for $200 a month | Our fixed-price builds, $25k–$120k |
| Time to first value | Days | Weeks | 6–16 weeks after a two-week discovery |
| Cost model | Per seat or per outcome, rises with volume | Per credit or message, rises with volume | Up-front build, then tokens and hosting |
| Fit to your workflow | The vendor’s workflow | Within the suite’s connectors and limits | Exactly yours |
| Who owns the code and IP | The vendor | The vendor; you own configuration | You |
A decision matrix for CTOs
Answer these eight questions for the specific agent you are considering. If most answers fall in the “buy” column, buy. If most fall in “build”, build. If it is mixed, buy now and design for a later move.
| Question | Points to buy | Points to build |
|---|---|---|
| Is the workflow a competitive advantage? | No, everyone does it the same way | Yes, how it works is why customers choose you |
| Does it need to act inside your own systems? | Only common SaaS tools with existing connectors | Internal systems, custom APIs or several systems of record |
| What volume do you expect in year three? | Low or uncertain | High and growing, so per-use fees compound |
| Where must the data live? | Vendor cloud is acceptable | Your cloud, your region or no third-party retention |
| How much control do you need over models? | The vendor’s choice is fine | You need to switch models or route by task |
| Is the agent the product you sell? | No, it is an internal efficiency tool | Yes, it is part of what customers pay for |
| Who will run it after launch? | Nobody has time to own it | A named owner with budget for changes |
| How fast do you need it? | This month | This quarter, done properly |
Three-year total cost: a worked example
The cost comparison flips with volume, so do the arithmetic for your own numbers rather than trusting a rule of thumb. Here is one worked example for a support agent that resolves customer questions.
The bought option is Intercom’s Fin AI Agent at its listed starting price of $0.99 per outcome, rechecked on October 18, 2026. The custom option uses assumptions we state openly: a $25k–$120k build placed at $60,000 for a support agent with helpdesk and order-system integrations, $500 a month for hosting and monitoring, 20% of the build per year for maintenance and model updates, and model tokens based on Anthropic’s own example of about $37 per 10,000 support tickets on Claude Haiku 4.5. Helpdesk seats are left out because you need them either way.
| Outcomes a month | Buy: $0.99 per outcome | Build: $60k build plus run | Cheaper option |
|---|---|---|---|
| 2,000 | about $71,300 | about $114,300 | Buy |
| 10,000 | about $356,400 | about $115,300 | Build |
How the build column adds up at 10,000 a month: $60,000 build, plus $18,000 hosting over 36 months, plus $36,000 maintenance over three years, plus about $1,300 in tokens. The tokens barely register; the build and the people who maintain it are the real cost. On these assumptions, the break-even is about 3,200 outcomes a month.
Three caveats keep this honest. A product like Fin includes things a custom build has to create, such as reporting and content management, and its per-outcome price can be higher than the starting price. Intercom also counts a handoff to a person as an outcome when Fin completes that workflow, so outcomes are not the same as fully resolved tickets. A custom build can cost more than $60,000 if it needs more integrations or compliance work. And a bought agent is live in days, which has value the table does not show. Change the assumptions and rerun it; the method matters more than our numbers. For a fuller breakdown of build and running costs, see AI agent development cost.
Data, IP and lock-in: what to check before you sign
Lock-in is rarely about the contract term. It is about whether your data, history and logic can leave with you. Before buying, check:
- whether the vendor trains models on your data, and whether that can be switched off in writing,
- whether you can export conversation logs, knowledge sources and agent configuration in a usable format,
- where data is processed and stored, and for how long,
- whether you can choose or change the underlying model,
- and what happens to your history if you cancel.
If you build, the equivalent questions are about ownership. Our builds put the code in your repository from day one and the IP is yours, but whoever builds for you, confirm both in the contract.
Price the exit before you sign, too, because leaving a bought agent is a small project of its own. Expect to export conversation history and the knowledge base, map them into the next system, rebuild every integration the product handled for you, and rerun your evaluation cases to prove the replacement answers as well. None of that has a list price, so ask the vendor for a sample export on day one; a messy or partial export is the clearest sign of how much leaving will cost.
Governance and risk: why most failures are not about the model
Agent projects stall more often because of how they are run than because of the model, and the build-or-buy choice decides who carries that risk. On the buy side, the risk is a product that demos well but cannot reach the systems or rules your cases depend on. On the build side, it is a team that has never shipped an agent learning on your budget.
According to Fortune’s summary of MIT NANDA’s 2025 report on enterprise AI, tools bought from specialized vendors and builds done with partners succeeded about 67% of the time, and purely internal builds only a third as often. The lesson is not “never build”. It is that building from scratch in-house, without people who have shipped agents before, is the riskiest route. Whichever route you choose, insist on an evaluation set, approval steps for high-impact actions, an audit log, and a named owner after launch; our checklist of agent guardrails lists ten controls to ask for on either route. We cover this in more depth in why AI pilots stall before production.
When buying is the better choice
Buying is the right answer more often than development shops admit. Buy when:
- the use case is common, such as help-center answers, meeting notes or ticket summaries,
- a product already integrates with the tools you use, without custom work,
- your volume keeps per-use fees below what a build and its maintenance would cost,
- you need value this month and can accept the vendor’s workflow,
- or there is no one to own a custom agent once it ships.
In those cases, a custom build would cost more and arrive later, and you should not pay for one, from us or anyone else.
Do general-purpose agents like Muse and Grok Bot count as buying?
Yes, and for one kind of work they are the cheapest option there is. Meta’s Muse and xAI’s Grok Bot are general-purpose agents that sign in to the apps a person already uses and work through multi-step jobs. If the job belongs to one person or one small team and runs through common tools, try them before you buy anything narrower or build anything at all.
What each one is, from the vendors’ own pages (checked October 12, 2026):
- Muse launched on September 8, 2026, rolling out in the US. Meta says it is free for most of what people need, with paid plans for more. It runs on its own cloud machine, people choose which apps it connects to and how much access it gets, and it checks with the user before sensitive actions such as sending an email or making a purchase.
- Grok Bot has been in beta since August 11, 2026, included with SuperGrok and paid Cursor plans, with its own usage on top. Bots share a cloud computer that belongs to the account, sign in across apps and websites, use connectors where they exist and operate the screen everywhere else, and come back when something needs approval. xAI says teams use them for sales outbound, marketing campaigns and office operations; Enterprise access is a waitlist.
The limits are those of any bought agent, plus a few more. The agent runs in the vendor’s cloud with your users’ logins. It follows the vendor’s approval model, not yours, and your evaluation cases and audit requirements don’t travel with it. Where it operates a screen instead of an API, a layout change can break the job. Enterprise controls are still arriving on both.
So split the work by who carries the risk. An agent that drafts, researches or files on behalf of one person can be bought this way today. An agent that changes records, moves money or speaks to customers on the company’s behalf belongs in the build column of the matrix above. There is also a middle path: keep the workflow and its rules in your own systems, and let Muse, Grok Bot or Claude call them through an MCP server for Muse and Grok that enforces your permissions.
- Drafts, researches or files for one person
- Runs through common apps with your users’ logins
- Follows the vendor’s approval model
- Changes records, moves money or speaks to customers
- Acts inside your own systems
- Follows your approval rules and audit trail
When building wins
Building wins when the agent is part of what makes your business different, or when no product can reach the systems it needs to act in. Two of our builds show both patterns.
Relm is a commercial real estate platform where the agents are the product: parallel agents turn a property address into a sourced report and a 10-year pro forma. No off-the-shelf agent does that, because that work is what Relm sells.
Superdeal is the second pattern. Its agent reads the platform’s own creator, deal and shipment records and works through the platform’s own approval step before anything is sent. A bought agent would sit outside that data and those approvals, which is where all of the agent’s value comes from.
The hybrid most teams end up with
In practice, nearly every custom agent is part bought. Models come from Anthropic, OpenAI, Google or open-source providers; vector search, telephony and observability come from vendors. What you build is the layer that encodes your workflow: the tools the agent can call, the rules it follows, the approvals it needs and the evaluation set that proves it works. Owning that layer is what lets you switch models as prices fall, and move between vendors without starting again.
AI agent vs chatbot vs RPA
Part of the build-or-buy question is whether you need an agent at all. Sometimes a chatbot or an RPA script is enough, and both are cheaper.
| Chatbot | RPA | AI agent | |
|---|---|---|---|
| What it does | Answers questions | Repeats fixed steps in software | Decides and acts within rules |
| Handles variation | In language only | Poorly; breaks when screens change | Yes, within guardrails |
| Takes actions | No | Yes, scripted | Yes, with approvals |
| Choose it when | The job is answering | Steps never change | Inputs vary and judgment is needed |
How to run a fair test before you decide
You can test both routes cheaply before committing to either. Run the bought product on a slice of real traffic for two to four weeks, with its own reporting turned on, and record three numbers: how many cases it fully resolved, how many it got wrong, and how many it handed to a person. Then run the same cases through a custom prototype on your real data; our discovery sprint ends with one for $5,000.
- 2–4 weeksRun the bought productOn a slice of real traffic, with its own reporting turned on.
- Same weeksRecord three numbersCases fully resolved, cases it got wrong, cases handed to a person.
- DiscoveryRun a custom prototypeThe same cases, on your real data.
- DecideCompare on your evaluation casesNot on a demo, and at a cost you can live with at year-three volume.
Compare the two on your evaluation cases, not on a demo. If the product resolves enough cases at a cost you can live with at year-three volume, buy it. If it stalls on the cases that matter most, such as those that need your internal systems or your rules, that gap is what a custom build is for. If you do go custom, the vetting questions are in how to choose an AI agent development company.
The method is not specific to AI. We ran the same decision for affiliate tracking, where SaaS plans that step up with tracked affiliate revenue play the part that per-outcome pricing plays here.
A build-vs-buy checklist
Before you decide, write down answers to these, for this agent specifically:
- The one business number the agent must move, and its current value.
- Expected volume in month one and in year three.
- Every system the agent must read from or write to.
- Where the data may be processed and stored.
- Which actions need a person’s approval.
- Who owns the agent after launch, and their budget for changes.
- The three-year cost of buying at year-three volume, and of building.
If the checklist points to buying, buy. If it points to building, our AI agent development team fixes the price after a two-week discovery sprint, and the first conversation is a free AI audit that covers this decision, including when the answer is to buy.
Sources
AI Agent Development
We design and build autonomous AI agents and multi-agent systems that read, decide and act across your tools, with human approval where it matters.
