Model-Agnostic Routing
Our routing architecture selects the execution path according to the workload rather than treating one model provider as the permanent center of the system.
Routing inputs
Routing inputs can include task type, reasoning difficulty, data sensitivity, latency tolerance, context size, output requirements, cost, reliability, tool-use capability, model availability, and deployment constraints.
The selected path may be a frontier model, open-weight model, private model, task-specific model, deterministic software component, or specialized tool.
Routing policy
Conceptually:
- Workload
- Task classification + policy
- Quality / privacy / cost / latency constraints
- Candidate execution paths
- Availability + evaluation state
- Selected route
- Validation / fallback / escalation
The routing policy is part of the platform architecture. The public capability does not depend on exposing the proprietary thresholds or model-selection weights underneath it.
Why we route
Different workloads have different economics. A difficult operating investigation may justify frontier-level reasoning because improved synthesis changes the value of the decision. A repetitive extraction task may be better served by a smaller private model. An exact reconciliation should often bypass model inference entirely.
Forcing all three through the same model would increase cost or reduce reliability without creating corresponding business value.
Routing also reduces platform dependence on any single provider. Model availability, pricing, context limits, tool-use behavior, and quality can change over time. Our architecture treats models as replaceable execution resources while preserving the layers that carry company-specific value: data preparation, ontology, retrieval, evaluations, permissions, operating logic, automation, and institutional memory.
A better model should improve the system. It should not require the system to be rebuilt.
Routing is evaluated, not assumed
A routing policy can itself become a source of error. Selecting a cheaper model is not useful if the resulting task failure creates more downstream cost. Selecting the strongest model is equally inefficient when the workload does not benefit from the additional capability.
We therefore evaluate routing decisions against the same production criteria used for the underlying models. The router can also account for temporary operating state such as provider availability, load, latency, or hardware capacity while maintaining task-level requirements.
This allows the execution path to change without changing the business contract of the task: the required output, validation rules, permissions, and escalation boundary remain stable even when the model underneath them changes.