GAR serves live traffic in its own environment
The engine runs in its own dedicated cloud project, behind its own service. It is deployed infrastructure with a version history, not a research notebook.
GAR — our cognitive engine
A general-purpose model is overkill for most of the work.
Almost every AI product answers every question by calling the largest model available. It works, and it is enormously wasteful. GAR is our own cognitive engine, built on the opposite premise: match the engine to the job, and it gets better every time you use it.
Cognitive engines will be special-purpose
The industry is in its one-engine-fits-everything phase. We do not think that lasts.
Nobody builds a single engine and drops it into a motorcycle, a delivery van and a container ship. Power plants are matched to the application — to the load, the duty cycle, and the cost the vehicle can carry. Software is heading the same way, and for the same reason: a general-purpose model asked to do a narrow, repeated task is paying for capability that task never uses.
That is what the name says. GAR — General Agent Replacement. Most cognitive work inside a product does not need a system that can also write sonnets and debate philosophy. It needs to do one bounded job accurately, repeatedly, and cheaply. Our position is that the winning systems will be built from engines sized to their jobs, and that GAR is the template for producing them — one engine design, specialized per problem domain.
“Better reasoning doesn’t always come from making models bigger. Sometimes it comes from rethinking the architecture.”
— Joe Boyd, Co-Founder, Octum
The common pattern
One giant engine for everything
- Every task, trivial or hard, pays the same per-call price
- Costs scale linearly with usage — growth makes the margin worse
- The system is exactly as good on its millionth call as its first
- Capability, pricing and roadmap belong to the vendor
How GAR is built
An engine sized to the job
- Comparable results on the work that matters, at a fraction of the cost
- Usage makes it better, and cheaper for us to run, rather than only more expensive
- Capable from the first day, not after a training program
- A template we can specialize for a new domain
It gets better through use
This is the part that is genuinely different, and the part that compounds.
A hosted model is a fixed asset. It performs identically on your millionth query and your first, and costs the same to run both times. Nothing about your usage makes it better, and nothing about it makes the next one cost less to serve.
GAR is built so that running it is itself a form of tuning. Doing a piece of work is also how the engine comes to do that same work more cheaply the next time, without waiting for a training cycle to come round.
With enough repetition a task stops needing the heavyweight path at all. It becomes a reflex — settled, fast, and answered directly. That shift happens one task at a time and it does not reverse, so work that begins expensive migrates steadily into work that is close to free to serve. Every query is therefore two things at once: a job completed, and a small permanent gain.
Nor is that the only place improvement happens. More than one part of the engine sharpens in the course of ordinary operation, and they all point the same way — which is the point of the whole design: use improves the engine, and an improved engine costs us less to run.
Some jobs genuinely want a full language model — composing prose is the obvious one — and for those it stays in the loop. The aim was never to eliminate it. The aim is to stop paying for it across the thousands of narrow, repeated judgments where a reflex does the same work.
To be clear about whose costs these are: they are ours, not your bill. Membership is priced by what a result is worth to you, not by what it cost us to produce — so a hard question does not cost you more because it took more work, and this efficiency shows up as a price that holds rather than one that drops.
We are describing what this produces, not how it is done. The mechanism is the part we keep.
“A hosted model costs us the same on your millionth query as your first. Ours doesn’t — which is why the price can stay where it is instead of climbing.”
— Joe Boyd, Co-Founder, Octum
Running, and not yet finished
Plenty of companies describe a proprietary engine without saying whether it is switched on. Here is the honest split.
A full environment runs on GAR instead of external models
Our test environment is configured identically to production in every respect but one: it routes to GAR rather than to external model APIs. That is how we compare the two on like-for-like work instead of asserting a result.
The current phase is doing work, not waiting
The live platform still answers on hosted frontier models today, and we would rather tell you that than have you discover it. That is not idle time: the best available models are the bar GAR is held to, and it is measured against them continuously, on real work rather than on benchmarks chosen to flatter it. The swap is a configuration change by design, and it happens when that comparison stops favoring the incumbent.
“So you are a wrapper company.” No. It is a fair question, so here is the direct answer. A wrapper company is fundamentally dependent on someone else’s model for its product. Remove that model, and the core product largely disappears.
Remove the hosted model from Octum and what remains is the proprietary, analyst-verified data; the institutional domain model built on top of it; the orchestration that turns a question into a sourced answer; and an engine already serving in its own environment with a full parallel deployment running on it. Which model answers a given query today is a configuration line we control. The rest is the company, and none of it arrives in an API response.
Owning the engine is what keeps your data inside
There is a question every allocator should put to an AI vendor, and most never do.
When you ask a typical AI product a question, that question leaves. Whatever it contains — a counterparty name, deal terms, an allocation you have not announced, the simple fact that you are researching a particular manager at all — is transmitted to a third-party model provider. It crosses your perimeter, and it crosses your vendor’s perimeter too. For a great many institutions that is the end of the conversation, and rightly so.
This is the part of owning an engine that has nothing to do with cost. Because GAR runs on infrastructure we operate, there is no third-party model host in the path of a query. That covers the whole cycle, not just part of it: every model involved in answering you, and in making the engine better at answering you, runs on our own hardware. There is no point at which your question is handed to an outside provider.
This is one of the larger reasons the work is being done at all, and it is the part of the cutover described above that we are least willing to rush.
Renting a model
Every question leaves
- Queries and their contents go to a third-party provider
- Your research pattern is visible outside your walls — and outside your vendor’s
- Residency and retention are governed by someone else’s terms
- Diligence questions have answers you do not control
Running GAR
Nothing is handed out to get an answer
- Inference is served in-house, on infrastructure we control
- No external model provider receives your questions or what is in them
- Deal terms, allocations and counterparties stay inside the boundary
- One decision — owning the engine — delivers the economics and the confidentiality together
We started from a different question
Not “what can we build with the models on offer?” but “what must any capable reasoning system contain?” — and then establishing the answer one capability at a time.
Asking which components you can remove from a system searches an infinite space and never finishes. So we inverted it. Nothing is necessary in the abstract; things are only necessary for some capability. Raise the demand on a system until a component flips from optional to unavoidable, and the flip point tells you something true.
Run that repeatedly across different kinds of demand and a short list falls out — the components a capable system cannot do without. These are what GAR is built on, and they are what stop a smaller engine from being merely a cheaper, worse one.
Select what matters
What is relevant is always a small part of what is available, and it has to be chosen under a budget — both from the present input and from everything that came before.
Reuse structure
Represent things in parts that recombine, or pay a cost that grows with every new combination. Generalising to a situation you have not seen depends on it.
Work out what cannot be precomputed
Novelty is precisely what you cannot cache in advance. Genuinely new situations have to be worked through when they arrive, over a model of the world that is not tied to yesterday’s goal.
Connect choice to consequence
Decisions and their results are separated by time. Without a way to span that gap, a system cannot learn from outcomes that arrive long after the choice that caused them.
One scale for choosing
Competing objectives need a common yardstick. Without one, preferences become inconsistent — and inconsistent preferences can be exploited by anyone who notices.
Some limits are not tradeable
A few constraints must sit above the yardstick rather than be priced against it. No amount of benefit elsewhere should buy its way past them.
Know what you do not know
A system that only ever produces a point answer has no choice but to guess. Representing its own uncertainty is what makes declining to answer possible at all.
Learn without overwriting
New knowledge has to accumulate without destroying what is already there — the difference between a system that improves and one that merely changes.
Each was established as a forcing result: a task designed so the component is not a nice-to-have but the difference between working and doing provably no better than chance. Each is graded by the strength of the evidence behind it — a proof outranks agreement across architectures, which outranks a single experiment — and we do not round grades up. The map is treated as open: it is an estimate of what is necessary, not a claim to have finished.
The current design exists because the previous one failed
A research program that only ever produces good news is not producing research.
Before building, we record what would count as success and what would count as failure — and, separately, the rationalizations we commit in advance to refusing. The one that costs something is the third:
“If the bet appears falsified by the build, I will not retreat to weaker versions of the claim … that I can defend regardless of evidence. … If the specific bet fails, the bet has failed.”
— from our internal position paper, written before the experiments were run
An earlier incarnation of our engine was built on a different bet about how cognition should be organized. We ran the experiments, and it did not hold. We wrote that down, in the same document that had proposed it, rather than quietly softening the claim into something unfalsifiable.
That null result is why GAR exists. The current architecture was not a refinement of the old one; it was the response to its failure — a redesign around what the evidence actually supported. Retiring an idea on schedule is not a detour from the work. In our case it produced the engine.
“Our first architecture didn’t work. We wrote that down in the same document that proposed it, and built the current one in response. That’s not a detour from the work — in our case it produced the engine.”
— Joe Boyd, Co-Founder, Octum
We think that record is the most useful thing we can show a serious counterparty. Anyone can describe a breakthrough. A team that can tell you precisely what it got wrong, and what it built as a result, is a team whose remaining claims you can price. The full technical record is available under NDA.
Why this should matter to you
If you are considering membership
- Answers grounded in proprietary, analyst-verified data — not whatever was on the open web during training
- A system built for institutional investing, rather than a general chatbot pointed at finance
- Reasoning you can inspect, so you can judge an answer instead of trusting it
- An engine designed to improve with use, so the product you join is not the product you keep
- Results priced by what an answer is worth to you, not by the compute behind it — a harder question does not cost more because it took more work
- A path to research that never leaves our infrastructure — what you look into stays between us
If you are evaluating us as an investment
- Unit economics that improve with scale instead of degrading — usage makes the engine cheaper to run, not just more expensive
- A defensible asset in the engine and in proprietary data a general model cannot reach by scaling
- No single-supplier dependency: the engine is a configuration choice, and ours already runs
- One engine design intended to be specialized into new domains, rather than a single-market product
- In-house inference opens the institutions that cannot send data to a third-party model provider at all
- A documented, dated, falsifiable research record — including, in writing, the bet that failed and what replaced it
The fastest way to judge this is to use it
Ask Ora something you already know the answer to, and see whether the reasoning holds up. That is a better test than anything on this page.
First month free, then $19/month. About 3 minutes to join.