# 2.8 Model-agnostic orchestration
One question runs underneath everything Orbit does: which AI model should do this particular piece of work? Orbit's answer is that there is no single right model — so it does not pick one and build around it. It uses whichever model is best suited to each task, and changes that choice as the models change. This is what it means to call the platform model-agnostic.
The reasoning is simple. AI models differ — in what they are good at, in how fast they are, and in what they cost to run. A task that needs the deepest reasoning is not the same as a task that needs to run cheaply across a million documents, and the best model for one is rarely the best for the other. A platform built around a single model is stuck with that model's particular balance of strengths, price, and limits for everything it does. Orbit instead routes each task to the model that fits it — reserving the most capable models for the work that needs them, and using faster, more economical models for work that does not.
> *Caption: Each task routed to the model best suited to it — for the right balance of quality and cost.*
This has three consequences that matter to a firm.
The first is **cost and efficiency.** Using the right model for each task, rather than the most powerful model for everything, keeps the economics sensible — which is what makes it viable to run research at scale across an entire universe of companies, not just on the handful of names where the cost of heavy processing can be justified. Matching the model to the work is part of what lets the platform operate at the breadth described earlier in this section.
The second is **improvement over time.** Because Orbit is not wedded to any one model, the platform gets better as the models do. When a stronger or more efficient model becomes available, it can be brought into the routing without rebuilding anything a firm relies on. The work a team has set up — its agents, its workflows — keeps running, and quietly benefits from advances in the underlying models. A firm does not have to migrate to capture the improvement; it arrives underneath.
The third is **no lock-in.** A firm building on Orbit is not making a bet on a single AI provider. If one model's capabilities, availability, or pricing change, the platform is not hostage to it, because it was never built around it. This is a meaningful form of future-proofing: the firm's research capability rests on the connected data and the orchestration over it, not on the fortunes of any one model.
This is also part of the answer to where Orbit's lasting value sits. The models are a shared resource — capable, improving, and reachable by anyone. What is not shared, and not easily reproduced, is the connected data, the entity master that links it, and the orchestration that puts the right model on each task and assembles the result. Orbit does not compete with the models; it is the layer that turns them into an institutional research capability, and that draws on the best of them without depending on any single one.
It is worth being clear about what this does and does not change for a user. It does not change how the platform is used: a team asks questions and builds agents exactly as described in the previous chapters, and never has to think about which model is doing what. What it changes is everything underneath — the quality, the cost, and the durability of the result. The orchestration is invisible by design. Its job is to make the right choice on every task so that no one using Orbit has to.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.orbitfin.ai/part-2-how-it-works/openapi-1.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.