The Context Substrate for Financial AI: HydraDB

Introduction

Your financial AI agent does not just have a context problem. It has a context quality, retrieval accuracy, retrieval speed, and broken ontology problem.

A company may already have thousands of 10-Ks, 10-Qs, earnings reports, analyst notes, internal documents, emails, transactions, and market data. Storing this information is easy, and embedding it into a vector database is also easy. The harder problem is giving an AI application the right information, from the right time, connected to the right entities, with enough evidence to trust the answer.

Are you still using RAG?? Stop using it. Vector search is very good at finding text with similar meaning, but real applications also need exact identifiers, relationships, historical state, current state, provenance, metadata, and a way to combine all of them into a small context that the model can reason over. HydraDB is designed for this larger problem. Instead of acting only as a retrieval engine, it acts as the context substrate underneath the application.

A traditional RAG system usually follows a simple pipeline: documents are split into chunks, embedded, stored in a vector database, retrieved with similarity search, and sent to an LLM. This works well for questions such as, “What was operating margin in Q2?” But financial applications quickly become more complex. An analyst may ask, “Which companies in my portfolio had declining margins this quarter, what caused the decline, and was the same reason mentioned last quarter?”

Now the system must understand companies, reporting periods, metrics, previous filings, current filings, causes, and supporting evidence. The answer might not exist inside one chunk. It may need to be reconstructed from several connected facts. This is why retrieval alone is not the application. Retrieval is only one primitive inside a larger context system. This is why HydraDB exists: it not only injects the right context for AI agents, but also builds an ultra-fast knowledge-graph database. Beyond a knowledge graph, HydraDB builds concrete ontologies, which are important for structuring the database for better contextualization.

FinanceBench gives us a way to measure whether HydraDB can solve the first part of this problem which is finding the right evidence inside dense financial documents. FinanceBench contains questions based on real financial filings where the correct supporting passages are known. On this benchmark, HydraDB reaches 89.0% Recall@10 in fast mode and 91.4% in thinking mode. Thinking mode also improves the top of the ranking, reaching 50.3% Recall@1 and 84.3% Recall@5. This matters because an application does not just need the correct passage somewhere inside 100 retrieved chunks. It needs the strongest evidence near the top. Every irrelevant chunk increases token cost, adds noise, and makes the reasoning problem harder. A good retrieval system should therefore maximize relevant evidence while minimizing unnecessary context.

HydraDB also reports an average context size of roughly 8K tokens per FinanceBench query in fast mode. This is an important application metric because larger context windows are not free. Sending 50,000 or 100,000 tokens to the model on every request increases inference cost, latency, and the amount of irrelevant information the model must process. The goal of a context layer should not be to retrieve as much information as possible; rather, it should retrieve the smallest amount of information needed to answer correctly. In simple terms, more context does not automatically mean better memory. In-context learning (the prompt) is temporary working memory, but an application still needs persistent infrastructure that knows what information exists, what changed, what is current, and what should be retrieved for a particular task.

This is also where a vector database alone becomes limiting. Suppose a company reports that operating margin fell in Q2 because of higher logistics costs, management later announces a cost-cutting program, and in Q3 the company reports that margins improved after logistics expenses declined. A vector database mostly sees three separate pieces of text. A financial application needs to understand how they are connected over time:

Now a question such as “Why did margins recover in Q3?” does not depend on finding one paragraph containing the complete explanation. HydraDB can retrieve the relevant company and metric, follow the relationships across reporting periods, preserve the temporal order, and return the original filing evidence behind the conclusion.

Time is especially important because enterprise and financial knowledge constantly changes. A company may issue new guidance, revise a forecast, change ownership of a project, update a policy, or replace an earlier assumption. A flat retrieval index can store the old and new statements, but similarity search alone does not know which one represents the current state. HydraDB uses a versioned temporal graph so changes can be preserved instead of simply overwriting old knowledge. This allows an application to answer both “What is true now?” and “What was true before?” That difference is fundamental. Search systems retrieve information; applications operate on state, and state changes over time.

HydraDB therefore combines several retrieval signals instead of assuming that semantic similarity solves every problem. Dense search is useful for meaning, BM25-style search is useful for exact identifiers such as AUTH-503, graph traversal is useful for relationships, temporal information is useful for current versus historical state, and metadata is useful for filtering by user, workspace, company, or permission. One query may need several of these signals at once. A financial application asking “Who currently owns the project blocked by AUTH-503?” may require exact search to locate the ticket, graph traversal to find the connected project, and temporal state to determine the current owner. That is why the context layer should be more than a vector index.

The larger architectural idea is simple. Instead of every application building its own chunking, embeddings, retrieval, graph logic, temporal logic, reranking, and memory system, those capabilities can live inside one shared substrate. A financial research agent, compliance assistant, portfolio agent, earnings copilot, or due-diligence system can all operate on the same persistent context layer. The applications focus on workflows and reasoning; HydraDB manages how knowledge is stored, connected, updated, retrieved, and assembled. This is similar to how applications today build on databases rather than implementing their own storage engine. In the same way, AI applications should not need to rebuild their own memory and context infrastructure every time.

This also separates the model from the knowledge system. Models will keep changing. An application may use GPT today, another frontier model tomorrow, and a smaller specialized model for cheaper workloads. The organization's knowledge should not need to be rebuilt every time the LLM changes. The model should act as the reasoning engine, while HydraDB acts as the persistent context and state layer underneath it. Better models do not remove the need for good context. A powerful model being stateless can still produce the wrong answer. Application intelligence is therefore better understood as the combination of the model, context, state, relationships, tools, and evidence.

HydraDB sits between raw enterprise data and the applications that need to reason over it. Below it are filings, documents, Slack messages, databases, APIs, transactions, and internal systems. Above it are financial agents, research tools, copilots, compliance systems, and autonomous workflows. HydraDB's job is to turn all of that raw information into context that is relevant, connected, current, traceable, and compact.

Conclusion

Financial AI applications need more than a larger context window or a vector index. They need a context substrate that can retrieve the correct evidence, preserve relationships and historical state, distinguish current facts from superseded information, and assemble everything into compact context a model can reason over. On FinanceBench, HydraDB achieves 91.4% Recall@10 in thinking mode and 89.0% in fast mode, while using roughly 8K context tokens per query on average. By combining dense and exact retrieval, graph relationships, temporal state, metadata, provenance, and reranking, HydraDB gives financial research, portfolio analysis, compliance, due-diligence, and other financial AI agents a stronger and more dependable foundation for reasoning over continuously changing enterprise knowledge.

References

1. Hydra DB: Technical Paper. Hydra DB (2026). Read the HydraDB research paper
2. FinanceBench: A New Benchmark for Financial Question Answering. Islam, P., Kannappan, A., Kiela, D., Qian, R., Scherrer, N., Vidgen, B. (2023). arXiv:2311.11944
3. Hydra DB FinanceBench Evaluation Code. GitHub. github.com/usecortex/hydradb-bench