Pinecone 2.0 — Edo Liberty, Pinecone

People asked Yahoo Answers whether they were fat. The forum had no personal information with which to answer, but the question still arrived. Edo Liberty, who worked at Yahoo roughly fifteen or sixteen years before this talk, uses that example to introduce theory of mind: our ability to model what someone else knows, believes, and might do. A user also needs a working model of what a product knows. Liberty argues that enterprise agents invite a subtler version of the same mistake: their fluency and general competence make it easy to assume they understand the company around them.

Three kinds of knowledge

Liberty offers a broad taxonomy, rather than an exhaustive account of knowledge:

• General knowledge: Public information absorbed during model training. His examples include improving Rust code, explaining legal terminology, and exploring product use cases. These are capabilities an agent can bring to a task before learning anything about its employer.
• Specific knowledge: Private facts such as what the company’s codebase implements or what a particular customer’s contract contains. Retrieval-augmented generation (RAG), search, and vector databases give agents access to this material. Liberty treats these as established approaches while acknowledging that there is still work to do.
• Tribal knowledge: The understanding a seasoned employee has about processes, ownership, guiding principles, and how work gets done. It belongs to the company, but a search result from one document may not capture it.

The third category creates the gap Liberty wants to address. Finding a culture document does not necessarily teach an agent how the organization operates. That understanding comes from many pieces of information considered together. An agent may retrieve relevant passages and still lack the accumulated sense of which goals, priorities, and processes should govern its work.

His model for the enterprise agent is a brilliant new hire: capable, equipped with tools, and facing high expectations, but unfamiliar with the company. It must read documents to orient itself. When most sessions begin from scratch, the agent repeatedly returns to its first day on the job. The missing capability is the ability to carry company understanding forward into the next task.

Liberty proposes a shared knowledge layer with three requirements:

• Persistence: Building company understanding takes substantial effort. The accumulated work should remain available to all the company’s agents, rather than be reconstructed for every session.
• Specialization: HR practices, kernel optimization, and customer support require different information. Liberty recommends that domain experts own the relevant knowledge and interact with it to keep it aligned with company goals.
• Freshness: Companies change. The layer must keep current information useful and deprecate information that no longer applies.

The CEO example: new facts must outweigh old references

Freshness is the hardest requirement. Suppose a company replaces its CEO. By the next day, employees know who leads the company, even if nine thousand documents spanning the preceding ten years still name the former CEO. The new fact overrides those historical references. An agent that simply retrieves old documents can confidently arrive at the wrong present-day answer.

This makes freshness a problem of changing the stored understanding, as well as bringing in new material. Adding another document does not by itself establish which fact now applies. Liberty’s requirement is that a knowledge layer recognize the change and stop treating obsolete information as current.

The layer sits alongside the agent’s existing capabilities. LLMs, tools, local files, RAG, vector search, and text search remain useful. Liberty wants a separate entity that many agents can consult for company understanding while continuing to use their own tools. Shared knowledge can persist even as individual task sessions begin and end.

Nexus is Pinecone’s implementation of the knowledge layer. Liberty introduces four parts: connectors, context, tasks, and queries. Connectors bring data into the platform while respecting access rights and controls. He moves through them quickly, but stresses that enterprise ingestion and permissions are painstaking to get right. They determine which information enters the system and under what access restrictions.

A context is the collection of assets Nexus maintains for a topic such as HR, operations, or engineering. It includes source connections and a manifest. The manifest specifies the tasks to support, the entities to track, and the information worth remembering. Liberty contrasts this with manually writing and maintaining skills, plugins, commands, and Markdown context files. The owner describes what matters; Nexus organizes and maintains the resulting knowledge.

Five representations with different jobs

The manifest describes the interests of the context. The knowledge assets hold and organize what the system has learned:

• Semantic map: A catalog of where information lives, including key schemas and glossaries. It gives the system a way to navigate the context.
• Markdown files: Unstructured information, decisions, memories, and notes. Liberty compares this to LLM Wiki, an idea he attributes to Andrej Karpathy in which agents manage Markdown files to keep their own notes.
• SQL tables: Tabular facts and data that support aggregation.
• Vector database: Information available through semantic search, text search, and filtering.
• Graph entities and indexes: Entities, relationships, and causal chains.

These representations let the context retain more than prose notes. Tables can support calculations over facts; search can locate relevant material; graphs can retain relationships. The semantic map describes how to find and use the assets. Liberty says Nexus creates and manages them through the manifest, so users do not need to build each table, index, or graph themselves. The manifest becomes the main way to direct what this managed system should keep.

Having described the stored objects, Liberty turns to the actions that change them. Import brings in new files, events, and concepts. Curation incorporates their information into the context’s existing understanding. His examples are a new PDF, meeting transcript, or board presentation. The important step happens after the material arrives: the system must work out what this context should remember and what needs to change.

The curator takes three inputs with different roles. The new material supplies information. The manifest identifies the concepts and entities that matter. The semantic map tells the curator where the relevant knowledge is stored. Together, they guide updates to tables, graph relationships, text indexes, and other assets. When curation finishes, the assimilated information persists in the context.

This is where the earlier CEO example belongs in the architecture. A new announcement can lead to changes in maintained knowledge, rather than merely become one more searchable document. However, Liberty does not specify how the curator decides that one source supersedes another or how it handles contradictory claims. The update path is explained; the reliability of those judgments remains open.

Search then exposes simple internal functions for accessing the context. The answering agent does not have to learn the access details of every table, graph, or index. This keeps the two jobs separate: curation maintains several knowledge representations, and a compact set of functions makes their information available to the querying engine.

NoQL specifies how an agent wants information out of a context. Liberty argues that a question alone does not communicate enough. The calling agent should also describe the resources the answer deserves: a budget in tokens or dollars, and how much time to invest. A quick answer and a thorough investigation can begin with the same question while requiring very different amounts of work.

The caller chooses between immediacy and a more extensive search in pursuit of accuracy. Nexus returns grounded text structured for another agent to use. This makes NoQL an interface between agentic systems, with effort and output requirements that go beyond conversational wording. Liberty does not provide a request schema or explain how budgets are enforced; additional effort is an intended control, not a demonstrated guarantee of correctness.

Liberty next opens up the answering engine. He describes a Nexus interface with a question at the top, steps on the left, and generated code at the bottom right. The code illustrates what he calls a runtime coding agent. In the conventional coding-assistant workflow he contrasts it with, the model edits software that is later deployed; the deployed artifact can run without the model. In Nexus, the model participates while the question is being answered.

Write, execute, inspect, revise

The engine works like a Jupyter Notebook or Python REPL. It writes code and executes it, then uses the result to decide what to do next. If the result differs from what it expected, it rewrites that piece of code and runs again. The answer emerges from an executable procedure developed during the request. The system can use code to obtain the information needed for the task, rather than express the entire task as one database query.

The resulting code can be saved and rerun. That gives a completed request a reusable artifact as well as an answer. The flexibility comes from combining executable logic with access to the context’s stored representations through its internal functions. The loop can adapt to unexpected results, but Liberty does not explain how the agent establishes that its answer is correct or how it chooses a stopping point.

A smaller description of the available interfaces

Liberty reports a reduction from roughly 150,000 tokens of tooling instructions to fewer than 1,000 tokens describing the interfaces needed to get information out of Nexus. This quantity concerns the prompt used to describe access to the tooling. It is not the total token cost of answering a question: the runtime agent still generates code and may iterate. The smaller interface lets agents reach managed knowledge without carrying the same large inventory of tool descriptions.

The closing comparison gives the same task to Nexus through NoQL and to an agent with the tools to complete it independently. Liberty returns to the new-hire analogy: the independent agent must read documents, find the data, understand the task, and write code. He reports that this route is slower, uses more tokens, and is less accurate because it lacks the maintained company context and objectives.

The comparison combines persistent preparation with the answering engine. Both routes can involve writing code, but one begins with accumulated company knowledge and an interface for using it. It therefore does not isolate runtime code generation as the sole cause of the improvement. It illustrates the work an agent can avoid repeating when the organization has already been interpreted and organized for it.

Reported early-access outcomes

Liberty describes gains across early-access customers, domains, and tasks:

• Token consumption: He cites reductions of 77% and 90% as common examples.
• Speed: He describes systems becoming 20% or 30% faster, and sometimes 77% faster.
• Accuracy: He claims that answers also become more accurate, treating this as the most important gain, but supplies no numerical accuracy measure in his explanation.

These are reported customer outcomes with limited detail about their measurement. Liberty does not give task definitions, sample sizes, or accuracy criteria. He does not explain whether the reported figures include the cost of constructing and maintaining the contexts. That matters because he has already described assembling company understanding as a substantial effort. The results suggest savings from avoiding repeated orientation, while leaving total economics and reliability across workloads unresolved.

Liberty ends by announcing that Nexus will move from early access into public preview the following day. The proposal’s hardest test remains his CEO example: can a maintained context reliably replace obsolete understanding when new information arrives? Curation provides a place to make that change, and persistent access lets many agents benefit from it.