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

(Cohere Rerank 4.0 Fast)

(Cohere Rerank 4.0 Fast) is now generally available as a reranking model on Pinecone. It succeeds cohere-rerank-3.5, improves relevance quality, and supports multiple rerank fields. Cohere Rerank 4.0 is hosted on Azure AI under the Global Standard deployment type, and requests may be processed in regions outside the United States. With this release, cohere-rerank-3.5 is deprecated:

• Through July 31, 2026: cohere-rerank-3.5 continues to serve requests as before.
• August 1, 2026: requests to cohere-rerank-3.5 are automatically served by cohere-rerank-4-fast.

No code change is required for the transition, but note two differences before you migrate:

• Relevance scores differ. cohere-rerank-4-fast returns different scores than cohere-rerank-3.5. If your application relies on hard-coded score thresholds, re-tune them against cohere-rerank-4-fast before August 1.
• Billing counts units differently. The per-unit rate is unchanged at $2.00 per 1,000 rerank units. One rerank unit covers a query plus up to 100 documents, with documents longer than ~500 tokens auto-chunked into ~500-token chunks that each count toward that 100. As a result, cohere-rerank-4-fast can bill multiple units for a large request, whereas cohere-rerank-3.5 billed one unit per request.

To control the transition yourself, migrate your rerank requests to cohere-rerank-4-fast before August 1. For model details and parameters, see Reranking models.

Original source

After working with enough production deployments, a pattern becomes clear: a stale, undersized, or under-resourced index doesn't go down. It returns the wrong results. The problem is that without continuous visibility into index health — record counts, upsert rates, storage utilization, latency trends — there's no signal that anything is wrong until the AI application has already been serving degraded results.

This post introduces pinecone-field/pinecone-monitoring: an open-source stack with pre-built Grafana dashboards, Prometheus metric collection, and support for both Pinecone SaaS (Serverless) and Bring Your Own Cloud (BYOC) deployments.

What's in the Stack

The monitoring solution is built on two industry-standard open-source tools:

Prometheus handles metric collection and time-series storage. It scrapes the Pinecone Metrics API at regular intervals, capturing operational data across all your indexes. For BYOC deployments, it also collects Kubernetes infrastructure metrics via Node Exporter.

Grafana provides the visualization layer — pre-configured dashboards that surface the right data, with built-in alerting capabilities so your team can respond to signals before they become incidents.

The repo supports three deployment configurations:

• SaaS Only: Docker Compose-based setup for teams using Pinecone Serverless. Operational in minutes.
• BYOC Only: Kubernetes-native deployment using Helm charts, with pod-level and node-level infrastructure visibility.
• BYOC + SaaS: A unified monitoring instance that covers both index types simultaneously, ideal for teams running mixed environments.

Why Monitoring a Vector Database Is Different

Monitoring a vector database isn't the same as monitoring a relational database or a REST API. Availability and latency are table stakes; what matters here is the health of high-dimensional index structures, the performance of approximate nearest-neighbor operations, and in BYOC deployments, the Kubernetes layer underneath.

Record counts, upsert rates, and storage utilization tell a different story than uptime alone. A gradual p99 increase over several days might indicate an index approaching a resource ceiling, a shift in query patterns, or a regression from a recent deploy. That signal doesn't exist without time-series data. And unlike databases where a DBA team controls load, Pinecone workloads are shaped by application code, users, and ML pipelines — which makes unexpected changes in operation rates often the first sign something has gone wrong.

What it enables

Proactive operations. Continuous metric collection with Grafana alerting lets teams set thresholds on latency baselines, pod CPU and memory utilization, operation rate deviations, and index storage growth. Issues caught at the signal stage get resolved in minutes; issues caught after users notice get resolved in hours, if not longer.

Root cause analysis. When incidents happen, the dashboards provide a complete operational timeline across every Pinecone operation type — queries, upserts, fetches, updates, deletes — with latency at p50 and p99. BYOC deployments add per-pod CPU, memory, and storage alongside Kubernetes node health. Post-incident reviews have data; recurring issues get traced rather than treated.

Workload change detection. AI applications change fast. New model versions, feature launches, and pipeline modifications all shift how Pinecone gets used — sometimes intentionally, sometimes not. A 5x query spike after a feature launch is expected but worth confirming. A background process looping through redundant upserts is invisible without operation rate tracking. A drop in query traffic signaling a broken integration gets caught before users do.

Cost visibility. Pinecone costs are tied to usage. Without visibility into operation rates and storage growth, cost surprises are common. With it, teams can correlate application behavior with usage spikes, identify inefficient patterns, validate that optimizations are actually reducing load, and set alerts before usage hits unexpected thresholds.

Capacity planning. The stack supports infrastructure decisions grounded in trend data rather than incident response. Months of index growth, query volume, and utilization history make it possible to project when a BYOC cluster needs additional nodes, how latency has responded to index growth, and what headroom looks like across pod memory.

Multi-project visibility. The stack supports multiple Pinecone projects in a single deployment. For platform teams managing staging, production, and customer-specific environments, unified visibility makes it straightforward to validate that a deployment change didn't introduce a regression, or that a new environment is performing consistently with an established one.

BYOC infrastructure health. For organizations running BYOC for data residency, compliance, or performance reasons, the stack brings Kubernetes-level observability to Pinecone infrastructure that previously required custom solutions. Pod CPU and memory, node health, filesystem utilization, and storage metrics are all captured and visualized — consistent with the tooling, alerting, and runbooks applied to the rest of the Kubernetes estate.

SLA documentation. Uptime and latency data matter beyond operations. Ninety days of Grafana data supports reliability conversations with business stakeholders, informs SLA commitments, and provides documentation for compliance or audit purposes.

Getting started

For SaaS monitoring, Docker Compose brings up Prometheus and Grafana with pre-configured dashboards in a few minutes. The only prerequisites are a Pinecone API key and project details.

For BYOC, Helm charts deploy the stack into the cluster. Node Exporter is included for infrastructure-level metrics, with deploy and uninstall scripts for lifecycle management.

All dashboards are pre-built and provisioned automatically.

View the repository on GitHub

Original source

We gave three enterprises a knowledge engine. Here's what happened to accuracy, latency, and costs.

For the past year, most enterprise AI discussions were about capability. The question that replaced it is about cost and reliability. AI is expensive to run at scale, and accuracy and latency still break down on the hardest corpora. When teams look at where their inference spend is actually going, most of it isn't on reasoning. It's on retrieval loops that run before the model can say anything.

Pinecone Nexus addresses this at the infrastructure layer. Rather than assembling knowledge at query time, it compiles structured artifacts from a corpus before any query arrives, tuning the retrieval pipeline to the specific shape of the data. We launched four weeks ago and have been engaged with early access users with real enterprise datasets. Our early enterprise partners are seeing real results. Here's what happened to their accuracy, latency, and costs after Nexus.

The Benchmark

For each customer, we ran Nexus against the most common pattern in enterprise agent deployments today: chunk the corpus, embed the chunks, use hybrid retrieval. The agent loops (run the query, rerank, read the top chunks, retrieve again) until it has enough context to answer.

That approach can produce correct answers. The question is at what cost in tokens, time, and consistency, and whether that cost holds at enterprise scale.

Three KPIs:

• Token cost. How many tokens does a single query consume? At enterprise volume, this determines whether the economics of an agentic deployment hold.
• Accuracy. Does the agent return the correct answer, repeatable across runs? Each eval set in our benchmark was built from human-labeled questions with expected answers drawn from the actual corpus. Answers were graded by an LLM judge (claude-sonnet-4-6) on a 0–1 scale against the expected output.
• Latency. How long does a query take, end to end? For agents embedded in live workflows, user-facing products, automated pipelines, or deal support, time to answer matters.

All three trace back to the same dynamic. Agentic RAG assembles knowledge at query time: retrieve chunks, rerank, read, decide what's missing, loop again. The loop runs on a generic index built once from the raw source, with no knowledge of the domain, the query types, or the reasoning the task requires. Each iteration is the agent compensating for what the index doesn't know and working around an absence, not a foundation.

Nexus works differently. Before any query arrives, it derives structured artifacts from the corpus shaped to the subject matter, the query types, and the reasoning the agent will need to do. The agent retrieves precisely and reasons immediately.

Melange: Standard Essential Patent Search

Domain: Intellectual Property / Patent Litigation

Melange Technologies runs an autonomous, large-scale prior art search engine used by law firms in patent invalidation and litigation. Their core product is an agentic search system which filters the total corpus of around 140 million patent documents down to the most relevant dozen and provides litigators with a first draft of the legal analysis necessary to prosecute their case. The work is nearly fully autonomous with human verification only at the final stage before delivery.

Melange’s next plan of expansion involves Standard Essential Patents, or SEPs. An SEP is a patent that claims technology required to comply with an industry standard. For example, any company building a phone with 5G capability must implement portions of the 5G technical standard. If a patent covers one of those mandatory portions, then practicing the standard may necessarily practice the patent. Patent licensing has become a multi-billion dollar industry, with SEPs at the center of the most valuable and contested disputes.

This has two important implications for the industry. First, it is critical to determine whether a patent is actually essential to the standard. That analysis can be expensive and time-consuming, often requiring human domain experts to compare patent claims against long, technical standards documents line by line. Second, standards documents themselves can serve as prior art, potentially invalidating patents that claim technology already disclosed during the standards-development process.

In just release 1 of the 3GPP technical standard, there are roughly 1,800 documents including 2.3 GB of relevant documents. The pilot evaluated a focused 29-spec slice of the 5G NR standards (~31 MB, converted to markdown). These specifications originate as .docx/.doc files dense with embedded tables and normative requirement language.

Corpus: 3GPP Release 18, 1,800 .docx/.doc files, ~2.3 GB, covering 5G NR specifications, protocol standards, interface definitions, and normative requirements. Pilot evaluated on a 29-spec NR slice (31 MB, converted to markdown).

Eval set: 30 SEP-candidacy questions, each a patent-style claim evaluated against the standards corpus for whether a finalized, mandatory 3GPP requirement necessarily practices it. Every answer is one of five verdicts (mandatory, conditionally mandatory, optional, forbidden, or absent) with the exact spec, clause, and information element cited.

Agentic RAG averaged ~20 retrieval steps per question on this corpus. The loop does not converge on dense, clause-referenced technical standards because the index carries no knowledge of how the standards are structured or what the query requires. Nexus organized the standards into addressable requirement artifacts before any query ran. The correct clause was retrieved directly, at 5.9K tokens versus 201K tokens.

Business impact: At 97% lower token cost, a previously cost-prohibitive autonomous patent search product becomes economically viable at scale. Latency under one minute per query means the workflow fits live litigation timelines. The accuracy improvement directly reduces attorney review time.

"These early results are genuinely exciting: a 34x reduction in token cost and queries resolving in under a minute on one of the hardest problems in our space tells us we're pointing in the right direction. Adding a purpose-built knowledge engine to Pinecone’s AI infrastructure is already showing signs of real business impact, and we're looking forward to evolving this together as Nexus matures to fully fit the demands of patent search at scale." — Joshua Beck, CEO, Melange

M&A Due Diligence

Domain: Financial Technology / Investment Management

The customer is a large financial technology company serving asset managers, hedge funds, and private equity firms. Their clients operate in document-heavy environments where extracting precise answers from large document sets directly affects deal outcomes and regulatory risk.

The use case evaluated here is M&A due diligence, which is a representative scenario for this customer's client base, where a deal dataroom for even a mid-market acquisition spans hundreds of documents across 10+ categories: audited financials, capitalization tables, customer contracts, IP filings, HR records, real estate leases, tax schedules, legal governance docs. Questions aren't contained within a single document. They require reasoning across all of it simultaneously.

The dataset is a full synthetic M&A dataroom for a $42M ARR enterprise SaaS company, structured across 10 category folders with files spanning PDFs, Excel workbooks, and markdown, covering the full complexity of a live deal room in a controlled, evaluable form.

The questions that matter here are inherently multi-hop. "What capital-structure feature in Vantage's preferred stock affects the equity-value waterfall to common shareholders?" requires reasoning across the cap table, preferred stock terms, and liquidation preference documents simultaneously. "What contingent legal liability could impair Vantage's projected cash flows or warrant a DCF risk discount?" requires connecting IP filings, litigation records, and financial projections across three separate folder categories. No single document holds the answer. The question only resolves when the full dataroom is treated as a unified knowledge surface.

Corpus: 90 documents across 10 category folders (PDFs, XLSX, and markdown) covering company overview, audited financials, ARR schedules, cap tables, customer contracts, IP filings, HR records, tax documents, real estate leases, and process documents.

Eval set: 30 multi-hop M&A diligence queries requiring cross-document reasoning.

Nexus resolved each question in a single retrieval step against RAG's approximately 10 iterative steps. The accuracy improvement holds on the hardest multi-hop queries, where agentic RAG's loop repeatedly retrieves incomplete context across documents and cannot close the reasoning gap without re-querying. Nexus derived artifacts from the dataroom that mapped the cross-document relationships before any query arrived.

Business impact: Due diligence workflows that required analyst hours to synthesize across folders now complete in seconds. At 92% lower token cost and 48% lower latency, the economics of deploying AI across deal pipelines are fundamentally different. Higher accuracy on multi-hop questions reduces the risk of missed liabilities or misread financial structures.

Revenue Intelligence from Gong Transcripts

Domain: SMS Marketing / E-commerce SaaS

The sales and CS teams for a leading SMS marketing and sales platform for e-commerce brands run a high volume of customer-facing calls every week, pricing conversations, onboarding calls, renewal discussions, competitive deal cycles, all captured in Gong.

The challenge is that insights locked in those transcripts are largely inaccessible at scale. Questions like "Which competitor is mentioned far more than any other across these calls?" or "Name several accounts where RCS is a major topic of discussion" require synthesizing patterns across dozens of calls simultaneously. Searching one transcript at a time, which is what an agentic loop does, is too slow and too expensive for a live revenue workflow. The signal is in the aggregate.

The dataset is one week of real Gong call exports: structured JSON transcripts covering sales, CS, and pricing conversations, with company-specific tracker data (message rate, list growth, churn indicators, competitor mentions, expansion signals) embedded throughout.

Corpus: 217 Gong call transcripts, ~45 MB of structured JSON call data spanning sales, pricing, and customer success conversations with full tracker and topic metadata.

Eval set: 40 revenue intelligence queries requiring cross-call synthesis, trend identification, and pattern recognition.

The accuracy improvement here is the largest of the three cases and reflects the fundamental mismatch between agentic RAG and aggregate synthesis workloads. An agentic loop over 217 transcripts is iterating through documents one at a time, searching for partial answers, and reassembling them into a response. It cannot see across the full corpus simultaneously. Nexus derived structured representations of the call data that made cross-call patterns directly addressable. The nearly 2x accuracy gain is what corpus-level compilation looks like in practice.

Business impact: Revenue intelligence queries that required manual analyst review become automatable. Competitive signals, churn indicators, expansion patterns, and pricing sensitivities become queryable in real time across the full call corpus. At 85% lower token cost, running these queries continuously as new calls come in becomes economically viable.

Results Across Three Customers

Three customers, three industries (financial services, intellectual property, revenue operations), three knowledge problems. Nexus outperformed agentic RAG on accuracy, latency, and token cost across all three.

The pattern held regardless of corpus shape, query type, or domain. In every deployment, agentic RAG started from the same place: a generic vector index built from the raw source, with no knowledge of the domain, the query types, or the reasoning the task requires. The retrieval loop that follows isn't incidental to that design. It's what happens when the index carries no knowledge of the domain, query types, or task structure.

Nexus gets to the root cause. The artifacts it derives from an M&A dataroom are structurally different from the ones it derives from a patent standards corpus or a Gong transcript database, because the subject matter, query types, and reasoning requirements are different. By the time a query arrives, the knowledge layer has already been shaped to the problem. The agent retrieves precisely and reasons immediately rather than sifting through generic chunks hoping to assemble enough context to answer.

The practical consequence is direct: projects that couldn't clear the business case now can. At 92–97% fewer tokens, inference costs that were prohibitive at enterprise volume become manageable. At 48–77% lower latency, agents that couldn't fit live workflows now do. At accuracy rates that hold on hard corpora, deployments that required constant human review become autonomous.

Apply for Early Access

Nexus is built for teams building agents over enterprise knowledge: documents, contracts, filings, call transcripts, technical specifications. If agentic RAG has hit its ceiling on a corpus, the issue is almost always in the retrieval loop, not the model.

Enterprises with a hard knowledge problem can apply for Early Access and run a benchmark on their own data before public preview. We'll work with you.

Original source