Build vs. Buy in the Agent Era: When Off-the-Shelf Beats Custom

Two meetings are happening in every enterprise right now. In one, a vendor is demonstrating the agent now bundled into a platform you already pay for — the CRM agent, the ITSM agent, the ERP copilot. In the other, an engineering team is proposing to build a custom agent on a frontier model, and the demo is impressive there too. Both meetings end with the same question and radically different price tags: build or buy? The classic answer — buy for commodity, build for differentiation — is still directionally right, but the agent era has quietly rewritten every term in that equation. What counts as commodity is expanding monthly, what counts as differentiation has moved out of the model and into your data and workflows, and the cost that dominates is no longer construction. It is everything that comes after.

Why the old calculus broke

Three shifts changed the math. First, the capability floor rises without you: an agent you buy inherits every model improvement its vendor ships, while the agent you build inherits a maintenance backlog — evals to re-run, prompts to re-tune, regressions to chase — every time a model version changes. Second, the moat moved: when every competitor can call the same frontier models, the model itself differentiates nobody; what differentiates is proprietary data, distinctive workflows, and accumulated domain judgment — which argues for building only where those assets actually live. Third, buying became integration work: an off-the-shelf agent still needs your permissions model, your data quality, your guardrails, and your change management, so "buy" no longer means "avoid engineering" — it means redirect it. Teams that miss this ship a purchased agent with default settings into a workflow nobody redesigned, then conclude the product was the problem.

A decision framework that survives contact with reality

Strip away the vendor decks and the engineering enthusiasm, and the decision comes down to four questions asked in order. Is this capability differentiating — would doing it distinctly better than competitors change your economics, or does it just need to work? Is your advantage in the data and workflow — do you hold proprietary data or process knowledge a vendor cannot have? Can you sustain the operational burden — not build it once, but eval it, monitor it, and re-tune it through every model generation, indefinitely? And does a credible product already exist — not a demo, but a product with referenceable deployments in your industry? Building is justified when the first three answers are yes and the fourth is no. Most capabilities fail that test, which is exactly the point: the scarce resource in the agent era is not the ability to build — it is the engineering attention to operate what you build. Spend it where it compounds.

The costs each side undercounts

Build advocates undercount operations. A custom agent is a product with a lifecycle: evaluation suites that must run on every model and prompt change, guardrails that must evolve with new attack patterns, monitoring that someone owns at 2 a.m., and a bus-factor problem when the two engineers who understand the orchestration leave. The build estimate that wins the meeting is the construction cost; the cost that arrives is construction plus a permanent product team. Buy advocates undercount dependence. An agent that works becomes how work gets done; switching later means retraining people, not just migrating data. Vendor roadmaps shift, per-seat pricing becomes per-action pricing, and the agent's telemetry — a detailed record of how your business operates — accrues to someone else's product. Neither cost is disqualifying. Both belong in the spreadsheet, and in most spreadsheets they are simply absent.

Run a portfolio, not a policy

The organizations navigating this well do not have a build-vs-buy policy; they have a portfolio. Buy the commodity layer: IT service desk, meeting summaries, code assistance, CRM hygiene — capabilities where you hold no special advantage and vendors iterate faster than you can. Build the thin differentiating layer: the underwriting triage agent that encodes your risk appetite, the pricing agent that knows your margin logic — narrow, high-value, fed by data only you have. And compose in between: buy the platform, build the skills — most modern agent platforms accept custom tools, retrieval sources, and policies, which lets you attach your proprietary logic to someone else's maintained chassis. The composition tier is where most of the real leverage sits, and it changes the talent question too: you need fewer people who can build an orchestrator from scratch, and more who can evaluate, govern, and integrate agents — whoever built them. Revisit the portfolio quarterly; in this market, a build decision is not a decision, it is a subscription to re-deciding.

The honest summary

Buy is the right default — not because building is too hard, but because operating what you build is the cost nobody budgets, and because your differentiation almost never lives in the agent itself. It lives in the data the agent reads, the workflow it sits inside, and the judgment it encodes. Build exactly there, buy everywhere else, and put your best engineering not into another orchestrator, but into the foundation every agent — built or bought — depends on: clean, governed, well-permissioned data. In the agent era, that is the asset that appreciates while everything else gets replatformed.