Sarvam Knowledge Fabric: Enterprise Agent Retrieval Explained

Sarvam published its Knowledge Fabric research on October 21, 2026, describing how it organizes information for enterprise agents. The useful question for teams building retrieval-augmented generation, or RAG, is how an agent finds enough context to complete a task, rather than simply returning a relevant passage.

What the knowledge layer changes

The knowledge tree lets agents navigate document indexes and page ranges through MCP tools. A domain ontology represents entities and relationships, enabling database-style filtering and joins. The goal is to prepare reusable structure before a question arrives.

Consider a hypothetical procurement assistant checking whether a supplier meets an internal policy. Finding the supplier’s name is an easy search test. A more useful test asks it to connect the relevant contract, an exception approval and the current policy, then explain which evidence supports its recommendation.

That example also exposes a design choice. A system can find the right document while still missing the section that changes the answer. Evaluation should separate finding the source, interpreting it and using it correctly. Otherwise, an improvement in search quality can look like an improvement in the whole workflow even when the final decision remains wrong.

Read the Harvey LAB numbers separately

On LAB’s firm-knowledge tasks, Sarvam reports 84.2% of rubric criteria met and 109 of 250 tasks fully solved, versus 55.1% and 72 tasks for agentic RAG. Both used GLM 5.3. The 109 completed tasks represent 43.6%, not 84.2%, task success. These are vendor-reported runs.

The same comparison reports $0.28 per task for the ontology setup, against $0.64 for agentic RAG and $1.18 for tree navigation alone. The tree improved retrieval but required more exploration; the ontology moved filtering into the database. These task costs do not establish the total cost of building and maintaining the knowledge layer.

Harvey’s Law Firm Knowledge benchmark uses a synthetic firm containing 9,288 files across 266 matters. Its tasks require finding and reasoning across that shared corpus.

The evaluation methodology explains the scoring distinction. Individual criteria receive pass or fail judgments. A task passes only when every required criterion passes. Criterion-level results help diagnose what went wrong, while the all-pass measure asks whether the complete deliverable met its requirements.

A hypothetical report can correctly identify several contract provisions and still omit a required conclusion. Counting the successful pieces gives useful information to the engineer improving the agent. Counting the finished task answers a different question for the person reviewing its work. Neither number should be relabeled as the other.

Sierra’s tau-knowledge benchmark tests another part of this problem. Its banking environment combines a knowledge base of 698 documents with conversations and tool actions. Tasks require agents to find information, reason across it and perform the appropriate operations. This makes retrieval part of task execution, rather than an isolated question-answering exercise.

Results from these two benchmarks should not be combined into a single reliability claim. They test different work and score different outcomes.

What is available in Cowork

Sarvam says the tree is already in production in Cowork, while enterprise ontologies are built with clients. Shared persistent memory remains planned.

The current Cowork Knowledge Bases documentation describes adding reference files and connecting them to agents, which can search and cite that material. That documents an available workflow, without establishing that every research component is a generally available feature.

A practical way to evaluate the approach

Start with a small set of representative tasks and keep the model, documents and scoring rules fixed while changing the retrieval approach. Record the benchmark revision and judge configuration so later comparisons use the same test. Include cases where two sources disagree, an exception changes the answer, or a policy has been replaced.

Inspect the retrieved evidence alongside the final output. Measure how often the complete task succeeds and what each successful run costs. A more elaborate knowledge layer has to earn its indexing and maintenance work through better outcomes on the tasks the team actually needs to delegate.

I’m Paras. I work at the intersection of AI, engineering and distribution.

If you’re building an enterprise AI product and want help explaining its retrieval architecture and evaluation results clearly to developers and buyers, I’d be happy to help.

Book a 30-minute call.