Beyond embeddings: Give AI context & memory with HydraDB

Introduction

Since the launch of ChatGPT, large language models have become an important part of how people work. They are excellent at solving problems when all the required information fits inside their context window. But, most real-world enterprise tasks are far more complex. An AI agent may need to understand hundreds of documents, analyze an organization’s financial structure, follow decisions across months of Slack conversations, or combine information from emails, GitHub, Notion, and internal systems. Standard LLMs struggle with these tasks because they are trained on historical data, do not continuously learn from new information, and can only reason over a limited amount of context at a time.

Retrieval-Augmented Generation, or RAG, attempts to solve this problem by retrieving relevant text from a vector database. This works well for simple semantic search, but it becomes unreliable when information is fragmented across thousands of messages, documents, emails, and conversations.

Vector similarity may find related text, but it does not reliably understand relationships, changing ownership, dependencies, timelines, or the latest valid state of information. Scaling the model’s context window does not fully solve the problem either; it increases computational cost and can introduce irrelevant information, and hallucinations. The model remains stateless and does not build persistent memory.

HydraDB approaches the problem differently. It treats organizational memory as a data-modeling problem rather than only a context-length problem. HydraDB continuously converts evolving information from Slack, Gmail, Notion, GitHub, documents, and other artifacts into a fast, temporally aware knowledge graph. Using Git-style versioning, it preserves historical changes, tracks the latest state, and gives AI agents the structured context they need to reason reliably over an organization’s continuously changing knowledge.

Why Vector Search Fails

Fragmented context. Chunking splits related facts across different segments. If an entity is introduced in one chunk and updated in another, the system may fail to connect them and miss important information.

Outdated information. A flat vector index does not understand time. An old policy and its latest version can appear equally relevant because similarity search cannot tell which fact is current.

Similarity is not Relevance. Two similar vectors don’t mean they are related to the context. For instance: 24 June log: "Deploy version 2.4 to production on Monday.”, after two days, 26 June log: “Do not deploy version 2.4 on Monday, deploy on Friday”. Querying about “Deployment Status” will retrieve both results because similarity search doesn’t have temporal understanding. Similarity-based vector search can retrieve both because they are similar, but it can’t comprehend the difference. Microsoft Research has shown this baseline "struggles to connect the dots" when answers require traversing disparate information.

Methodology

Our methodology replaces flat chunk retrieval with a context-enriched, temporally versioned knowledge graph designed for enterprise AI agents.

First, each document, conversation, ticket, meeting note, and operational record is processed using a sliding-window context window. For a segment $s_i$, the system uses its neighboring segments $W_i$ to resolve pronouns, implicit references, missing subjects, and local dependencies:

This produces self-contained segments that preserve the original text while adding the context required to interpret each record independently. The system then extracts typed entities and relationships. Mentions referring to the same employee, customer, project, policy, issue, product, or service are resolved to a shared entity identifier. Facts distributed across Slack, email, CRM records, support tickets, and internal documents can therefore be connected into one organizational memory.

Each relationship is stored as a versioned edge:

where $u$ and $v$ are entities, $r$ is the relationship type, $t_{\text{commit}}$ records when the fact entered the system, $t_{\text{valid}}$ records when it became true, and $m$ stores provenance, confidence, ownership, and access-control metadata.

Updates are append-only. A new fact does not destroy the previous state, it creates a new version. The current state is reconstructed by ordering related facts by validity time and selecting the latest valid version.

For retrieval, the system combines semantic, contextual, and lexical signals:

Content embeddings retrieve direct semantic matches. Enriched embeddings retrieve records whose meaning depends on surrounding context. Lexical search captures exact identifiers such as customer IDs, project names, ticket numbers, service names, and error codes. The strongest text matches are mapped to their connected entities. The system then performs bounded graph traversal across permitted relationship types, valid time ranges, and access-control boundaries. This expands retrieval from isolated passages to the wider operational context around them. The system can retrieve the project, traverse to the blocking issue, identify its assignee, inspect the affected service, and recover the latest status update. The agent receives a connected explanation rather than several unrelated chunks containing similar words.

Finally, vector results, lexical matches, and graph-expanded evidence are deduplicated, temporally filtered, reranked, and compressed into the final model context. Every retrieved fact remains linked to its original source, making the answer traceable and auditable.

Why This Matters for Enterprise AI Agents

Enterprise agents do more than answer questions. They monitor operations, coordinate workflows, recommend actions, and make decisions across changing organizational data. To perform reliably, they need memory that is connected, current, permission-aware, and explainable.

This methodology provides that Knowledge Database.

Persistent organizational context. The agent can retain relationships across sessions instead of treating every interaction as isolated. It can remember who owns a project, which issue blocks it, what decision was made, and how that state changed.

Current-state reasoning. Temporal versioning prevents the agent from acting on obsolete policies, ownership records, customer states, or operational instructions.

Cross-system understanding. Entity resolution connects information distributed across communication tools, project trackers, CRMs, documents, and databases into a unified operational model.

Multi-hop reasoning. Graph traversal allows the agent to follow dependencies that cannot be recovered through similarity search alone, such as:

Project → blockedBy → Issue → assignedTo → Engineer

Permission-aware memory. Access metadata can be enforced during retrieval and traversal, preventing the agent from exposing information that the requesting user is not authorized to access.

Auditable responses. Provenance links every fact back to its source, timestamp, and extraction confidence. This makes agent outputs easier to verify, debug, and govern.

Reliable action planning. Because the agent can reconstruct the latest valid organizational state, it can make better recommendations, identify responsible owners, detect unresolved dependencies, and trigger workflows using current evidence.

The result is a structured memory architecture that allows enterprise AI agents to understand how organizational facts are connected, how they change over time, and which information is valid for a specific user and task.

Controlled inference

Context enrichment should clarify ambiguous text, not invent new facts. The model may use nearby messages to resolve references, but every extracted fact must remain linked to its evidence:

This allows low-confidence resolutions to be excluded, reviewed, or stored as uncertain claims rather than accepted facts. The original text must also remain available. Enrichment improves searchability, it does not replace source evidence.

Enterprise communication is highly contextual. Employees frequently use phrases such as:

• “Assign it to Arnav.”
• “The customer approved the second option.”
• “That service is still failing.”
• “Use the previous pricing policy.”
• “She owns the migration now.”

A flat chunk index stores these statements without reliably identifying the referenced project, customer, service, policy, or employee. Sliding-window enrichment converts them into explicit operational records:

1. “The engineering manager assigned the Ontology-Based Migration to Arnav.”
2. “Customer Acme approved Pricing Proposal Version 2.”
3. “The Authentication Service continues to return Error 503.”

This gives enterprise agents memory that remains retrievable across sessions, systems, and changes in vocabulary

Bio-Mimetic Context Consolidation

Persistent memory creates a second problem: GROWTH!

An enterprise agent may ingest millions of messages, tickets, documents, decisions, status updates, and transient events. Keeping every record equally active increases retrieval latency and allows weak or obsolete memories to compete with high-value information. The system therefore needs to decide not only what to store, but also what should remain immediately retrievable.

Retention score

For a memory $m$ at time $t$, we define a retention score:

• $I_{\text{salience}}$ is the memory’s initial importance.
• $\lambda$ controls the rate of temporal decay.
• $\Delta t$ is the time since creation or last consolidation.
• $t_{\text{access}_i}$ is a successful retrieval time.
• $w_i$ measures the usefulness of that retrieval.
• $\sigma$ controls reinforcement strength.
• $\epsilon$ prevents division by zero.

The first term gradually reduces the priority of unused memories. The second term reinforces memories that repeatedly contribute to successful answers or actions. A retrieved record should not be reinforced merely because it appeared in a candidate set. Reinforcement should depend on evidence that it was useful.

Retrieval pipeline

The knowledge graph stores entities and relationships, but retrieval must first find the records and entities to begin from. HydraDB indexes each record three ways, searches them together, then traverses the graph from the best matches.

Three representations

The content vector embeds the original text for meaning, so "Who owns the authentication migration?" matches "Harsh owns the authentication migration." The sparse representation preserves exact terms that dense embeddings miss, such as ticket IDs, error codes and AUTH-503:

The latent-context vector embeds the sliding-window-enriched record, so "Error 503: Service Unavailable" (enriched to "the authentication service is returning HTTP 503") matches an abstract query like "Why is the application not working?":

Hybrid search and ranking

The query is first expanded into parallel paraphrases to widen recall when records use different wording. All three indexes are then searched, and candidates are scored with weights that adapt to the query, exact identifiers favour sparse search, conceptual questions favour dense vectors, and current-state questions favour recency:

Graph traversal and expansion

The strongest matches resolve to graph nodes, and HydraDB follows bounded paths across allowed relationship types:

Because every chunk is linked to its entities at ingest, a strong vector match also expands directly through its pre-linked neighbours: a chunk about AUTH-503 pulls in the project it blocks, the service it affects, and the engineer assigned to it, without repeating entity extraction at query time.

A cross-encoder then scores each candidate path against the query:

Project Migration → blockedBy → AUTH-503 → assignedTo → Alisha

Reranking and fusion

Vector candidates are reranked on semantic and lexical relevance:

and the final context fuses the top vector chunks with their graph neighbourhoods plus the strongest independent graph paths, after temporal, permission, provenance, duplicate and token-budget filters:

In short, query expansion improves recall, hybrid search finds the entry points, graph traversal reconstructs dependencies, and reranking selects the smallest set of evidence needed to answer correctly.

3 · Results across benchmarks

We evaluate HydraDB on eight public benchmarks chosen to cover the places production agents actually retrieve from: company-internal knowledge, dense financial documents, source code, records surrounded by adversarial look-alikes, years of personal memory, and long conversational histories. Each was run on the benchmark's own data with its own scorer. This section is a consolidated view: each benchmark has a dedicated report with the full methodology, linked below and in the table. All results are self-reported.

HydraDB is first on every benchmark with a public comparison except ATM-Bench, where it is second by 0.005 behind a system that re-captioned the media with a stronger model, and first among systems that use the benchmark's own captions. The same pattern holds across domains: the hard cases are the ones where the right record competes with near-identical wrong ones, and that is where a context graph separates from flat similarity.

3.1 · Against vector search

Two of the benchmarks run standalone vector and graph systems on the same corpus with the same scorer, which isolates what the context graph adds.

KyroBench [KyroBench report] surrounds every query with stale, cross-tenant and poisoned look-alikes across 3,634 documents and 864 cases. Run through KyroBench's own open-source controls, a raw Qdrant store reaches 0.717 recall@k and a raw pgvector store 0.649; HydraDB reaches 0.917. The gap widens at the top of the ranking, where the look-alikes are built to win on similarity: 0.776 nDCG@k for HydraDB against 0.366 for Qdrant and 0.316 for pgvector.

ATM-Bench [ATM-Bench report] covers four years of one person's photos, videos and emails, 11,034 items where the right memory looks almost identical to hundreds of others. On the public leaderboard, mem0, a vector-based memory system, reaches 0.619 recall@10 and HippoRAG2, a graph-based RAG system, 0.664. HydraDB reaches 0.918.

A graph on its own is not the fix either. On the neutral GraphRAG-Bench, the best graph method edges the chunk baseline by roughly a point on multi-hop reasoning (45.5 against 44.2) and by about two on answer accuracy (73.6 against 71.7), and several graph methods score below the chunk baseline. A graph only helps once retrieval has found the right node to start from, and that first-stage lookup is the same embedding search a vector store runs. An independent long-term memory study found that at a matched retrieval budget a graph store scores below a flat vector store, token-F1 0.417 against 0.468, while taking longer to query and far longer to build.

HydraDB uses dense, sparse and latent-context vectors to find entry points with high recall, performs bounded, permission- and time-aware graph traversal from those entry points, and reranks the fused evidence. It keeps the vector store's recall and adds the graph's structure, rather than paying one to buy the other.

3.2 · Enterprise knowledge

EnterpriseRAG-Bench [EnterpriseRAG-Bench report] is a synthetic enterprise of 511,958 company-internal documents, Slack threads, tickets, wikis and email, where information is duplicated, outdated and contradictory, with 500 employee-style questions. HydraDB scores 88.7 overall, with 92.0% answer correctness and 96.7% document recall@10, against 80.3 for the highest system on the public leaderboard (as of 28 August 2026). Entity resolution across sources and current-state selection are what separate the right document from its stale copies.

3.3 · Finance

FinanceBench [FinanceBench report] asks questions over real public-company filings. Its authors found that a shared vector store over the filings answered only about 19% of questions correctly with GPT-4-Turbo, against 85% when the correct pages were supplied: retrieval, not the model, is the bottleneck. HydraDB reaches 91.4% recall@10 in thinking mode (89.0% in fast mode), with 50.3% recall@1.

OfficeQA Pro V2 [OfficeQA Pro V2 report] is Databricks' grounded-reasoning benchmark over 1,435 U.S. government financial documents from 1793 to 2024, where the statement for one year looks almost identical to the next. HydraDB returns a cited document in the top ten for 81.1% of questions and as the first result for 67.8%, and holds 72.2% recall@10 when the corpus grows almost six-fold with distractors from every other year.

3.4 · Code

CodeWikiBench [CodeWikiBench report] scores repository-level documentation against rubrics derived from maintainers' own docs, judged by a panel of three LLMs. A documentation agent built on HydraDB, which ingests the repository as a knowledge graph of files, types and calls, scores 90.73 ± 3.29 / 100 on nlohmann/json and covers 47 of 57 criteria, against 66.06 (33/57) for DeepWiki and 61.28 (30/57) for CodeWiki on the same rubric, judges and commit. This is one repository; the full 22-repository run is in progress.

3.5 · Long-term memory

BEAM 1M [BEAM 1M report] tests ten memory abilities at the one-million-token tier. HydraDB scores 82% overall against Hindsight's published 74%, with the largest gains in temporal reasoning (91% against 60%), information extraction (80% against 61%) and multi-session reasoning (60% against 46%).

LongMemEval-s [LongMemEval report] asks 500 questions over conversations averaging more than 115,000 tokens and about 50 sessions, ingested session by session. HydraDB reaches 90.79% overall, 5.0 points above the strongest reported competing system, with 97.43% on knowledge updates and 90.97% on temporal reasoning, and holds 85.80% even with GPT-5 Mini as the answer model.

3.6 · The common thread

The eight benchmarks share one failure mode for flat retrieval. The right record competes with near-identical wrong ones: a stale copy of a policy, another tenant's record, the adjacent year's financial statement, a similar photo from the same life, an earlier version of a fact in a long conversation. Similarity cannot separate them; identity, time, relationships and provenance can. That is why HydraDB's margins are largest on ranking measures (nDCG, recall@1, MRR) and on current-state and temporal questions, and why the advantage holds across domains rather than in one.

The architecture is suited to any agent that works over changing, connected data:

• Enterprise assistants that connect conversations, documents, tickets and organizational entities.
• Financial and research agents that must find the one correct figure among near-identical filings and statements.
• Coding agents that navigate a repository as a graph of files, types and calls rather than a folder.
• Support and sales agents that remember customer history, preferences and unresolved issues.
• Compliance agents that retrieve the currently valid policy with provenance.
• Project and incident agents that reconstruct owners, blockers, dependencies and timelines.

Conclusion

Production AI agents in enterprise, finance, software engineering and other knowledge-intensive settings reason over documents, conversations, code and records that change over time and are full of near-duplicates. Retrieving that context through flat vector search alone is not reliable: similarity retrieves what looks related, not necessarily what is correct. HydraDB models knowledge as a versioned, relational, and time-aware context graph, combining sliding-window context enrichment, a Git-style temporal knowledge graph, hybrid retrieval, bounded graph traversal, and multi-stage reranking. Across eight public benchmarks it places first on every one with a public comparison except ATM-Bench, where it is second by 0.005: 88.7 on EnterpriseRAG-Bench, 91.4% recall@10 on FinanceBench, 81.1% on OfficeQA Pro V2, 90.73 on CodeWikiBench, 0.776 nDCG@k on KyroBench, 82% on BEAM 1M and 90.79% on LongMemEval-s. Where vanilla vector stores run on the same corpus, HydraDB's lead is largest at the top of the ranking. The advantage of a context graph is not specific to one domain or to agent memory: production AI agents need more than flat embeddings; they need structured context that preserves identity, relationships, chronology, and provenance.

References

1. LLMs: Bigger Is Not Always Better. Rigoni, T. Ampere Computing Blog (2024). amperecomputing.com
2. Lost in the Middle: How Language Models Use Long Contexts. Liu, N.F. et al. (2023). arXiv:2307.03172
3. Context Rot: How Increasing Input Tokens Impacts LLM Performance. Hong, K., Troynikov, A., Huber, J. (2025). research.trychroma.com
4. Introducing Contextual Retrieval. Ford, D. Anthropic Engineering (2024). anthropic.com
5. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Lewis, P. et al. (2021). arXiv:2005.11401
6. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. Wu, D. et al. (2025). arXiv:2410.10813
7. Evaluating Very Long-Term Conversational Memory of LLM Agents. Maharana, A. et al. (2024). arXiv:2402.17753
8. Lies, Damn Lies, & Statistics: Is Mem0 Really SOTA in Agent Memory? Chalef, D., Rasmussen, P. (2025). blog.getzep.com
9. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. Edge, D. et al. (2024). arXiv:2404.16130
10. Supermemory: State-of-the-Art Agent Memory on LongMemEval. Daga, S., Sreedhar, S., Shah, D. (2026). supermemory.ai/research
11. Zep: A Temporal Knowledge Graph Architecture for Agent Memory. Rasmussen, P. et al. (2025). arXiv:2501.13956
12. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. Chhikara, P. et al. (2025). arXiv:2504.19413
13. BEAM: Benchmark for Evaluation of AI Memory. Tavakoli, M. et al. (2025). arXiv:2510.27246
14. FinanceBench: A New Benchmark for Financial Question Answering. Islam, P. et al. (2023). arXiv:2311.11944
15. GraphRAG-Bench: Challenging Domain-Specific Reasoning for Evaluating Graph Retrieval-Augmented Generation. Xiao, Y. et al. (2025). arXiv:2506.02404
16. Selective Forgetting: A Graph-Based Memory Framework for Long-Term LLM Agents. (2026). arXiv:2608.28978
17. Hydra DB: Beyond Flat Embeddings for Production AI Agents. Hydra DB Research Team (2026). Read the HydraDB research paper
18. According to Me: Long-Term Personalized Referential Memory QA (ATM-Bench). Mei, J. et al. (2026). arXiv:2603.01990. Leaderboard: atmbench.github.io, retrieved October 2026.
19. KyroBench. KyroDB Research (2026). github.com/KyroDB/KyroBench
20. OfficeQA: A Grounded Reasoning Benchmark Suite. Databricks (2026). arXiv:2603.08655. Dataset: databricks/officeqa-pro-v2
21. CodeWiki: Automated Repository-Level Documentation at Scale. Nguyen Hoang, A., Le-Anh, M., Le, B., Bui, N. D. Q. (2025). arXiv:2510.24428. Dataset: CodeWikiBench
22. DeepWiki. Cognition. deepwiki.com
23. EnterpriseRAG-Bench: A RAG Benchmark for Company Internal Knowledge. Sun, Y. et al., Onyx (2026). arXiv:2605.05253. Leaderboard: Hugging Face, accessed 28 August 2026.
24. Hindsight: Long-Term Memory for AI Systems. (2026). arXiv:2512.12818. agentmemorybenchmark.ai