> For the complete documentation index, see [llms.txt](https://docs.orbitfin.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.orbitfin.ai/part-1-what-orbit-is/1.5-why-orbit-not-a-model-alone.md).

# 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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-1-what-orbit-is/1.5-why-orbit-not-a-model-alone.md?ask=<question>
```

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.