The emerging enterprise AI architecture isn't built around one model. It's built around the ability to dynamically select the right model for each task — based on capability, cost, latency, privacy, risk, and control.

The old question was:

Which model should we standardize on?

The emerging question is:

Which model should handle this particular task, under these particular constraints, right now?

An enterprise might simultaneously use frontier proprietary models for difficult reasoning, coding, multimodal work, or tasks where maximum capability matters; smaller models for routine workloads; open-weight models where greater deployment and control flexibility is required; and specialized models for narrow, repeatable domains.

That means heterogeneity becomes an architectural assumption, rather than something architects try to eliminate.

And once you accept a model portfolio, something has to decide which model gets which task.

This is where routing becomes part of the AI control plane.

A routine classification task might go to a smaller, cheaper model.

A difficult reasoning step might go to a frontier model.

Sensitive data might be restricted to an approved private deployment.

A high-consequence task might require a stronger model, additional verification, or human escalation.

And routing doesn't necessarily happen once per user request. An agentic workflow can route different steps of the same task to different models.

The decision can consider:

Capability × cost × latency × privacy × sovereignty × reliability × context requirements × risk.

This also makes the common argument that open-weight models are cheaper much less straightforward.

Token price is not TCO.

For self-hosting, the economic equation includes compute, infrastructure, utilization, engineering, serving, observability, security, upgrades, power, and operations.

At sufficient scale with predictable workloads, self-hosting can make economic sense. With modest or highly variable usage, APIs may remain more cost-effective.

And sometimes cost isn't the deciding factor.

An organization may knowingly choose a more expensive deployment because it provides better data control, residency, isolation, auditability, latency, customization, or vendor independence.

So the optimization problem isn't simply:

minimum cost

It's:

minimum cost subject to enterprise constraints.

There is another important distinction here.

Fine-tuning should not automatically be treated as the third option alongside frontier and open-weight models.

Specialization can come from several places:

context engineering → retrieval → tools and workflows → fine-tuning

Fine-tuning is one tool. It should be used when it solves a measurable problem better than the alternatives, not simply because an organization wants its own "custom model."

But dynamic routing introduces another requirement: evaluation.

How does a system know that Model A should handle one task while Model B should handle another?

It needs evidence based on the organization's actual workloads, not just public benchmarks.

A model might provide slightly better quality at five times the cost. That difference may be essential for one workload and economically irrational for another.

The resulting architecture starts to look like this:

Evaluate → Policy → Route → Execute → Observe → Learn

At that point, this is no longer primarily a model-selection problem.

It's a systems engineering problem.

And this is where the shift from prompt engineering toward agent engineering becomes important.

Prompt engineering asks:

How do I get this model to perform this task well?

Agent engineering asks:

Which model should perform this step? What context should it receive? Which tools can it use? What policy applies? How do I evaluate the result? When should another model verify it? When should the system escalate to a human?

The model becomes one component of a larger engineered system.

That leads to what I think is one of the more consequential architectural implications:

Model choice may increasingly become a runtime decision rather than an architecture decision.

Architecture still determines which models are permitted, where they can run, what data they can see, what policies apply, and how they are evaluated.

But within those boundaries, the system chooses the model at runtime.

Models will change rapidly. Prices will change. Open-weight models will improve. Frontier leadership will move around. New providers will appear.

An enterprise architecture tightly coupled to today's "best model" will age quickly.

But an architecture capable of evaluating, routing, governing, observing, and replacing models can absorb those changes.

The strategic asset may not be the model.

It may be the intelligence layer that decides how models are used.