The classical make-or-buy calculation no longer carries for agentic systems. Three new dimensions — process proximity, data intensity, rate of change — lead to the foundational decision before any tool comparison begins.

Make or Buy in the age of agents. A model.

Essay #002 · 2026 · Reading time 6 min · Field: Make/Buy · Market: Mittelstand/Trades

Ten years ago, make-or-buy was a decision that usually computed well. There was a table. On the left, the costs of in-house development — salaries, infrastructure, maintenance, opportunity cost. On the right, the costs of purchasing — license, customization, dependency. At the end, one side had the better number. You signed.

In the age of agents, this table no longer works.

Not because the numbers have grown harder. But because the categories beneath the table have shifted. What used to be “license” with classical software is, for agentic systems, a subscription to a service whose architecture changes monthly. What was “in-house development” is now more like “orchestration of the already existing.” What was “maintenance” is “permanent reconfiguration.” The terms no longer carry what they used to carry.

This essay proposes a model for how make-or-buy decisions should be made in the age of agents. It is not a finished framework. It is a pattern of thought that I have found to carry in my own decisions at arocom and in work with clients.

Three dimensions instead of two

The classical make-or-buy question essentially knew two dimensions: cost and control. You chose between build (expensive, controlled) and buy (cheap, dependent). For agentic systems this is not enough. Three dimensions are needed.

The first: process proximity. How close does the agentic system sit to the core business? An agent processing internal invoices is far from the market. An agent conducting customer conversations is in the middle of it. The closer to the market, the more own-built the system should be — not because in-house is better, but because proximity to the market means adaptation speed weighs more heavily than cost.

The second: data intensity. What role do proprietary data play for the system? If the system works with open, generally available data (literature research, general text summarization, translation), buying is cheaper and better. If the system works with internal, often sensitive data (customer dossiers, internal finances, process know-how), the question becomes abruptly strategic. Those who put sensitive data into an outside architecture give away more than they realize.

The third: rate of change. How quickly does the task the system is to perform change? A compliance check for credit contracts changes slowly. A marketing assistant changes monthly. Quickly changing tasks want an architecture that changes with them. That is not automatically in-house — but it is rarely the large enterprise purchase.

The three dimensions together form eight quadrants. Not all eight are equally interesting. Some are almost always “buy” (low process proximity, low data intensity, slow change: the calendar assistant). Some are almost always “make” (high process proximity, high data intensity, fast change: the sales agent for a niche business). The interesting decisions lie in the mixed areas — and there the model helps find the center of gravity.

A case

A mid-sized industrial company. Two hundred employees, specialized manufacturing, many custom constructions. The managing director is facing the question: should we deploy an agent that drafts technical offers?

Offer processing is an internal bottleneck. Technical clarification with the customer, alignment with engineering, preliminary costing, offer writing. Per offer: half a working day of a senior designer. With increasing inflow, a growth bottleneck.

A vendor is pitching a finished solution. It promises to be trained on internal data sources. Price: €60,000 rollout, €4,000 per month. Attractive because fast.

An in-house team proposes building it themselves: €140,000 in the first year, then €50,000 per year. More expensive, slower, but tailored.

What does the model say?

• Process proximity: high. Offers are direct customer communication. Every inaccuracy is visible.
• Data intensity: very high. Quality depends on how well the system knows customer history, prior projects, internal margin logic. This data is highly sensitive.
• Rate of change: medium. The structure of offers changes rarely. What changes are prices, materials, boundary conditions — master data, not agent logic.

The decision by the model: the purchased solution is risky because process proximity and data intensity are too high. Building in-house is necessary — but because rate of change is only medium, the build need not be elaborate. A lean, hybrid approach: base framework from the market, integration and adjustment in-house. That might cost €80,000 in the first year, significantly less in the following years.

The model here has recommended neither the most expensive nor the cheapest variant. It has recommended the structurally most correct one.

What the model does not do

The model is not a calculator. It does not tell you which vendor to buy or which architecture to build. It tells you where the foundational decision lies — and which questions you must ask your people before you make that foundational decision.

That is a lot. Because the mistake in most make-or-buy decisions in the age of agents is not that the wrong variant was chosen. The mistake is that the decision became technical too early. Vendors were compared before it was understood what actually needed to be decided. Integration interfaces were discussed while the real question was whether to let the data leave the house at all.

The model forces these questions to be asked before the tool questions.

Three failure patterns I have seen repeatedly

“We buy now, build later.” That is the decision that looks cheap in the short term and gets expensive in the long run. Those who buy build on an architecture they do not control. The switch is usually more expensive than the original in-house build would have been.

“We build everything ourselves.” This is the decision born of control-anxiety. It is also expensive — and it ties up capacity that would be better used elsewhere. Not every task is core. Not every task requires bespoke work.

“We decide when the technology is more mature.” This is the waiting decision. It sounds wise. It is usually the worst of all. While you wait, your competitors learn. While you wait, your workforce gets used to not being given a clear direction. While you wait, decisions get made somewhere in the house — just not by you.

The actual point

The make-or-buy model is a tool. It does not solve a decision — it structures it. But the decision itself remains with the decision-maker. And that is the point the first essay of this archive made: those who delegate the make-or-buy question to external experts or to internal IT delegate the company’s strategic core question. The decision about where in the company agentic work takes place and where not is not an IT decision. It is an architecture decision in the most literal sense: it shapes what the company will look like in five years.

For that, a model is needed. For that, one’s own head is needed.

For that, both are needed — separately.

— Axel Roth