Quick answer: Buy when the agent does what every company’s agent does, volume is modest and the product already connects to your systems. Build when the workflow is your advantage, the data must stay under your control, or usage fees would outgrow a one-off build. Most teams end up buying the commodity layers and building the workflow on top.
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, configure or build
| 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.
Eight questions that decide build vs buy
| 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 29, 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 at the rate in our AI agent cost worked example: four Claude Haiku 5.5 calls per ticket with prompt caching, about $0.0018 a ticket at list prices checked October 29, 2026. Helpdesk seats are left out because you need them either way.
Three-year cost, support agent (list prices and stated assumptions)
| Outcomes a month | Buy: $0.99 per outcome | Build: $60k build plus run | Cheaper option |
|---|---|---|---|
| 2,000 | about $71,300 | about $114,100 | Buy |
| 10,000 | about $356,400 | about $114,600 | 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 $640 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.
Where the build option’s three years go, at 10,000 outcomes a month
- Build: $60,000
- Maintenance, 3 years: $36,000
- Hosting, 36 months: $18,000
- Model tokens: about $640
Stated assumptions above; total about $114,600. Tokens are the shortest bar.
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.
Split the work by who carries the risk
Buy a general-purpose agent (Muse, Grok Bot)
- Drafts, researches or files for one person
- Runs through common apps with your users’ logins
- Follows the vendor’s approval model
Build (your systems)
- 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.
A commercial real estate platform we built is the first pattern: the agents are the product, and 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 the platform 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.
The layer you build is the one that encodes your workflow.
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 or AI agent
| 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.
A fair test of both routes
- Run the bought product (2–4 weeks): On a slice of real traffic, with its own reporting turned on.
- Record three numbers (same weeks): Cases fully resolved, cases it got wrong, cases handed to a person.
- Run a custom prototype (discovery): The same cases, on your real data.
- Compare on your evaluation cases (decide): Not 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
- MIT report: 95% of generative AI pilots at companies are failing, Fortune
- Intercom pricing (Fin AI Agent), Intercom
- Microsoft Copilot Studio pricing, Microsoft
- Claude API pricing, Anthropic
- Introducing Muse: The World’s First Personal AI Agent Built for Everyone, Meta
- Introducing Grok Bot, xAI
Originally published at apptycoons.com.
Top comments (0)