LLM-agnostic model routing
Also called: model routing, model-agnostic AI platform
Directing each task to an appropriate language model at runtime, so a provider can be changed without rewriting workflows.
What llm-agnostic model routing means.
LLM-agnostic model routing separates the definition of a workflow from the choice of model that executes each step. A router selects a model per task based on the requirements of that step, such as reasoning depth, latency, cost, context length, or whether the data may leave the environment at all. Because the workflow references a capability rather than a specific provider endpoint, a model can be swapped, added, or withdrawn without changing the workflow. The property being protected is optionality: the ability to change model providers without a migration project.
Why it matters.
Two pressures make single-provider commitments expensive. Capability and price move fast enough that this year's optimal choice is not next year's. More decisively, some work cannot leave the environment: classified or otherwise restricted data has to run on a model you can host yourself, while the same organization's routine work runs perfectly well on a hosted frontier model. Routing lets one platform serve both without maintaining two stacks.
How it works in practice.
Capability-based selection
A step declares what it needs. The router matches that to an available model rather than the workflow naming a provider.
Data-boundary awareness
Routing respects where data is permitted to go, so restricted work is directed to on-premise models by policy rather than by developer discipline.
Provider substitution
Adding or removing a model is a configuration change. Workflows referencing capabilities keep running.
Routing decisions are auditable
The record includes which model handled which step, which matters for reproducing a run and for demonstrating that restricted data stayed inside its boundary.
What people get wrong.
That model-agnostic means using the lowest common denominator of every provider's features. Routing is the opposite: it lets each step use the model best suited to it, including provider-specific strengths, because the choice is made at the routing layer instead of being hardcoded across the workflow.
Common questions.
Does supporting many models mean using none of them well?
No, because the abstraction is at the routing layer rather than a lowest-common-denominator API. A step that benefits from a specific model's strength is routed to it. What is abstracted is the binding between workflow and provider, not the model's capability.
Which models does Trunnion run on today?
Trunnion is LLM-agnostic and runs on Anthropic and OpenAI models today, with on-premise models used where data cannot leave the environment. A proprietary in-house model is in development.
How does routing help in an air-gapped environment?
In a disconnected environment hosted models are unreachable, so every step routes to locally hosted models. Because the workflow never named a provider, the same mission definition runs in both connected and air-gapped deployments.
Standards referenced.
Trunnion is engineered to align with these control families. Alignment by design is not a claim of current certification or authorization.
Read next.
- AI control planeThe shared layer that composes, authorizes, routes, and records agent work, separate from the applications built on top of it.
- Air-gapped AI deploymentRunning an AI system inside a network with no physical or logical connection to external networks, including no model API calls.
- Multi-agent orchestrationCoordinating several specialized AI agents through a defined workflow, with explicit handoffs, state, and control over the sequence.
Get started
See llm-agnostic model routing running on your workflow.
Governance, approval, and provable audit built into the control plane, from cloud to air-gap. Request a demo against a workflow you actually run.