Every company evaluating AI agents lands on the same question, usually within the first meeting: do we buy a product, or do we build our own? The honest answer is "both, split correctly". We build custom agents for a living, so watch closely whether our framework gives the buy side a fair hearing. Here it is; judge for yourself.
Terms first
Buying means adopting an agent product someone else builds and operates: a sales copilot, a support automation suite, an AI feature switched on inside software you already license. You configure; the vendor decides what the agent can do.
Building means custom agents developed against your own systems and processes, today typically on the Model Context Protocol (MCP), the open standard that lets agents reach your ERP, CRM, and internal tools through connectors you control. You decide what the agent can do; you also own the consequences.
The trap is treating this as an identity question ("are we a build company or a buy company?"). It is a portfolio question, decided workflow by workflow.
When buying wins
Off-the-shelf wins more often than firms like ours tend to admit, and it wins in predictable places:
- The workflow is commodity. Meeting summaries, generic support triage, email drafting: your version of these processes is not special, and a vendor serving thousands of customers will iterate faster than your team can.
- The product already fits your stack. If an agent feature lives inside a tool you use daily and touches only that tool's data, the integration cost is close to zero. Configuration beats construction.
- You are small or moving fast. Below a certain team size, the arithmetic rarely supports custom work. Buy, learn what agents are good for, and revisit.
- Someone else's maintenance is the feature. Models change, APIs drift, prompts go stale. With a product, that treadmill is the vendor's problem, and that is worth paying for when the workflow is not strategic.
If a purchased product covers most of a non-differentiating workflow, take it and move on. Custom work spent on commodity processes is waste dressed up as ambition.
When building wins
The build case is narrower and stronger. It rests on situations where the workflow is the business:
- The process is proprietary. Think of how your deal team qualifies opportunities or how your finance team reconciles across systems. Where the process embodies your edge, a generic product flattens exactly what makes it valuable.
- The value crosses systems. Products live comfortably inside one tool. Real processes cut across ERP, CRM, accounting, and email. Agents that work across your stack need an integration layer shaped like your stack, and that is custom work almost by definition.
- Compliance and audit set the constraints. When agent actions must respect approval chains, produce audit trails, and follow data-residency rules, you need to control what the agent can reach and prove what it did. A vendor's SOC 2 report is not the same as owning the logs.
- The agent is core to your product or margin. Anything customers experience, or that drives unit economics, should not have its ceiling set by a vendor's roadmap.
The dimension people underweight: ownership
Price gets negotiated; ownership gets discovered later, usually painfully. Three mechanics deserve cold-eyed attention.
Per-seat pricing scales against you. Agent products priced per user get more expensive precisely as adoption succeeds. Custom agents are rarely priced per seat: their running costs follow usage (model calls, hosting, maintenance), not headcount. Whether that is cheaper depends on volume, so run the numbers for your own workflows.
Data gravity accumulates. A year of configurations, workflow tuning, and accumulated context inside a vendor's walled garden is a year of switching costs. Ask on day one: what do we get out if we leave? The answer is often sobering.
Standards are the hedge. This is what changed recently: custom agents built on MCP are not welded to any single AI vendor. The connectors to your systems survive model churn, so you can swap the model and keep the layer. Custom-on-a-standard used to be an exotic bet; it is now the boring option.
Ownership cuts both ways: owning agents also means owning their upkeep. Which brings us to money.
The total-cost reality
Buy-side true cost: subscription, times seats, times years, plus the integration glue nobody budgets, plus change management (a purchased agent still needs rollout, training, and process change, and the licence fee buys none of that), plus the exit cost you will not think about until you need it.
Build-side true cost: the build itself, plus real, permanent maintenance. Models improve, APIs drift, and an unmaintained agent degrades quietly. Anyone selling you custom agents without a maintenance story is selling you a future problem. The honest mitigations are to build on open standards, so maintenance is contained in the connector layer, and to insist on a handover, so your own team can service the system instead of renting the builder forever. That handover is how we work with clients.
A worked example
To make the curves concrete, take one real list price and one clearly hypothetical build. Microsoft lists Microsoft 365 Copilot at $30 per user per month, paid yearly, on top of a qualifying Microsoft 365 licence (Microsoft, as of September 2026). Copilot is a general assistant rather than a single-workflow agent, so treat it as a stand-in for any per-seat AI product.
The build side below is a hypothetical with round numbers, not a quote: a one-off build of $60,000, maintenance of $15,000 a year, and usage costs (model calls and hosting) of $5,000 a year at 50 users, rising to $15,000 a year at 200 users.
| Three-year cost | 50 users | 200 users |
|---|---|---|
| Per-seat product at $30/user/month | $54,000 | $216,000 |
| Hypothetical build | $120,000 | $150,000 |
At 50 users the per-seat product is less than half the cost of the hypothetical build. At 200 users the order flips. Three caveats keep this honest: the per-seat product covers many tasks, not one workflow; the build figures depend entirely on scope; and neither column includes rollout and training, which both options need. Run the same table with your own seat counts and a real quote before deciding.
Neither column is cheap. The question is which cost curve matches the workflow's importance.
The framework on one page
For each workflow, ask in order:
- Is it differentiating? No: buy, and move on.
- Does it cross systems? Yes: leans build.
- Do compliance or audit requirements bind? Yes: leans build.
- Does the total cost at target adoption favour ownership? Price per-seat products at year three, not month one.
- Can we maintain what we build? If neither in-house capacity nor a handover partner exists, do not build.
Most companies end up with a portfolio: commodity workflows bought, a handful of load-bearing processes built and owned. In our experience the split is decided badly when it is decided abstractly, and decided well when someone maps actual workflows first. If you are weighing a specific vendor, our Salesforce Agentforce comparison shows what that analysis looks like for one common case, and enterprise AI implementation covers what the build side involves.
Buy where you are ordinary. Build where you are not. And be more honest than your vendors about which is which.
Talk to us
If you have a shortlist of workflows and want a second opinion on which to buy and which to build, talk to us. We will tell you when the answer is "buy".