Buy, build or compose in the age of agents

For years, the technology decision was framed as a choice: buy a standard product or develop a custom solution. Buying promised speed and built-in practices. Building offered adaptation and differentiation in exchange for greater cost and responsibility.

The boundary was never absolute, but agents and the lower cost of producing software have made a third strategy more visible: compose.

Buy

Buying remains a good answer when the process does not differentiate the company, the market understands it well and a provider can spread the cost of quality, security and evolution across many customers.

The question is not whether the product fulfils one hundred per cent of our wishes. It is whether adapting part of the process makes more sense than owning a complete system.

Risk appears when a standard tool forces a genuinely differentiating capability out of shape, or when integration, licensing and dependency costs are excluded from the comparison.

Build

Building makes sense when specific knowledge is part of the value, when we need control over evolution or when no existing solution fits an important constraint.

It also means owning a product, not just code: security, operations, support, data, user experience and future decisions. AI can reduce part of the execution cost, but it does not remove ownership.

Compose

Composing means using standard components for common capabilities and creating only the connections or behaviours that make the system unique. One platform can manage identities, another store documents, a model interpret information, an agent coordinate steps and a small application present the right workflow to the team.

This was possible before, but it is now viable for much smaller needs. Agents can work across several tools without requiring all the logic to become one large monolithic application.

Six criteria for deciding

Criterion	Favours buying	Favours building	Favours composing
Differentiation	Low	Very high and stable	High in one part of the workflow
Market maturity	High	Low	Intermediate or fragmented
Rate of change	Absorbed by the provider	Requires complete control	Specific connections and components change
Integration	Limited and standard	Deep and specific	Several coordinated sources and actions
Risk and regulation	A certified product is sufficient	Extreme control is required	Clear boundaries between components
Internal capability	Supplier administration	Complete product team	Technical direction and ownership of the composition

The table does not produce an automatic answer. It forces us to name the kind of problem we are solving.

The cost that is usually missing

When buying, we forget migration, configuration, exit and price changes. When building, we forget operations and maintenance. When composing, we forget that somebody must understand the contracts, permissions, failures and evolution of every component.

Total cost includes the ability to change our mind. A cheap solution today can be expensive if it closes every future path. A larger initial development may be reasonable if it preserves an important strategic option.

Build only the difference

My preferred criterion is to identify which knowledge or experience we do not want to delegate to a generic product. That is the candidate part to build. Everything else should earn its customisation.

Composing is not a mediocre compromise between two extremes. It can be a deliberate strategy: own the direction and the differentiating part, take advantage of mature capabilities and keep the system ready to evolve.

Sources and references

• OpenAI’s components and patterns for building agents.
• Primary source: Victor’s experience in technology strategy, product and integration.