Frontier vs grounded: the wrong axis

"Why not just use Claude or GPT?" is the most reasonable question in every procurement conversation we have. The honest answer is that it is asked on the wrong axis.

The public AI conversation ranks models on capability: which one reasons best, scores highest, writes most fluently. That axis is real — frontier models are genuinely more capable than open-weight models, and anyone who tells you otherwise is selling something. But for most enterprise work it is not the binding axis.

The axis that actually binds

Enterprise questions are overwhelmingly grounded questions: what does clause 14.2 of this agreement commit us to, what did we quote this customer last year, which SOP revision applies to this line. The answer exists in your documents or it does not exist at all.

For grounded work, output quality is dominated by what the system read, not by how large the model is. A mid-size open-weight model that retrieves the right paragraph — parsed correctly, permission-checked, cited — beats a frontier model that never saw your corpus, because the frontier model can only produce a fluent guess. Fluency without grounding is the most dangerous output class there is: someone will act on it.

That is why the engineering effort in our stack sits in the retrieval layer — layout-aware parsing, hybrid lexical-plus-dense search fused by reciprocal rank fusion, a reranker, and an index that inherits your access model — rather than in chasing parameter counts. When the task is grounded in your data, architecture beats model size. When it is not, it does not; which brings us to the honest half of the answer.

Where frontier models genuinely win

We build on-premise AI, and we publish this list anyway, because pretending it is empty would cost us your trust:

Open-ended reasoning with no private grounding. Strategy drafts, general research, code on public frameworks. Nothing to retrieve, so raw capability is the whole game — and the frontier wins it.

Low volume. Below roughly 90,000 queries a month, no on-premise deployment pays back inside three years — including the cheapest one we build. A team of twelve spending about ₹1,200 a month on API access has no business buying hardware, and we say so.

Spiky, unpredictable workloads. Owning capacity you use two days a month is renting inverted, and worse.

Frontier-only capability. A small set of tasks genuinely need the largest models. If your workload lives there, use them — deliberately.

Not either/or: sovereign by default, frontier by choice

The mature position is not a ban in either direction. In our platform, commercial APIs are available by policy rather than by default: routing to a frontier model is policy-gated, defaults to off, and every routing decision is logged. Sensitive material stays on infrastructure with no egress path — the fail-closed on_prem_required mode refuses rather than transmits. The non-sensitive, capability-hungry task can still go to the frontier when your policy says it may.

You choose the axis per task, and the audit trail shows who chose.

When the grounded axis also wins on cost

Grounded work at volume is where ownership pays. Our mid-enterprise reference fleet (₹41.7 lakh capex) crosses over against API pricing in about 18 months at 1 million queries a month with 700-token contexts; 12 months at 1.5 million; 9 months at 2 million. And the variable that drags crossover earlier is not hardware price — it is context length. Retrieval-augmented and agentic workloads run long contexts by construction, which means the grounded work that most needs your data is also the work that most rewards owning the infrastructure it runs on.

The question to take into the room

Not which model is smartest, but: what does this system need to have read to be useful — and how much of our work is that? Where the answer is "our own material, at volume," the axis is grounding, and architecture wins it. Where the answer is "nothing private, occasionally" — use a frontier model, and spend the capex on something else.

Book an Architecture Consultation →

---

Companion pieces: Three ways to deploy enterprise AI · Intelligence over your data, not over the internet · When you should use Claude or GPT instead