LLM-Agnostic by Design: Why Finance AI Shouldn't Be Locked to One Vendor

The model market moves faster than most procurement cycles. Capability changes, prices move, versions are deprecated, and provider policies evolve.

Hard-wiring a finance AI product to one model makes every one of those changes an application migration. But calling a thin provider abstraction “LLM-agnostic” is not enough either.

Useful model optionality requires two things at once:

1. a stable business and tool contract that does not depend on one model's habits; and
2. evidence that a replacement model can satisfy that contract for the workload in question.

The Twin provides the first. Evaluation and controlled routing provide the second.

What Stays Stable When the Model Changes

For a governed workflow, the durable unit is the published Twin product:

• the approved business definition;
• source mappings and grain;
• exposed dimensions and measures;
• the stable published relation;
• freshness expectations;
• validation evidence;
• the generated product policy and routing snapshot;
• an optional product-specific evaluation suite.

The agent does not choose an arbitrary warehouse table or write free-form SQL. It requests a typed query against the activated product. The runtime validates the fields and filters, injects organisation scope, and mechanically compiles the read-only query.

That boundary remains meaningful whether the configured agent model comes from one supported provider family or another. The model's job is narrower: select from approved products, express a bounded query intent, and render the governed result.

A task skill is not the invariant. Skills can contain useful operational guidance, but different models may interpret that guidance differently. The product contract and deterministic tool layer provide the stable boundary.

What “Agnostic” Means Today

MLX currently supports multiple external model-provider contracts. The runtime can represent OpenAI, Anthropic, Together, and Google configurations, while the actual models available to a user depend on the selected deployment's credentials and policy.

Runs can carry an explicit model configuration. When they do not, the control plane assigns a complexity tier from deterministic signals such as resolved sources, resolved skills, requested capabilities, routing architecture, and broad prompt patterns. Automatic tier profiles currently map those decisions to OpenAI or Anthropic models. Other represented provider configurations require an explicit run configuration and target credentials.

Direct governed-product runs are intentionally capped at the standard tier by default. Once a product has been selected, the routine task is to translate the request into a bounded query and present the result; finance-related words do not automatically justify the most expensive model.

An explicit per-run configuration can override automatic routing. That makes route choice inspectable rather than burying it inside a prompt.

There are also clear limits:

• MLX does not currently ship a self-hosted inference provider.
• A target exposes only the provider credentials and models configured for it.
• Supporting a provider in a contract does not mean every target has approved or enabled it.
• Multiple providers reduce coupling, but they do not make model behaviour interchangeable.

That is a more useful definition of model agnosticism than claiming every possible model can be dropped in unchanged.

Why the Twin Matters to Model Portability

Without a governed product, model switching can change the answer in two dimensions at once:

• how the model reasons; and
• what the model decides the business data means.

The Twin removes the second variable. A reviewed working-capital product still exposes the same definitions, fields, relation, scope, and freshness evidence after a routing change.

The output may still differ. One model may choose a better grouping, follow an escalation instruction more reliably, or produce clearer commentary. But it cannot legitimately redefine the activated product or query fields outside its contract.

This is what makes a model comparison useful: both candidates operate against the same approved business product and tool boundary.

Model Changes Need an Evidence Gate

“Change one configuration value” describes the mechanics, not the risk.

A material routing change should:

1. identify the workflows and Twin products affected;
2. run their validation and available evaluation suites;
3. compare task quality, refusals, latency, and cost evidence;
4. canary the new route on bounded traffic or approved test cases;
5. preserve an explicit rollback;
6. confirm the route actually executed the intended provider and model.

The last point matters. MLX records requested and executed model identities separately, because a requested route is not proof of what ultimately ran.

Cost evidence is similarly careful. Model-call usage can record provider, model, runtime role, tokens, and provider-reported cost. An estimated cost is attached only when a matching immutable pricing version exists. Missing evidence stays unavailable; it is not converted to zero.

Why Finance Benefits

Finance workloads vary in risk and shape:

• governed queries over published business products;
• extraction from documents and spreadsheets;
• long-context analysis of policies or contracts;
• drafting board, audit, and lender commentary;
• high-value structure changes or write-capable workflows.

Those workloads do not all warrant the same capability tier or provider. A bounded governed query should not be promoted to the most expensive model merely because it concerns finance. A high-value mutation or difficult exploratory task may justify a stronger route and tighter review.

Multi-provider routing creates useful leverage:

• Capability: evaluate new models without rebuilding the business-product layer.
• Cost: compare routes using recorded usage rather than assumed price.
• Continuity: migrate away from a deprecated or disallowed model with less application coupling.
• Procurement: keep a credible alternative when provider terms change.

The leverage is real only if the organisation owns the evaluation criteria and can establish which route actually executed.

What to Ask a Vendor

Ask for current evidence rather than an architecture diagram:

1. Which provider and model contracts ship today?
2. Which subset is configured and approved in our target?
3. What automatic signals influence routing?
4. Can a caller provide an explicit per-run model configuration?
5. Are requested and executed model identities recorded separately?
6. Which Twin product contracts and tool policies remain unchanged across a route change?
7. Which evaluations gate a model migration?
8. How are missing token or cost records represented?
9. Is self-hosted inference actually implemented, or only an architectural possibility?

The point is not to change models constantly. It is to keep the option real without letting a routing change silently alter the business definition or the safety boundary.

In MLX, the Twin is the durable asset. Models compete to use it well.

---

Related: What “Customer-Controlled AI” Actually Means for Finance. Model optionality is one control plane; data, execution, and governed business meaning matter too.

Market watch: Kimi K2.6. How to evaluate a new model candidate without implying that it is already an enabled MLX route.