1.5 Why Orbit, not a model alone
Most firms evaluating Orbit have already tried a general-purpose AI assistant, and many have considered building something themselves. Both are reasonable starting points, and both run into the same wall: the hard part of investment research is not the reasoning, it is the data the reasoning has to stand on. Orbit is the layer that supplies it.
A model on its own has no data of yours, and no memory of anything. A general-purpose assistant is a powerful reasoning engine, but it arrives empty. It has no access to a firm's internal research, no proprietary corpus of filings and disclosures, no decade of history to read a new document against, and no master record that knows which company a document actually concerns. It cannot tell you what changed since last quarter because it does not retain last quarter. Ask it the same question twice and you may get two different answers, with no trace of where either came from. For a casual question this is fine. For research that informs capital decisions and must withstand scrutiny, the gap is the whole problem. Orbit exists to close it: the connected data, the entity master that links it, the persistence that lets one analysis build on the last, and the lineage that lets every answer be checked. The model reasons; Orbit gives it something to reason about.
Running at scale is a different problem from answering one question. A model can read a filing you paste into it. It cannot, on its own, monitor a thousand companies overnight, run the same disciplined analysis consistently across an entire coverage universe, or produce structured output stable enough to compare one company against another and this quarter against the last. That requires data already structured for the purpose, workflows that run unattended, and orchestration underneath — which is what Orbit is. The difference between asking a question and running a research process is the difference between a model and the infrastructure around it.
Building it yourself is a data problem, and the data is the part that cannot be rushed. The orchestration patterns are increasingly public, and a capable team can wire a model to a database in weeks. What it cannot do in weeks — or in a single year — is source filings, transcripts, news, and market data across the Americas, APAC, and Europe; process a decade of history so that each new document is read in the context of everything before it; and, hardest of all, build and maintain an entity master that reliably resolves every document and data point to the right company across markets, languages, and corporate changes. That backbone is the difference between a pile of sources and a connected one, and it is precisely the part that takes years and does not get easier with a larger model. On top of it sits the ongoing work most build plans underestimate: integrating the firm's own internal data and third-party feeds into that backbone, keeping the whole thing current as companies change and new documents arrive, and routing work across models as they evolve. A firm can build this. The question is whether it wants to spend years building data infrastructure instead of doing research — and whether, having built it, it wants to maintain it forever.
Orbit is not a competitor to the models — it is what makes them useful here. Because the platform is model-agnostic, it does not bet against any model; it routes each task to whichever model serves it best, and improves as they improve. The lasting value is not in the model, which everyone can reach, but in the connected data, the entity master, and the orchestration that turn a general-purpose model into an institutional research capability. That is the layer a firm adopts when it decides to bring AI to its research process systematically, rather than one question at a time.
This is the claim Part 2 sets out to prove. Each chapter that follows — the entity master, the unified data layer, the structured records, the agents your team can build, the orchestration across models — is one more part of what "a model alone" leaves out, and one more part a build-it-yourself effort would have to reproduce and maintain. Read together, they are the case for adopting the layer rather than rebuilding it.
Last updated