The Build vs. Buy vs. Agent Decision in 2026

The decision that will not stay decided

Every mid-to-large enterprise we work with runs this meeting at least once a quarter. A capability is needed. A VP argues for buying. A CTO argues for building. Somebody argues for "an agent can do it." The meeting ends in a hedge, a scoping exercise is commissioned, and three months later the same meeting happens again.

The reason the decision does not stay decided is that the framework is wrong. "Build vs. buy" was coherent when you were choosing between writing software and purchasing a license. It is incoherent when a third option exists — an orchestrated set of agents and primitives that neither you nor the vendor fully owns. Below is the tree we use.

Step 1: What kind of capability is this?

Classify the capability into one of four types, borrowing from Simon Wardley's value chain mapping. Genesis: does not exist in the market yet, or exists only as research. Default: build, cautiously, with small teams. Custom-built: exists in bespoke form for a handful of operators. Default: build on primitives, borrow from open source. Product: mature SaaS category with several credible vendors. Default: buy. Utility: commoditized at near-zero marginal cost. Default: consume as a dependency.

Most arguments in the room are actually arguments about which category a capability is in. A VP calls something a "product" that a CTO thinks is "custom-built." Resolve that first.

Step 2: Is there a Theory of Constraints bottleneck nearby?

Apply Eli Goldratt's Theory of Constraints test. If the capability is the bottleneck, invest more than feels comfortable. If it is adjacent, deliberately under-invest. If nowhere near the bottleneck, do nothing — the best investment in a non-constraint is often zero. This step alone eliminates roughly 30% of the capabilities that enter the build-vs-buy conversation.

Step 3: The three-axis agent test

If the capability survives steps one and two, we apply a three-axis test to decide whether "assemble from agents" is a credible third option. The axes:

Axis A — Variation

How much does the shape of the work vary across instances? Low variation (invoice extraction with a stable schema): agents are overkill. Medium variation (customer email triage across many product lines): agents shine. High variation, low stakes: agents shine. High variation, high stakes (claims adjudication): agents with heavy verification, or humans with agent assistance.

Axis B — Integration surface

How many systems does the capability need to read from or write to? Few, stable integrations: prefer traditional build or buy; agent orchestration overhead is not justified. Many, unstable integrations: agents become attractive because they tolerate integration drift better than hard-coded pipelines. One of the strongest signals for the agent path.

Axis C — Iteration cadence

How often does the business want to change the rules? Quarterly or slower: built or bought is fine. Monthly or faster: agents with prompt-level or policy-level updates are dramatically cheaper to change than code. The most underrated argument for the agent path.

Two or more axes pointing toward agents is a strong signal. One axis alone is not.

Step 4: The reversal test

Before committing, we ask one more question, adapted from Annie Duke's work on decision quality: if this turns out wrong, how reversible is it?

• Fully reversible (e.g., a SaaS subscription on a monthly contract with low switching costs): bias toward speed. Pick the option that gets to signal fastest. Often, this is buy, even if the long-term answer is build.
• Partially reversible (most internal tooling): bias toward modularity. Pick the option that preserves your ability to swap components later. Agents often win here because their components are more swappable than monolithic builds.
• Nearly irreversible (e.g., a core data model, a customer-facing legal surface): bias toward caution. Build only if you have the senior engineering capacity to maintain it for five years. Buy only from vendors you would be willing to acquire.

The mistake we see most often is teams treating a reversible decision as irreversible (over-deliberating, under-acting) or an irreversible decision as reversible (under-deliberating, committing to a bad vendor or a bad architecture).

The three honest answers

The answer almost always falls into one of three patterns. Buy, and stop debating — the capability is a product, not a bottleneck, not on an irreversible path. The right move is the fastest credible vendor, not the best one. Assemble from agents and primitives — medium-to-high variation, multiple unstable integrations, fast iteration. This is where the 2026 advantage lives and where most enterprises are under-invested. Build, but smaller than you think — genuine constraint, genuinely differentiating, genuinely irreversible; scope it to the 20% that is actually differentiating and assemble the remaining 80% from vendors and agents.

The defaults of 2018 — "when in doubt, build" and "when in doubt, buy" — are both wrong in 2026. The honest default: classify first, test against a bottleneck, score on agents, ask about reversibility. Four questions. Ten minutes if you are practiced. Enough signal to stop re-running the same meeting.

If the same build-vs-buy conversation keeps showing up on your calendar, the problem is the framework, not the decision. [We can help you replace it](/contact).