Pinecone Release Notes

Pinecone Nexus makes agents more accurate, faster, lower cost, and trusted, outperforming agents that use frontier models alone on Sierra’s agentic work benchmark

NEW YORK, August 6, 2026 / PRNewswire / — Pinecone announced today the general availability of Pinecone Nexus, a knowledge engine that transforms an enterprise's proprietary data and workflows into governed, agent-ready knowledge, delivering it to AI agents in a single call. On its debut on τ-Knowledge, Sierra's open benchmark for the most demanding enterprise knowledge tasks, an agent using Nexus as its knowledge layer posted the top score, outperforming agents built on frontier models from OpenAI, Anthropic, and Google.

The first era of enterprise AI was built by developers for human users. Retrieval systems like RAG pipelines, vector search, and brute-force agentic search assumed a human in the loop who could read the results, catch the wrong ones, and try again. Agents are now the dominant consumer of enterprise AI. Costs are exploding as they run those same systems autonomously. More than 85% of LLM effort goes to retrieving knowledge from the underlying data, driving accuracy down and latency up on every task.

Enterprises moving agents into production face another problem: the model is a commodity because every competitor can buy the same one. The only durable advantage is the enterprise's own knowledge and the way its people do the work. Today's agent stacks give both away, reassembling that knowledge on every call and handing it to a model vendor that turns around and competes with the enterprise.

Pinecone Nexus solves these problems by delivering a knowledge layer purpose-built for agents. Nexus compiles an enterprise's data into governed, domain-specific knowledge that agents query through KnowQL, a declarative query language built for agents. Pre-compiling knowledge lowers token costs by more than 90% over agentic RAG, answers up to 30 times faster, and completes tasks with more than 90% accuracy.

Nexus deploys in the customer's cloud and runs with zero access, on the models they choose, including open-weight models. Outputs are open and portable with no lock-in. Governance is native: field-level access control, per-field citations, confidence scores, PII-aware ingestion, and lineage back to source. Enterprises keep their own knowledge. They don't hand their competitive moat to model vendors.

Nexus relies on subject matter experts to shape the knowledge so it fits the business context and workflows the enterprise runs every day. No central ontologies set once and left to decay. Keeping domain experts in the loop extends Pinecone from a developer-first tool into a platform for the line-of-business professionals now driving AI adoption: financial analysts, insurance underwriters, attorneys, account executives, and customer service representatives.

"Enterprises adopting AI are squeezed from two sides," said Ash Ashutosh, CEO of Pinecone. "Agents burn tokens grinding through raw data, so cost and latency climb while accuracy stays lower than it should be. And every model call risks handing proprietary knowledge to a system that can turn around and compete with you. Nexus puts a knowledge engine in your own cloud, raises accuracy, lowers the total cost of running AI, and keeps your own experts shaping how agents work."

τ-Knowledge is Sierra's open-source benchmark for agentic customer support work that demands multi-step reasoning, strict policy adherence, and coordinated tool use. The benchmark measures exactly the work for which Nexus is built because it is graded on whether the agent drives the system to the correct end state. The best frontier model on the current leaderboard, GPT-5.5, solves 46.4% of the tasks. With Nexus as the knowledge layer, an agent solved 47.4%, the top score on the benchmark. It also achieved 74% less cost per task compared to an agent using a frontier model without a Nexus knowledge layer.

"Enterprises running agentic workloads have been hitting a real ceiling on cost, since retrieval and re-orientation can eat up the bulk of token spend before an agent ever reasons”, says Devin Pratt, Research Director at IDC. “Pinecone's approach, compiling proprietary knowledge into a reusable layer instead of re-deriving it on every call, is a sensible response to that problem. It's a promising direction, and one worth watching as more enterprises evaluate precompiled knowledge layers."

Pinecone Nexus is generally available beginning August 6, 2026, deployed in the customer's own cloud. It sits within the broader Pinecone platform, with the Pinecone Database as its retrieval foundation and Pinecone Marketplace offering production-ready knowledge apps. Learn more at pinecone.io/nexus and pinecone.io/blog/pinecone-nexus-generally-available/.

About Pinecone

Pinecone is the trusted AI knowledge company. Its leading vector database and knowledge engine, Pinecone Nexus, power accurate, performant AI applications for more than 10,000 customers and 1M developers worldwide. Pinecone's mission is to make AI knowledgeable. For more information, visit pinecone.io.

Media Contact

Mike Sefanov
[email protected]
Sr. Director, Communications

Original source

Sierra AI built an internal AI agent and named it Pinecone. We're flattered. So we took the benchmark Sierra built and beat it. Name confusion aside, Sierra and Pinecone landed on the same conclusion about production AI: it's the knowledge, not the model.

Let's clear something up first. Sierra AI, Bret Taylor's AI company, recently announced they had “AI-pilled” the whole company with an internal agent they built and named Pinecone. Great name!

Here is the part where the joke turns serious. Today, on τ-Knowledge, the benchmark Sierra itself built, an agent using Pinecone Nexus posted the top score, ahead of agents running on frontier models alone. Two companies reached the same conclusion independently: in enterprise production, it is the knowledge, not the model, that decides whether AI works.

We did not arrive here overnight. We have been building Nexus for about a year. More than 800 organizations signed up for early access, and since Early Access opened in May we have worked closely with over a hundred enterprises, many of them among the largest in the world, running their Data through it. Today Nexus is generally available. This is what we learned, and why the thesis held.

Start with what those enterprises told us, because it is probably familiar. They moved agents out of the demo and into production, across finance, insurance, legal, retail, and support. The agents stalled. Not because the model was not smart enough. Because of everything the agent had to do before it could be smart.

Picture a support agent handling a billing dispute. Before it can answer, it reads the ticket, searches the knowledge base, reads what came back, searches again, and re-sends everything it has gathered on the next turn. Most of its time and most of its token budget is spent before it decides anything. Then the retrieval itself betrays it. A vector search returns the top matching chunks of text, stripped of the relationships that connect them, and the agent confidently quotes a refund policy that was revised eighteen months ago. A fluent answer grounded in the wrong version of the policy scores zero, and in production it reaches a real customer.

Now multiply that by every ticket, every day. The bill does not scale with the price of a token. It scales with retrieval. Blended inference prices fell about 67% year over year, and enterprise AI budgets kept climbing anyway, because one task fans out into dozens of model calls, each re-reading the same documents. More than 85% of an agent's effort goes to fetching knowledge before it reasons. Goldman Sachs projects token consumption to multiply 24x by 2030. In a survey of 306 teams running agents in production, reliability, not model capability, was the top challenge, and 68% cap their agents at ten steps before a human has to step in. A bigger model does not fix a bill that scales with retrieval, or a completion rate capped by what the agent can reach.

There is a second cost. The model is a commodity, because every competitor can buy the same one. The only durable advantage an enterprise has is its own knowledge and the way its people work. Most agent stacks reassemble that knowledge on every call and hand it to a model vendor. Satya Nadella has made this the center of Microsoft's argument: models are becoming interchangeable, and the moat that lasts is the enterprise's own data, context, and memory, kept under its own control. Alex Karp of Palantir has put it more sharply, warning that frontier labs have oversold their models while quietly absorbing the proprietary edge of the companies paying for them, so enterprises end up paying to lose their advantage. Different companies, same warning from two leaders serving world’s largest enterprises. The moat leaks out one API call at a time.

That is the problem Nexus was built to remove, and the fix is not a better model. It is moving the knowledge work out of the per-query loop.

Nexus compiles your data once, ahead of time, into governed, domain-specific knowledge, and agents reuse that compiled layer on every call. The person who understands the work describes it in their own terms: the entities that matter, how they relate, and the shape of the answers the work needs. Nexus turns raw sources into structured knowledge, including the relationships that ordinary retrieval throws away, and resolves conflicts between sources up front, so the layer knows what it knows and flags what is contested. Agents then ask through KnowQL, a query language built for agents. The agent states what it needs and gets back a typed, cited answer in a single call. Compile once, answer every time.

Go back to the support agent. With a compiled layer it stops grinding through documents and asks for the answer instead. It gets the current policy, with a citation, and because it now has customer-level context it knows the one question only the customer can answer, and when to ask it. We know this because we pointed Nexus at our own support queue on July 17. The share of tickets the agent resolved on its own went from 24.6% to 55.1%. More than half of our tickets now close without a person touching them.

The same shift shows up on Sierra's benchmark. τ-Knowledge grades an agent on whether it drives the system to the correct end state, and its hardest domains make the agent find and apply the right policy before it acts. On the banking domain, ninety-seven of those tasks, we gave the same frontier models a Nexus layer to query and watched their behavior change.

The model calls roughly halved, and each one carried less context. GPT-5.2 gained 12% accuracy at 80% lower cost. GPT-5.5 held its accuracy at 77% lower cost. In dollars, that is a task that cost $1.45 falling to $0.53, and the advantage held on 96 or 97 of the 97 tasks, so it is not an average hiding a wide spread. Across the full benchmark, an agent with Nexus posted the top score, 47.4% against the best frontier model's 46.4%, at 74% less cost per task.

Task completion is the number benchmarks chase. Cost is the number that decides whether an enterprise AI program returns anything. When the same model delivers the same accuracy at a third of the prices, AI finally delivers on the promised enterprise ROI business case. It also drops low enough that, in many cases, smaller and open-weight models clear the bar, which compounds the saving. The AI strategy initiative now becomes the Production AI initiative.

None of that matters in a regulated industry if the answer cannot be defended, which brings us back to Nadella and Karp. Both are describing a crisis of trust: keep control of your knowledge, and be able to prove where a decision came from. Nexus is built that way. It runs in your own cloud, on the models you choose, with no standing Pinecone access to your data, so your knowledge never leaves your infrastructure. Every field it returns carries a citation and a confidence score. Every answer traces back to the source document and clause it came from. Access control is applied when knowledge is retrieved, not requested in a prompt. That is what lets an agent's answer survive a security review and an auditor, and it is what turns moat preservation from a keynote line into something an enterprise can operate.

One more thing the hundred-plus enterprises taught us. They validated accuracy fast, usually in the first week. The rest of the work was keeping the layer true as the world moved: new tickets daily, contracts amended, a process doc revised on a Tuesday, and the wiki that disagrees with the contract. Across those engagements they compiled 3.5 million source chunks into nearly 26,000 structured knowledge artifacts, drawn from support tickets, contracts, filings, research papers, and call transcripts. Nexus curates incrementally, so only what changes gets recompiled, and the person who owns the domain keeps control of how the knowledge is shaped. The layer worth building is the one still true in month twelve, not just the one that demos well in week one.

You do not wait for a better model to build a reliable agent. You give the model better knowledge.

Pinecone Nexus is generally available today, in your own cloud. Learn more at pinecone.io/nexus.

Original source

Pinecone Nexus Is Now Generally Available

Five weeks ago we opened Pinecone Nexus to Public Preview. Today Nexus is generally available to be deployed in your own cloud.

On τ-Knowledge, Sierra's open benchmark for agentic customer-service work, we gave GPT-5.5 and GPT-5.2 a Nexus knowledge layer and ran them against the same models using the benchmark's own tools. GPT-5.5 held its accuracy at 77% less cost per task. GPT-5.2 achieved 12% more accuracy and saw 80% cost reduction. Both cut their tool calls and model calls roughly in half.

We also pointed Nexus at our own customer support queue. The agent handling inbound tickets went from resolving 25% of them on its own to 55%.

Here’s why the benchmark reads the way it does, what Public Preview taught us about how enterprises manage knowledge, and what GA changes for you.

What's Ready Now

The durable advantage an enterprise has is its knowledge and how its people do the work. Every agent call that ships that knowledge to a third-party model transfers a piece of that advantage to someone else. Nexus keeps it where it belongs: in a governed layer, in your cloud, shaped by your own experts. That principle runs through everything shipping today. Nexus is ready for the standard enterprise motion: evaluate, pilot, procure, run in production. As of today:

• Deployment. The Nexus data plane runs in your own cloud, on AWS, Google Cloud, or Azure. Your documents and compiled knowledge never leave your infrastructure.

• Model hoice. Nexus runs on the models you choose, including open-weight. You supply the model credentials, and inference calls go from your cloud to the provider you name. Each workflow can use an ensemble, with the right model picked for each step.

• No lock-in. The knowledge layer Nexus compiles is yours. You can download it as an archive.

• One interface. Agents, chatbots, AI search, and recommendation systems all query the same layer through KnowQL. Find the specifications at spec.knowql.org.

• Platform fit. Nexus sits within the broader Pinecone platform, with Pinecone Database as its retrieval foundation and Pinecone Marketplace offering production-ready knowledge apps.

All of that rests on one claim: enterprise agents hit a knowledge ceiling long before they hit a model ceiling. To check it, we ran the following test.

The Benchmark: Same Models, Different Knowledge

τ-Knowledge is Sierra's open-source benchmark for agentic customer-service work: multi-step reasoning, strict policy adherence, coordinated tool use. It grades on whether the agent drives the system to the correct end state. Its newest domains are knowledge-intensive by design. The agent has to find and apply the right policy before it acts, and a plausible answer grounded in the wrong version of a policy scores zero. That is the workload we built Nexus for, so we ran its banking_knowledge domain that has 97 tasks, where the agent has to find and apply the right policy before it acts.

Note: Results are from benchmarks ran as of Aug 4, 2026.

GPT-5.2 on its own averaged 42.5 tool calls and 81.7 model calls per task, grinding through documents to assemble an answer. With Nexus it asked for the answer instead: 17.7 tool calls, 42.6 model calls, and about six KnowQL queries per task. Half the model calls, and each one carrying less context, is where a $1.45 task becomes a $0.53 task. GPT-5.5 moved the same way, from 28.6 tool calls and 60.9 model calls down to 16.0 and 39.4. The cost advantage held on 97 of 97 tasks for GPT-5.2 and 96 of 97 for GPT-5.5, so this is not an average hiding a wide spread.

Why the gap is this large: the models by themselves have enough reasoning capability. What they lack is grounded knowledge they can reach cheaply. And it gets expensive for an agent when it spends most of its token budget locating and re-reading policy documents. Give the same model a compiled, governed layer it can query in one call and the reasoning gets spent on the task.

Where Enterprise Agents Break in Production

Enterprises have moved agents out of demo and into production across finance, insurance, legal, retail, and support. The move exposes four failures at once which can be a deal-breaker for enterprises in regulated industries:

• Task completion and accuracy on hard corpora stalls short of what production needs.

• Token bills climb faster than the value the agents return.

• High latency per task breaks production service levels.

• And the answers carry no citation, so nobody can trace a claim back to the document and clause it came from.

Most enterprises blame the model and wait for the next frontier release. But the data doesn’t support this approach. In a survey of 306 teams running agents in production, reliability outranked model capability as the top development challenge, and 68% cap their agents at ten steps before a human steps in. Meanwhile it was evident that cost does not respond to cheaper models. Blended inference costs fell about 67% year over year while average enterprise AI budgets rose from $1.2 million in 2024 to $7 million in 2026, because one agent task runs many model calls, each re-sending the context gathered so far. Goldman Sachs projects token consumption to multiply 24x between 2026 and 2030, so the waste per task compounds. A bigger model does not fix a bill that scales with retrieval, or a completion rate capped by the context an agent can reach.

Failure points in accuracy, latency, cost, and trust share one root cause, which is the work an agent does before it reasons. It reads the task, searches for context, reads the result, searches again, and re-sends everything it has gathered on the next turn before it takes a single action. Most of the token and latency budget is spent before the agent decides anything.

The retrieval itself is lossy. A vector or hybrid search returns the top matching chunks of text, stripped of the relationships that connect them. The agent gets fragments and has to reconstruct, on every request, how a policy connects to a record or how one clause qualifies another. When the answer depends on the relationship rather than the passage, top-K retrieval misses it. In a knowledge-intensive task, a fluent answer grounded in the wrong version of a policy scores zero.

Agentic RAG re-derives context on every query and re-embeds whenever the data or the task changes. Central ontologies, the model-the-whole-business approach from Palantir and Microsoft, are authored up front by a team that does not do the work, and they decay from the day they ship. Either the knowledge is assembled at query time, or it is modeled once and left to drift. That is the ceiling.

How Nexus Works: Compile Once, Answer Every Time

Nexus moves the retrieval work out of the per-query loop. It compiles your systems-of-record data into governed, domain-specific knowledge once, ahead of time, and agents reuse that compiled layer on every call. Three parts that make it work:

The manifest

A subject matter expert describes the work in their own terms, and that description becomes a Manifest: the entities that matter, the relationships between them, and the shape of the answers the work requires. The person who understands the domain defines it, not a central modeling team. A Manifest is scoped to a job rather than to the whole company.

The compiled knowledge layer

Guided by the Manifest, Nexus compiles raw sources into structured knowledge artifacts: summaries, structured extracts, and the entity-and-relationship graph that top-K retrieval throws away.

KnowQL

Agents query the compiled layer through KnowQL, a declarative language built for agents. The agent states what it needs, the question, the output shape, the scope, the grounding, and the budget. It gets back a typed, cited answer in one call.

Four Failures, Solved at the Knowledge Layer

• Accuracy: The compiled layer keeps the relationships between facts and carries per-field citations and confidence, so an agent gets connected, grounded knowledge rather than a bag of passages, with conflicts already resolved by the expert. Task completion clears the ceiling that keeps agents stuck in pilot, on answers an auditor will accept.

• Latency: One KnowQL call against a precompiled layer replaces the retrieve-evaluate-re-retrieve loop and its round trips. Agents meet production service levels instead of timing out and losing the user.

• Cost: Compiling knowledge once and reusing it removes the largest line item in an agent's bill, and re-curation processes only what changed rather than the whole corpus. AI spend becomes predictable and capped instead of scaling with every query, and low enough that smaller and open-weight models become viable.

• Trust: Governance lives at the data layer, enforced by construction rather than requested in a prompt. Access control is applied at retrieval. Every field carries a citation and a confidence score. PII is tagged at ingest. Each answer traces back to its source. The compiled layer runs inside your own cloud with no standing Pinecone access, on the models you choose. Agents pass a security review and deploy in regulated industries.

We Ran It On Our Own Support Queue

We put Nexus behind our own support agent on July 17th.

More than half of our tickets now close without a person touching them. This was made possible because Nexus holds contexts about our customer accounts, so the agent can reason across everything available to it and sort a question into three buckets: what it already knows, what it can look up, and what only the customer or another team can tell it. That third bucket is where Nexus made a significant difference to the overall performance against business metrics.

A Knowledge Layer That Stays True

Public Preview customers created 300 contexts, compiling 3.5 million source chunks into nearly 26,000 structured, queryable knowledge artifacts. The corpora that flowed through those projects: support knowledge bases, legal contracts, financial filings, research papers, meeting minutes, and call transcripts. We asked for bounded corpora where a single question draws on files across the corpus, and that is what we got.

The headline learning from those engagements: customers validate accuracy fast, usually in the first week of evaluation. The rest of the engagement goes to a different question. How do we manage this knowledge layer as a living thing? Three demands came up in almost every conversation.

Keeping knowledge current has to be effortless. Enterprise corpora do not hold still. New tickets land daily, contracts get amended, a process doc gets revised on a Tuesday. Preview customers wanted new source data flowing into the compiled layer as it arrives, incrementally, without rebuilding from scratch. Nexus curates incrementally: new and changed sources flow into the existing knowledge layer instead of triggering a full rebuild.

The knowledge layer has to follow the business. The right knowledge structure changes as the work changes. A revenue team reorganizes its pipeline stages. A compliance team inherits a new regulation. The questions people ask in month three are not the questions from month one. Today the SME handles this directly: update the Manifest to reflect the new requirements, re-curate, ship. That loop is fast, and it keeps the person who understands the domain in control. Every query an agent runs against the layer is also a signal about what the layer should contain, and a Manifest-driven architecture can read that signal. We are investing there.

The knowledge layer has to handle source conflicts. The wiki says one thing, the contract says another, and one of them is three years stale. A retrieval system hands the agent both, which is how confident wrong answers get made. Curation surfaces conflicts in the compiled knowledge, where the SME can adjudicate them. A knowledge layer should know what it knows and flag what is contested.

The preview confirmed a design conviction. The durable value is a knowledge layer your experts can keep true over time, well past the first curation run. Approaches built on static, declarative context, central ontologies included, define knowledge once and let it decay. Nexus recompiles as the outcome requirements change, guided by the person with direct experience of the domain.

Start Building

If your agents are unreliable on your corpus, or token and latency costs keep climbing without the accuracy to show for it, the ceiling is the knowledge layer. That is the problem Nexus was built for, and as of today you can solve it with a standard procurement conversation.

Pinecone Nexus is generally available now. Learn more at pinecone.io/nexus, or Start Your Trial today.

Original source

A look at the self-service system built to emulate real customer workloads on synthetic data.

TLDR: Sizing a Pinecone deployment (on-demand or dedicated, how many replicas, which node type) used to mean an engineer hand-running load scripts on an EC2 box and eyeballing the output, one question at a time. A pipeline now takes a workload spec, builds and loads a matching index, and sweeps it across the full grid of configurations automatically, so customers get a sizing recommendation backed by a measurement of their own workload instead of an engineer's best guess.

Every meaningful architecture decision a customer makes on Pinecone comes down to a question that can't be answered by looking at a schema alone. How will this actually behave under my workload?

For a long time, the only way to answer that was an engineer hand-running load scripts on an EC2 box and eyeballing the output. That worked for one question at a time, not the volume of sizing decisions Pinecone actually needed to make, and it left customers without a number they could plan against.

To close that gap, Pinecone built a pipeline that takes a workload spec and turns it into a fully provisioned, loaded, and measured index automatically. Sizing a deployment now takes a batch of rows and a click, and every customer gets an answer backed by a measurement of their own workload instead of an engineer's best guess.

The Decision Is a Measurement Problem

A real recommendation is specific: at a given query rate, dataset size, and filter pattern, it names the replica count where p99 stops improving and what each step up costs. Getting there means sweeping across a grid of several query rates, several replica counts, on-demand versus dedicated, and one node type versus another, all built on an index shaped like the customer's real one.

When done from scratch, this takes tens to hundreds of runs, each with its own setup, import, request pattern, and teardown. Deployments got sized on intuition and prior experience, and the same trade-offs got re-litigated every time a new customer showed up with a familiar-looking workload. Automating that grid started with the simplest thing that could work.

What Got Built

The first version automated what an engineer already did by hand: a script on an EC2 instance (a single AWS virtual machine), with someone watching it run. That worked for one-off questions. A sweep meant repeating up to hundreds of times the setup, load, and teardown by hand for every cell in the grid. Pinecone's own VSB (Vector Search Bench) generated the load fine. Provisioning, capacity setup, and teardown around it were still manual, and that's what made a sweep slow.

A pipeline now wraps VSB with that missing automation: it provisions the index, configures capacity, runs the load, records results, and tears down, so a sweep runs unattended from a row in a database to a measured result.

A user describes the workload they want to test as one or more rows in a table fronted by a simple UI, and the system does the rest.

The end-to-end flow:

A session is a batch of rows submitted together — typically the full grid for one customer question. Triggering it launches a dispatcher that groups the rows by index shape and brings up one EC2 worker per distinct index shape. Each worker claims its rows one at a time and runs them serially.

That grouping is what keeps a sweep economical. Because an index is identified by its dimensions, vector count, and similarity metric, the first row in a shape pays the one-time import cost, and every subsequent row reuses that index, only reconfiguring capacity (say, changing the replica count) and re-running the benchmark. A 48-cell sweep over one dataset imports the data once and measures 48 times.

For heavy query loads, a single load-generating box can become the bottleneck before the index does. So a session can request multiple load generators. The worker coordinates them as a distributed fleet, so the target query rate is actually met rather than capped by one box's limits.

A workload is a set of knobs

The whole point is to describe a customer's workload faithfully, so each row exposes the dimensions that actually move performance and cost:

• Index shape. Vector count, dimensions, distance metric, and which sparse model is in play for hybrid workloads.
• Capacity. On-demand (serverless) versus dedicated read nodes, including the node type and replica count, and a path to import cheaply on serverless and then switch to dedicated for the read benchmark.
• Query load. Target queries per second, duration, top_k, whether queries return values and metadata, and what metadata filters are applied to queries.

Each row also records what happened: achieved throughput, request counts and capacity limits, the full latency distribution, and recall. That's what a recommendation gets built on.

What This Has Meant for Customers

The pipeline changed the kind of conversation possible with customers, in three ways.

Cost.

The biggest win is that customers stop over-provisioning. Instead of buying headroom "to be safe," they provision exactly enough to hit the performance they're after. By sweeping a workload across replica counts, capacity modes, and node types, the pipeline pinpoints the configuration where the performance requirements are met and spend stops buying improvement. The customer gets the latency and throughput they need at the lowest configuration that delivers it, backed by a measurement of their actual workload.

Performance.

Going the other direction, when a workload genuinely needs more replicas, a larger node type, a different capacity mode, the data shows exactly where the latency curve bends and what the next step buys. The recommendation comes with the data behind it, so it holds up three months later instead of getting re-litigated.

Expectations.

Maybe the most valuable outcome is the least flashy. A customer about to scale, or about to change their architecture, can see what's going to happen before they commit. Their workload gets benchmarked as it stands, the traffic they're growing into gets modeled, and the latency and throughput on the other side get laid out ahead of time. That turns a scaling event from a leap of faith into a planned change, with far fewer surprises in production.

The pipeline runs sweeps that used to take an engineer a week, and it runs them in the background from a batch of rows and a click. That time now goes into the next workload question worth answering, instead of re-running the last one by hand.

Original source

Delivering scoped, accurate context, without pre-labeling entire datasets

Semantic search returns results that are close in meaning, not necessarily results that answer what someone meant to ask. A person scanning through can tell the difference and skip past the ones that miss the mark. An agent can't: it takes whatever comes back as ground truth and starts acting on it, with nobody checking the work first.

The sharpest version of that gap is unstated context: a query can be perfectly clear to the person asking it and still leave out information a system needs to answer it correctly. This post walks through that failure mode using a public dataset of 10,000 CNN news articles from Hugging Face, spanning 2022 to 2024, with each article's text and topic label stored as metadata, and shows how Pinecone's new text match filters fix it without requiring the dataset to be pre-labeled for every case in advance.

Follow along with the queries and results below in this notebook.

The ambiguity problem

Take the query "Who are the top presidential candidates?". A user in the United States asking this almost certainly means the U.S. presidential election. Nothing in the query says so.

Dense vector search alone returns this:

Rank Article ID Score Excerpt 1 3433 0.8168 First round of voting, featuring 11 presidential candidates, takes place on April 23. Le Pen and Macron are tipped to... 2 8054 0.8138 Presidential candidates for France's mainstream parties failed to make the second round. Poll favorite Emmanuel Macron... 3 3421 0.8130 France holds its first round of the presidential election on Sunday. Candidates react quickly to the death of a pol...

Every one of these is about the French election, and every one is a legitimate semantic match, yet none of them answer the question the user actually meant to ask.

The obvious fix is to have the user rewrite the query as "top US presidential candidates," but that comes with two costs. First, it pushes the burden of writing a precise query back onto the user, who came in with what felt like a simple question. Second, in an agentic pipeline, a bad first retrieval costs more than a re-query: ask an agent to chart polling trends and analyze who's rising and falling, and if it builds that analysis on French election data, the tokens spent generating the wrong answer are wasted, so are the follow-on tool calls, and the error compounds at every step downstream. Multiply that across a few thousand queries and the cost stops looking incidental.

Restricting results by country with metadata filtering is possible, but it means labeling every record for every dimension that might matter, in advance: country, election year, local versus national race. Any filter dimension discovered after the fact requires reprocessing the entire dataset, which for production systems can mean billions of records, before it can be applied.

The solution: text match filtering

Full Text Search from Pinecone, now in public preview, supports text match filters: a lexical query that restricts the candidate pool for a semantic search to records matching specific text, without pre-labeling metadata for every case an application might need to handle.

Applying a text match filter for "United States" to the same query changes the candidate pool before the semantic search runs:

Rank Article ID Score Excerpt 1 5326 0.8012 (CNN) Former Vice President Joe Biden swept to victories across southern states on Super Tuesday, but Vermont Sen. Bernie Sanders... 2 7641 0.7992 (CNN) The Human Rights Campaign Foundation announced Thursday it will host a CNN Democratic presidential town hall in California... 3 9859 0.7987 (CNN) President Donald Trump and Democratic presidential nominee Joe Biden have taken very different positions on a range of polic...

The query, model, and index are identical to the search above. The only difference is that the candidate pool was scoped to records containing "United States" in the article body before the vector search ran, and all three results now land on the actual U.S. race.

Where this generalizes

News search makes the ambiguity easy to see, but the same pattern shows up anywhere a query assumes context it doesn't state: industrial manuals scoped to a machine number or error code, insurance claims scoped to a policy number or type, legal search scoped to a case or jurisdiction. Most semantic search applications run into some version of this, since most queries leave something unstated.

These filters chain: combine them with boolean operators, stack them with metadata filters, or layer on more text match filters against other fields, and the candidate pool narrows along several dimensions in a single query.

What changes for agentic applications

An agent has no step where it double-checks that a semantically close result is actually the right one for the task. Whatever filtering needs to happen has to happen before the results reach the agent, not after. Text match filtering moves that correction into the query itself, without requiring the dataset to be pre-labeled for every filter an application might eventually need. For pipelines where a bad retrieval turns into a chain of wasted tool calls, narrowing the candidate pool at query time is cheaper than catching the error after the fact.

Original source

TLDR

Pinecone's V2 sparse index organized posting data in document-major blocks, which forced every query to load the entire index regardless of which terms it contained. V3 reorganizes the index around terms: each term owns its own sequence of posting blocks, and a query only loads the blocks for terms it actually references. From disk, this reduces I/O by 151× for SPLADE queries and 1,428× for BM25 queries, with no loss in recall, and measurably better recall for BM25.

Sparse indexes at Pinecone

In March 2025, Pinecone launched sparse-only indexes, bringing keyword and lexical search into the same serverless platform as dense vector retrieval, supporting both BM25 and learned sparse models including SPLADE and Pinecone's own pinecone-sparse-english-v0.

Sparse retrieval is built on inverted indexes, a data structure at the heart of search engines for decades. Each term gets mapped to a posting list: a record of every document containing it and a relevance score for that document. Traditional scoring functions like BM25 weight terms by frequency within a document and rarity across the corpus. Learned sparse models like SPLADE go further, using a transformer to assign context-aware weights and expand a document's representation to include related terms. A document about machine learning might score non-zero on "training" and "inference" even without those words appearing verbatim. Pinecone's implementation runs this on the MaxScore algorithm, which makes retrieval fast at scale by skipping documents that can't beat the current top-k threshold rather than scoring every candidate.

Supporting sparse vectors alongside dense, operating a separate Elasticsearch or Solr cluster is no longer needed, and the search pipeline gets further consolidated..Sparse and dense indexes are queryable together in a single index (sparse for keyword matching, dense for semantic breadth) with Pinecone managing both.

The scale problem

The architecture that powered V1 and V2 organized posting data in what's called a document-major layout. Documents are divided into groups by ordinal position (1–1000, 1001–2000, and so on). Each group gets a block on disk containing the interleaved posting data of all terms in any of the group’s documents.

At query time, the search algorithm has to read each of these blocks, because any block might contain postings for any of the query's terms. A query for "apple" and "orange" reads the block covering documents 1–1000, then 1001–2000, then every other block through the entire index. There's no way to skip ahead without reading.

When an index fits in memory, this is survivable. SIMD scoring is fast, and scanning several gigabytes at memory bandwidth completes in hundreds of milliseconds. But as sparse indexes gained adoption, larger workloads appeared. A billion-vector SPLADE index can run to hundreds of gigabytes. At that size, keeping the full index in memory is expensive. And in a serverless environment where many users share the same underlying hardware, it often isn't feasible: memory is allocated dynamically across workloads, so one large index needing most of the available memory delays other active indexes.

When an index can't stay in memory, every query becomes a series of disk reads—nd reads from disk are orders of magnitude slower than memory. The V2 disk benchmarks make this concrete: every SPLADE query took 3,407 milliseconds regardless of what it was searching for, at p50, p90, and p99. The completely flat distribution exposed disk throughput as the limiting factor.

For billion-scale indexes, the only path to sub-second latency used to be dedicated hardware sized to keep the full index in memory.

What V3 changes

We needed a way to reduce disk reads. Specifically, instead of loading the whole index into memory, we needed to devise a method to identify and load only the relevant postings. That way, a query touching 2 terms out of a 50,000-term vocabulary still had to read all 50,000 terms' worth of posting data (because they were packed together indistinguishably).

V3 overhauls the layout so queries can skip directly to what they need.

• Term-major layout: Each term gets its own blocks on disk; a query only loads data for the terms it contains.
• In-memory term directory: A compact map keeps every term's disk location in memory, so finding a term costs no I/O.
• Metadata-first block skipping: A small summary block per term lets the algorithm decide what to skip before loading any posting data.
• Compressed posting blocks: Doc IDs and scores are compressed per-term, reducing block sizes up to x2.5.

Organizing by term instead of by document range

V3 flips the grouping strategy: it groups posting data by term instead of document range. All of "apple"'s postings live in their own contiguous sequence of blocks on disk; all of "orange"'s postings live in another sequence elsewhere. A query then reads only the blocks for the terms it actually contains. A SPLADE query typically includes dozens of non-zero terms; a BM25 query, just a few. Against a vocabulary of tens of thousands, both are a small fraction of the index to load.

A compact directory that lives in memory

Reorganizing around terms creates a new problem: with posting data scattered across potentially tens of thousands of separate locations on disk, how does the search algorithm find a given term's blocks without scanning the index?

V3 solves this with a term directory, a compact map stored in the index metadata that records, for each term, where its posting data begins on disk. The metadata loads into memory when the index is opened and stays there. Every term lookup is an in-memory operation; finding a term's disk location costs no I/O.

The directory uses Elias-Fano encoding, which compresses sorted integer sequences while preserving O(1) lookup. For 100,000 terms, the result fits in about 300 KB (small enough to stay in the CPU’s L2 cache).

Structure Size (100K Terms) Lookup Sorted array of pairs ~800 KB O(log n) Hash map ~2.4 MB O(1) Elias-Fano ~300 KB O(1)¹

¹ O(1) positional access by term ID; the term dictionary resolves strings to dense integer IDs upstream.

Deciding whether to load a block before loading it

Even after locating a term's posting data, not every block for that term may be worth loading. A term that appears in many documents will have many posting blocks. MaxScore pruning can skip the weaker ones, but applying that logic requires knowing each block's maximum possible score before deciding to load it.

V3 stores this information in a metadata block at the start of each term's data. Before any posting blocks are read, the search algorithm loads this metadata block (a small, fast I/O) and gets back a summary for every posting block the term contains: the range of document IDs in the block, the highest score any posting in the block achieves, and the number of postings. With that summary in hand, three classes of skip decisions happen without reading any posting data: metadata filtering, MaxScore pruning, and position skipping.

Compressing what's left

The blocks that aren't skipped need to be as small as possible to reduce I/O and better fit in the memory cache during scoring. V3 applies two compression techniques that only work best with its term-major layout.

Document ID compression.

Rather than storing each document ID as a full 32-bit integer, V3 stores only the offset from the block's minimum document ID. The minimum ID is already recorded in the metadata block, so the decoder knows the reference point before reading any posting data. The maximum offset within a block determines how many bits each offset needs. For example, a block spanning documents 50,000 to 50,128 only needs 7 bits per offset rather than 32. SIMD operations pack and unpack each posting block’s values in a single pass with no branching. The result is 2–2.5× compression for tightly clustered blocks, and meaningful compression even for spread-out ones.

Block Spread Bits per ID Total Tight (range < 256) 8 256 B Medium (range < 64K) 16 384 B Wide(range < 1M) 20 448 B

A full posting block fits in a handful of L1 CPU cache lines.

Per-term score quantization.

Scores are stored as single bytes mapped to a score range. Whereas V2 used one range across all terms in a document block to represent score, V3 uses each term's own range. This finer mapping explains V3’s increased recall, especially for BM25 models.

Finding the right heuristics

The performance-critical decisions—window sizing, merge strategy, and scoring granularity—depend on hardware cache geometry and posting list density in ways that resist analytical derivation.How these parameters got tuned turned out to be the most unconventional part of the build, and in some ways more interesting than the structural changes it was optimizing.

The approach: property-based tests and recall benchmarks as the fitness function, with Claude driving hundreds of iterations testing algorithmic combinations, and a human reviewing direction and killing runs that were clearly going wrong. When a property test failed or recall dropped, the loop backtracked. When throughput improved with recall holding, the change was retained. The heuristics that shipped (window sizes tuned to L1 cache, adaptive behavior across posting densities) came from this iterative, empirical process. It worked because the test harness was rigorous enough to trust, as a false pass would have been worse than a slow run.

Results

Benchmarks run on MS MARCO, a standard retrieval corpus of 8.8 million documents using SPLADE embeddings (averaging ~45 non-zero query terms) and BM25 (averaging ~3 query terms). BM25 gains are larger because sparse query vectors reference fewer terms, leaving more of the index for V3 to skip.

Scanning under I/O pressure (from disk)

This is the case V3 was built for: an index too large to keep resident, where every query pays in disk reads. Under V2, that meant reading the whole index on every query, no matter how few terms it touched.

Metric V2 V3 Change Recall@100 1.0000 1.0000 -- Bytes loaded / query (p50) 3,396 MB 22.5 MB 151x less Latency p50 3,407 ms 128 ms 27x faster Latency p90 3,407 ms 252 ms 14x faster

V2's latency is flat across percentiles. Every query did the same work, so every query took the same time— a little over three seconds regardless of what was asked. V3 executes those same queries in a couple hundred milliseconds, scaling by the number of terms involved rather than the flat size of the index.

Metric V2 V3 Change Recall@100 0.9840 0.9840 -- Bytes loaded / query (p50) 714 MB 0.5 MB 1,428× less Latency p50 715 ms 6 ms 119× faster Latency p90 719 ms 13 ms 55× faster

For a typical short query, V3 reads 1,428× less data and returns in milliseconds, because it pays only for the terms it contains. The recall a user gets back is identical.

The payoff shows up directly in production. One customer running billion-scale sparse queries migrated to V3 and went from multiple seconds per query to 40 milliseconds on the same hardware. For their users, that’s the difference between a search that stalls and one that feels instant. It’s also what makes billion-scale sparse retrieval affordable on shared serverless infrastructure, rather than something that demands dedicated hardware sized to the worst case.

Conclusion

The document-major layout had one flaw that scale exposed: queries couldn't skip all irrelevant data. Every query read the entire index, so a two-term lookup costed as much as scanning everything. This worked well when indices could fit in memory.. Once they didn't, every query fell back to disk and the design didn't hold.

V3 reorganizes posting data around terms rather than document ranges:

• each term owns its blocks
• in-memory directory finds them with no I/O
• per-block metadata lets the algorithm skip what it doesn't need before reading it from disk
• per-term compression shrinks what remains

A full-index scan becomes a read that touches only the terms a query contains.

This algorithm runs in all of Pinecone's sparse indexes today (thanks to the compaction process, changing algorithms was a completely online procedure, without disrupting any ongoing operations). Queries pay for what they use, recall holds, and billion-scale sparse retrieval runs on shared serverless infrastructure alongside dense retrieval in a single pipeline.

Original source

Full-text search now supports two new ways to match text:

• Fuzzy matching (typo tolerance) — In a query_string search, append ~ to a term to match indexed terms within a small edit distance: body:(compxter1) matches computer. Use term for an automatic distance based on term length, or term~N for a fixed distance (N is 0–2). Fuzzy works on existing indexes with no reindex. See Fuzzy matching.
• Substring search with n-grams — Configure a text field for character n-gram tokenization to match on partial words, prefixes, and autocomplete-style queries. Add an ngram object (min_gram, max_gram, prefix_only) to a field’s full_text_search config at index creation, then query it with ordinary text or query_string searches. See Substring search with n-grams.

Full-text search remains in public preview under API version 2026-01.alpha.

Original source

Organizations on the Enterprise plan with SSO can now manage Pinecone roles directly from their identity provider (IdP), instead of assigning them manually in Pinecone. Two modes are available:

• SAML role management sets each user’s organization and project roles from a SAML attribute on every SSO login.
• SCIM provisioning syncs members and their roles in real time as you add, update, deactivate, or remove them in your IdP.

Both modes use the same pinecone:* role values and work with Okta and other SAML 2.0 / SCIM 2.0 providers. Configure them under Settings > Access > Identity provider in the Pinecone console. For more information, see Manage roles with Okta and SCIM provisioning with Okta.

Original source

Pinecone now offers an expanded set of roles for managing access to organizations and projects. New Organization member and Project member roles grant more restricted access than the owner and manager roles, and projects now support granular editor and viewer roles (project, control plane, and data plane) that you can assign to users, service accounts, and API keys.

To better communicate the access hierarchy, organization owners are now shown in each project’s member list. This replaces the separate project-role assignments that could fall out of sync with the access organization owners inherit to all projects. Effective permissions are unchanged.

If you used the previous role model, the User role has been renamed to Manager: the organization-level User role is now Organization manager, and the project-level User role is now Project manager. This is a name change only—permissions are unchanged and existing assignments are migrated automatically.

You can assign and manage roles in the Pinecone console or programmatically with the Admin API. For more information, see Manage roles and access, Organization roles, and Project roles.

Original source

Seven weeks ago, we announced early access to Pinecone Nexus, to deliver knowledge to AI agents.

We’ve since partnered with a broad cohort of users spanning massive data, high complexity, and stringent accuracy, latency and cost requirements. Today, we are opening up public preview.

Distributed enterprise knowledge, compiled into something agents can rely on.

Agents built around frontier models are great at world knowledge, complex reasoning, and synthesizing information across disciplines. Finding specific information buried across files is a search problem, one vector databases have been chipping away at for years.

There's a third kind of knowledge that neither of those touches: business context. It's what a three-year employee knows without searching; which internal process doc reflects how things actually work today, what the quarterly goals mean in practice, how a policy in one department connects to a decision in another. It lives distributed across your enterprise in contracts, wikis, HR docs, meeting notes, support tickets, and financial records. Most of it has been written down somewhere, often many times over, but written down isn't the same as compiled, and an agent walking into a task needs the latter.

Every time an agent starts a task, it starts from zero on all of this. It can piece things together on the fly, but the cost shows up in tokens, in time, and in answers that are half right.

Pinecone Nexus is a knowledge engine that closes that gap. It compiles an enterprise's distributed knowledge into a structured layer agents can query directly, shifting token spend out of the per-query retrieval loop and into a one-time curation step.

Today, we're opening it up to anyone with a business use case. Pinecone Nexus is now in Public Preview.

What's Ready

Starting today, request access to Pinecone Nexus and see what curated knowledge does for agentic workloads on the dimensions that matter: cost, speed, and accuracy.

Nexus is built for bounded corpora where agents need to reason across documents. It's at its best on the kind of corpus where a single question touches dozens of files and standard retrieval starts falling apart.

There are two ways in:

Preview Playground

request access today and get a live environment to connect your data, design a Context, and run real queries. It's enough to validate the approach on something real before committing to a deployment.

BYOC Deployment

for production workloads, request a dedicated deployment. The cluster runs in your VPC with no shared infrastructure. Pinecone never has access to your data, your documents don't leave your infrastructure, and there's no shared compute with other tenants. Our deliberate focus on this deployment model is to align with the needs of enterprises where data residency, security, and compliance are non-negotiable.

See Nexus in Action

The demo above uses a synthetic financial services corpus of a household's complete set of financial records including their goals, plans, meeting notes, and portfolio documents. It’s the kind of corpus where a question like, "How are the Chens tracking against their retirement goals?" touches dozens of documents across multiple years, and unlike Nexus, a standard retrieval system would return chunks instead of fully-formed answers.

The Knowledge Engine, Explained

The results enterprises in Early Access are seeing aren’t a product of better prompting or a smarter model. They come from a different approach to how knowledge is organized before any query arrives. (See our previous blog, Nexus in the Wild: Real Results from Our Early Access Customers)

Connectors handle ingestion: Local file upload, Box, and Microsoft OneLake are live today, with Google Drive, Slack, GitHub, Notion, Confluence, and S3 close behind.

A Workspace is the top-level container: the boundary around a team or business unit. Connectors and other shared resources live at the Workspace level, so the natural mental model is one Workspace per team that owns its own data sources and access controls: a support org, a legal team, a data science group.

Inside a Workspace, your data is organized into Contexts: one per dataset or knowledge domain. Sources flow through Nexus's curation layer, guided by a Manifest that turns raw documents into structured knowledge artifacts tuned to the domain. The Manifest is the blueprint for how the corpus should be understood.

Tasks run the actual work inside isolated Sandboxes: import to ingest and clean sources, curate to build artifacts per the Manifest, and search to query via KnowQL. Each workflow can employ an ensemble of models, with the right model picked for each step. Everything surfaces through a single interface: KnowQL, the Query Interface into Nexus. Agents, chatbots, AI search applications, recommendation systems all tap into the same knowledge layer through one consistent surface.

SMEs in the loop

The people who know what questions matter, and what knowledge structure would answer them, usually aren't the engineers building the pipeline.They're the patent attorney who knows how patent standards are organized. The M&A analyst who knows which document categories need to be cross-referenced for a clean diligence answer. The revenue leader who knows which signals in a Gong transcript actually predict churn.

The Manifest is how we bring that person into the loop. A subject matter expert can design a blueprint defining the artifact types and relationships that encode their domain knowledge into the curation layer before any query runs. The agent isn't left to figure out the structure of the corpus at query time. It inherits the SME's understanding of it.

This is a different model than prompt engineering. The model isn't being coached at query time, it's being handed a knowledge layer that was designed by someone who actually knows the domain. The difference is between an agent that retrieves the most relevant chunk and one that reasons over a corpus already structured by someone who understood it. The answer comes out precise and fast, with the reasoning pointed in the right direction from the start.

Knowledge doesn't stay static. Regulations change, products evolve, and a corpus that was accurate six months ago develops what we call knowledge drift. Nexus lets SMEs re-curate: update the Manifest to reflect new requirements, rebuild the knowledge layer, ship. The agent stays current because the person who understands the domain stays in control of the knowledge layer.

More Benchmarks

Since opening Early Access, we've kept benchmarking. Different industries, different corpus shapes, same question: does the Manifest-driven curation model hold up when the knowledge problem gets harder or stranger? Three of those benchmarks are below.

Q2: Support Knowledge Base for Financial Services

Domain: Digital Banking / Financial Technology

Q2 builds digital infrastructure for financial institutions. Their support team works through thousands of technical knowledge base articles as part of standard triage, searching them every time a client calls in with an issue.

The articles themselves are easy to find. Most real support questions, though, have answers that live across several of them, and a wrong answer to a financial institution carries real downside, so accuracy ends up being the deciding criterion.

Q2 ran this benchmark themselves. They got early access to the preview environment, ingested their sources, designed a Manifest from a pre-built template, curated the artifacts, and ran the evaluation without Pinecone team in the loop.

Corpus: A sample of Q2's internal technical support knowledge base, covering the breadth of questions their support team handles daily.

Eval set: 20 questions across 6 categories: single-article lookups, two-article reasoning, multi-article synthesis, persona-based support scenarios, and customer cases. Designed to mirror the real question types Q2's support teams face daily.

Results:

F1 Score: 95%
Avg Recall (1–5): 4.70
Avg Precision (1–5): 4.70

For Q2, accuracy was everything, and 95% on their hardest questions was the number that made the case. Jesse Barbour, Chief Data Scientist at Q2, put it best:

"We can easily stand up a vector database and run RAG (and agentic search) over our documentation corpus. The hard part is getting an agent to reliably and efficiently assemble the right knowledge for genuinely difficult questions. In our own evaluations, Pinecone Nexus answered a set of complex support and compliance questions with 95% accuracy. And the fact that it has the ability to do it while keeping token costs down, not driving them up, makes it even more compelling." — Jesse Barbour, Chief Data Scientist, Q2

A Legal Research AI Company: Coverage and Reliability Over EU Case Law

Domain: Legal Research / LegalTech

This benchmark, run with a company building AI tools for legal research, tested Nexus on the task at the center of their product: answering substantive legal questions over EU case law and legislation. Nexus ran against an agentic-RAG baseline and a coding agent, with the same model composing every answer. Only the retrieval architecture changed, so any difference in the results is attributable to it.

The questions span the shapes a real legal researcher asks: looking up what a specific provision requires, tracing how a doctrine has been applied across cases, assembling every relevant precedent on a topic, and reasoning across multiple regimes at once. These are hard for standard retrieval for the same reason municipal records and support tickets are: the answer is rarely sitting in one document.

Corpus: 30,000 documents (~1.1 GB) of CJEU and General Court case law plus EU legislation, spanning 2021–2026.

Eval set: 35 legal research questions across 8 categories, including provision lookups, doctrine synthesis, cross-case and cross-regime reasoning, coverage and enumeration questions, precedent chains, and out-of-corpus negative controls.

Results:

Metric | Nexus | Agentic RAG | Coding Agent
Completion rate | 100% | 66% | 6%
Accuracy | 87% | 45% | 4%
Avg Tokens per query | 9k | 80k (9x) | 135k (15x)

The completion gap tells most of the story. The coding agent completed just 2 of 35 questions, browsing 30,000 documents by listing and reading files doesn't scale to a corpus this size. The RAG baseline did better but fell apart on doctrine synthesis, cross-case reasoning, and coverage questions, the shapes that require many sources assembled into one answer. On 12 of those, it never made it to composing a response at all. Nexus completed every question in the set, and even on the ones both systems answered, it was more accurate.

On a control question about U.S. securities law, asked of a corpus that contains only EU law, Nexus recognized the question was out of scope and said so. The other two systems fabricated answers.

A Leading Data Protection and Security Vendor: Cross-Document Reasoning Over Municipal Records

Domain: Enterprise Data Management

This benchmark, run with a data protection and security vendor, tested Nexus on a corpus where the documents themselves aren't technically complex, but they're structured so that almost no question can be answered from a single one of them.The corpus is 598 documents of municipal meeting minutes from a major city, spanning 2022–2025 across 13 governing bodies. Almost no question in the eval set can be answered from a single document. Counting a council member's attendance requires reasoning across roughly 40 documents. Resolving a project location requires joining an agenda item to its parcel number, applicant, and owner. Reading a motion's full vote requires extracting a structured roster from a narrative paragraph.

These are exactly the queries that expose the problem with standard retrieval. Chunk the corpus, embed it, and there's no way to answer "How many times did Mayor Smith preside over a city council meeting between 2022 and 2025?" without the agent looping back dozens of times to reassemble partial answers.

Corpus: 598 documents, one per meeting. 13 governing bodies. 4 years of data. Multi-session meetings with repeated structures.

Eval set: 100 questions across 13 categories including attendance counts, motion votes, officer history, project locations, deadlines. All cross-document by design.

The Manifest: 12 artifact types, including dedicated SQLite-backed tables for Meeting Attendance, Motion Log, Deadline Log, and Project Location.

Results:

Accuracy: 90% vs (RAG Baseline: 65%)
Curation cost (one-time, 598 documents): $0.0038 per doc
Query cost: $0.0069 per question

Curating 598 documents into 12 structured artifact types cost $2.31 and took 34 minutes. Every subsequent query runs against that curated index at a low average cost, with no per-query retrieval loop accumulating tokens. The knowledge gets compiled once.

A leading data protection and security vendor, a digital banking infrastructure provider, and a legal research AI company don't have much in common. One use case is reasoning across years of government meeting minutes, another is answering technical support questions for banks, and the third is legal research across tens of thousands of case law documents. But all three hit the same wall with standard retrieval, and all three saw the same thing when they switched to a knowledge layer built for their corpus: accuracy went up, costs came down, completion rates climbed, and questions that used to require multiple retrieval loops just got answered.

The shift is to compile knowledge upfront instead of reassembling it on the fly. When the knowledge layer is structured before a query arrives, the agent reads from a layer that already knows the shape of the corpus, rather than rebuilding that understanding from raw retrieval every time it gets asked something.

Start Building

If your agent setup has hit its ceiling on your corpus, has accuracy that won't improve, token costs that won't close a business case, latency that doesn't fit a live workflow… the issue is almost always in the knowledge layer, not the model.

Pinecone Nexus solves those problems. And when you're ready to go to production, BYOC deployment means your data never leaves your infrastructure. No shared environment, no data residency concerns, no compromises on security. Your cluster, your VPC, is fully isolated.

Get started with the Nexus Public Preview
Make your agents more accurate, faster, and cheaper
Request Access
Talk to Sales

Original source