Build, Buy or Agent: The New Make-or-Buy Decision for AI

Every team adopting AI hits the same fork. There is a job to be done, an email triage queue, a reporting task, a first-draft workflow, and someone asks whether to buy a tool for it or build something in-house. That question is as old as corporate IT. What changed is that there is now a third door. You can hand the job to an AI agent, a system that plans and executes the steps itself, without buying a finished product or committing an engineering team to build one.

This is not a fringe option. In its 2025 global survey, McKinsey found that 62 percent of respondents say their organizations are at least experimenting with AI agents, and 23 percent are scaling an agentic system somewhere in the enterprise (McKinsey, The state of AI). But adoption is still shallow: in any given business function, no more than 10 percent of respondents say their organizations are scaling agents, and just 39 percent attribute any EBIT impact to AI at all.

So the third door is real but narrow. Most teams will still buy most things and build a few. Naming the agent as its own option matters because it stops you forcing a task through the wrong door: paying for a heavy platform you will use at 10 percent, or starting a build you cannot staff for the years after launch.

The question that sorts everything

Before you compare options, answer one thing: is this capability a source of advantage, or is it table stakes? Almost every good build-or-buy framework since the 1990s reduces to some version of that. If a customer would not notice you performing the task worse than the market average, it is not where your differentiation lives, and you should buy the cheapest reliable version and move on.

McKinsey frames the same test for the AI era directly: successful scalers "balance build-versus-buy decisions based on sources of distinctiveness and competitive advantage, avoiding technology or vendor lock-in so they can adapt quickly" (McKinsey, The agentic organization). The report also points to proprietary data as the durable asset, "a walled garden of proprietary data as their superpower." If the task runs on data or judgment only you have, that is a build signal. If it runs on generic inputs any vendor could replicate, that is a buy signal.

Run this filter first and most candidates resolve quickly. What is left, the genuinely differentiating work, is where the build-versus-agent choice actually matters.

The short version of the three doors: buy if the job is common and non-differentiating; build if it differentiates you and runs on data or process that is yours; use an agent if it is a bounded, multi-step task with variable inputs inside a workflow you control.

When to buy

Buy when the capability is common, a credible vendor already does it well, and owning the code yourself would not change how customers see you. Document summarization, meeting notes, transcription, standard support triage, ad-copy variants, spell and tone checking. In most cases these are well served by mature vendors, unless domain-specific compliance or proprietary context changes the job. Building them in-house spends scarce engineering time to land roughly where a subscription would have put you on day one.

Buying is the right call when:

• The use case is standard. many companies need the same thing, so a vendor can afford to make it good and keep it current.
• Speed matters more than control. you need the capability working this quarter, not after a build cycle.
• The vendor carries the maintenance. model upgrades, security patches, and compliance updates are their problem, not a line on your roadmap.

The cost people miss with buying is integration and switching. A tool that does not connect to your CRM, warehouse, or identity system creates manual work that eats the time it was meant to save. And the more a bought tool becomes load-bearing, the more its pricing and roadmap become yours to live with. Favor vendors with clean exports and open interfaces so a later switch is a project, not a rebuild.

When to build

Build when the capability differentiates you, depends on data or a process that is yours alone, or simply has no vendor that fits. A build means you own the logic, the data flows, and the roadmap. That ownership is worth paying for only when the thing being owned is worth owning.

The cost of starting a build has fallen, though less than the demos suggest. McKinsey reports that with agentic coding tools, business-side employees can assemble software assets themselves, with early adopters seeing productivity "at least double" (McKinsey, The agentic organization). Cheaper to start is not the same as cheap to run.

The failure rate is the counterweight. Gartner predicted that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, weak risk controls, rising costs, and unclear business value (Gartner), and it put the more ambitious business-model deployments at 5 to 20 million dollars. A build you cannot finish, staff, or maintain is worse than a subscription you never bought.

Build when:

• The capability is core to your edge. doing it distinctly better than competitors is part of why customers choose you.
• It runs on proprietary data or process. no vendor can replicate the input, so no vendor can match the output.
• You can staff the two years after launch. someone owns evaluations, model updates, and drift, not just the initial release.

Example: a pricing or quoting engine that runs on your own sales history and margin rules. No vendor has that data, and doing it better than competitors wins deals.

When to hand it to an agent

The agent is the right door for a specific shape of work: a bounded, multi-step task with variable inputs, sitting inside a workflow you control, where a finished product would be overkill and a permanent hire is premature. Think of it as scoped delegation. You are not buying a platform or committing a team. You are assigning a defined job and keeping a person above it.

McKinsey, drawing on more than 50 agentic builds it has led, is blunt that "agents aren’t always the answer" and offers a working rule of thumb (McKinsey, One year of agentic AI):

• Multi-step decisions with a long tail of variable inputs. use an AI agent.
• Output that needs synthesis, judgment, or creative interpretation. use generative AI on its own, without the multi-step action.
• Classification or forecasting from past data. use predictive analytics, or generative AI.
• Repetitive work with structured inputs, such as data entry. use plain rule-based automation.

Example: an agent that reads supplier invoices arriving by email in a dozen different formats, extracts the details, and posts them to your accounting system for a person to approve. The inputs vary too much for simple rules, the task is bounded, and it sits inside a workflow you already own.

The same research warns against agents for "low-variance, high-standardization workflows" such as regulatory disclosures or investor onboarding, where a non-deterministic model "could add more complexity and uncertainty than value." If the process is tightly governed and predictable, automate it the boring way.

Two cautions from the people doing this work. First, "onboarding agents is more like hiring a new employee versus deploying software": an agent needs a clear job description, examples of good and bad output, and continual feedback. Second, there is "no launch and leave." An agent that worked in a demo can quietly degrade when the inputs change, so someone has to watch the task success rate, the share of runs completed correctly without a human stepping in. McKinsey has seen teams "rehiring people where agents have failed."

A test you can run in a meeting

When a candidate task comes up, walk these five questions in order. The first no or the first clear signal usually tells you the door.

1. Would a customer notice if we did this worse than average? If no, buy the cheapest reliable option and stop here.
2. Does a credible vendor already sell this? If yes and the fit is good, buy. A build has to beat "already working" to be worth it.
3. Is this one repeatable task or an evolving system? A bounded task with variable inputs points to an agent. A system central to your product points to a build.
4. Do we have the data and a named owner for after launch? No owner means no build and no agent. Buy, or wait until you can staff it.
5. What does it cost to run per month at real volume? Price the token and inference spend at scale, not the pilot. If the running cost sinks the case, the answer changes.

This is deliberately low-tech. The point is to make the decision explicit and repeatable, so the agent option gets weighed on its merits instead of defaulting to whichever door the loudest person prefers.

The costs that decide it later

Most build-buy-agent decisions look fine at the setup stage and go wrong on the running cost. Budget for these before you commit, not after.

• Evaluations and oversight. agents and builds both need someone checking output quality on a schedule. This is a standing role, not a launch task.
• Token and inference spend at volume. a workflow that costs cents in a pilot can cost real money at production scale. Model it.
• Integration and maintenance. anything bought still has to connect to your systems and stay connected through both sides’ updates.
• The internal owner’s time. every option except a fully managed tool needs a person who understands it and is accountable for it.
• Lock-in. the switching cost of a bought tool or a chosen model rises the more the rest of your stack depends on it.

Budgeting for oversight is easier when the rules are set before the first agent ships. Our guide to AI governance for small teams covers the guardrails worth agreeing up front.

Revisit on a schedule

This is not a one-time decision. Vendor products absorb features that used to require a build. Agent reliability improves. Your own data and talent grow. A task you correctly built in-house last year might be better bought this year, and a task you bought might now be worth owning.

The direction of travel is clear enough to plan around. Gartner predicts that through 2027, generative AI and agents will mount "the first true challenge to mainstream productivity tools in 30 years," and that by 2028, 90 percent of B2B buying will be intermediated by AI agents (Gartner top predictions for 2026). The mix that is right for you now will not be right in eighteen months. Put a recurring review on the calendar and treat the decision as a portfolio you rebalance.

The make-or-buy question did not get harder. It got one option wider. Keep the sorting question simple and be honest about who owns each thing after launch. Getting this right is a large part of an AI-native operating model, where a small team gets its leverage from putting each job behind the right door.

If you want a second view on where your team should build, buy, or delegate to an agent, that is the kind of work we do at Gaveau Strategy.