When AI becomes infrastructure, how much of its cost and resilience is determined by architecture rather than procurement?

The economics of AI can look remarkably simple when usage is discretionary.

A person asks a model a question. The answer saves them time. The cost of the interaction is tiny compared with the value of the human effort it replaces or accelerates.

That can remain true while the enterprise economics become much more complicated.

Once AI is embedded inside systems and workflows, consumption is no longer simply a person choosing to use a tool.

Architecture starts deciding how much AI gets used.

How many model calls does one user action trigger?

How much context is sent each time?

Does every task use the most capable model, or are requests routed according to need?

What happens when an answer fails validation?

How many retries are allowed?

Does an agent make three tool calls or thirty?

Does evaluation happen occasionally, or does another model evaluate every result?

What happens when the preferred model is unavailable?

Each of those looks like a technical design choice.

At scale, each is also a budget decision.

Perhaps AI cost isn’t primarily a procurement problem. It’s an architecture problem.

The important measure is therefore unlikely to be the cheapest token.

It is closer to the cost of producing a useful, trustworthy outcome.

A more expensive model that succeeds in one pass may be cheaper than a cheaper model surrounded by retries and correction loops. A larger context may improve performance but increase cost on every call. More evaluation may increase consumption while reducing the much larger cost of bad outputs.

Optimisation cannot be separated from quality.

Nor can cost be separated from resilience.

If an important workflow depends on one external model provider, the organisation has acquired a new operational dependency.

Capacity constraints, outages, pricing changes, rate limits or service degradation can now affect the organisation’s ability to work.

The answer will not always be multi-provider complexity. In some services the sensible response may be a degraded mode. In others it may be routing to an alternative model, limiting non-essential consumption, preserving a local capability or temporarily returning work to people.

The point is to make the dependency visible.

This is why consumption architecture belongs inside the organisational harness.

The harness should not only provide context, permissions, tools and evaluations. It can also provide observability over which models are being called, why they are being called, what those calls cost, whether they succeed and what happens when the preferred route is unavailable.

That allows organisations to optimise something more useful than tokens.

They can optimise the system.

AI can still have extraordinary unit economics.

But as it moves from an optional productivity tool into the machinery of an organisation, those economics increasingly depend on choices made in architecture.

The model has a price.

The system determines how often we pay it.