If you have ever watched an agent burn a thousand tokens re-reading the same policy PDF on every turn, Pinecone's pitch for Nexus will land: the retrieval work you do at read time is work you could have done once, upstream. Nexus is a knowledge engine — it compiles your raw business data into task-optimized, cited artifacts ahead of time, so the agent asks for an answer instead of a pile of chunks it has to re-reason over. It moved from early access into public preview on July 1, 2026, and it now has a $20/month Builder tier, which is the part that makes it worth a solo founder's afternoon.
We covered the idea when Nexus was announced — retrieval as a compile step, and why "is RAG dead" is the wrong question. This is the practical companion: what the tool actually is, who should try it, and where it will quietly hurt you.
What it is#
Nexus has two moving parts:
- A context compiler. It ingests your sources and builds knowledge organized around how your company operates — not a flat pile of embeddings, but structured, cited artifacts. This is the "compile" in the metaphor: it runs when your data changes, not when the agent asks.
- A composable retriever. It formats and serves those artifacts in the exact shape each agent needs to finish its task — the right slice, the right structure, with provenance attached.
The interface is KnowQL, a declarative query language built for agents rather than humans. Instead of tuning a vector search and re-ranking chunks, an agent states its request through six primitives — intent, filter, provenance, output shape, confidence, and budget — in one query. It says what it's trying to do, how grounded the answer must be, the format it wants, and its cost/latency ceiling. Pinecone's framing for all of this is blunt: better models won't save your agent — the bottleneck is the knowledge you feed it.
Who it's for#
Nexus fits the team building an agent over a large, slow-changing internal corpus: product documentation, policies, playbooks, contracts, a knowledge base of resolved tickets. If your agent's job is to answer accurately and cite its source, and the source doesn't change every hour, this is aimed squarely at you. The preview also added a native full-text search preview, new cloud regions in Germany and Singapore for data-residency, and a partner marketplace — Box, Unstructured, Teradata, and LlamaIndex — on top of the Microsoft OneLake integration Pinecone shipped in June.
How to start#
- Create a Pinecone account and pick the Builder tier ($20/month) — the new entry point for small teams.
- Connect a source. Start with one high-value corpus, not your whole data lake. Use a marketplace connector (Box, Unstructured, LlamaIndex) or OneLake if you're on Microsoft.
- Let the context compiler build artifacts, then query from your agent with KnowQL — set
provenancehigh if you need citations andbudgetto cap per-call cost. - Eval on your own data. This is the step everyone skips and shouldn't.
The numbers — and the honest caveat#
Pinecone reports task-completion rates above 90%, up to 30x faster time-to-completion, and token spend cut by as much as ~90% versus a conventional pipeline. Those are real numbers and they're also Pinecone's own — internal benchmarks, not independently reproduced, with the largest token savings drawn from single case studies. Read them as a ceiling that a well-fit workload might approach, not a promise. On a badly-fit workload you'll see none of it.
Compilation is only a win when a source is read far more often than it changes. That's the whole decision.
When to skip it#
The failure mode of any compiler is the confidently stale artifact. Classic RAG's appeal was freshness-on-read; Nexus trades that away for cheap, fast, cited reuse. So if your knowledge moves faster than you can recompile — live prices, inventory, open tickets — stay on read-time retrieval. Before you commit to any of these, run the one-ratio test in knowledge engine vs RAG vs long context, and compare the vector-store options the way we laid out in turbopuffer vs Pinecone vs Vectorize and RAG vs long context. Nexus isn't a replacement for a vector database; it's a bet that, for read-heavy and slow-changing knowledge, the reasoning belongs in a build step. For a lot of founder workloads, that bet is right. For the fast-moving ones, it's cache invalidation wearing a new coat.



