Waaris: Agentic AI with FalkorDB and Gemini

Team: Legacy Labs Hackathon: Graph Hacks – Context for AI Agents Technologies: FalkorDB, Google Gemini 2.5 Flash, Cypher, Agentic AI

When a loved one passes away, families may face a complicated administrative process to claim bank deposits, mutual fund investments, and other financial assets.

Each financial institution can have its own documentation procedures, verification requirements, and claim process. Families may need to understand nominee information, establish legal heirship where required, collect supporting documents, and follow up with multiple institutions.

The challenge is not simply finding information. It is understanding how people, assets, institutions, and documents relate to one another.

A document relevant to one claim might also help progress several other claims. However, identifying these relationships across multiple accounts and institutions can be difficult.

Traditional chatbots can explain general procedures, but they may struggle to answer structured questions that require traversing relationships, counting affected accounts, and comparing financial values.

What if an AI agent could connect these relationships and help families identify which documents may be most useful for progressing their claims?

That question inspired us to build Waaris, our project for the Graph Hacks – Context for AI Agents hackathon.

Waaris is an agentic AI prototype designed to help users explore inheritance-related information and documentation dependencies through a connected knowledge graph.

Instead of treating every question as an isolated text-search problem, Waaris represents relevant information as interconnected entities and relationships.

Our approach combines three core technologies:

Together, these technologies provide a foundation for answering questions using structured graph context rather than relying exclusively on generated text.

The central design decision in Waaris is to model inheritance-related information as a graph.

A deceased person has several financial accounts across different institutions. Multiple documents may be associated with the requirements for progressing those claims. One document could be relevant to more than one account.

Representing this information in isolated records makes it harder to explore the relationships between all these entities.

A graph makes those connections explicit.

FalkorDB allows the application to traverse these relationships and perform structured queries over the connected data.

The graph is not merely a visual representation. It is a queryable source of context that supports the agent's answers.

We designed Waaris around six main node types.

Represents the person whose financial assets may need to be claimed.

Represents a person who may have a family or legal relationship to the deceased. The relationship alone does not establish legal entitlement.

Represents a bank account, mutual fund investment, or another financial asset included in the system.

Represents the bank or financial institution associated with an account.

Represents a potentially relevant document, declaration, form, or legal record.

Represents a documentation, verification, or procedural condition associated with a claim.

These relationships allow the system to reason about dependencies across multiple connected entities.

The exact relationship semantics depend on the graph data and the rules used to populate it. In a production system, these rules must be validated against authoritative legal guidance and institution-specific documentation.

One of the questions we designed Waaris to explore is:

"Which one document could help unblock the most accounts, and what is their combined value?"

This question requires more than retrieving a paragraph about succession documents.

This is where graph traversal and database-side aggregation become useful.

Rather than asking the language model to estimate the answer, we can express the calculation directly in Cypher.

Here is the Cypher query for this example:

MATCH ( d: Document ) - [:UNLOCKS ] -> ( a: Account ) WHERE a.status IN [ 'blocked', 'in_progress' ] RETURN d.name AS document, count ( DISTINCT a ) AS accounts_unlocked, sum ( a.amount_inr ) AS total_value ORDER BY accounts_unlocked DESC LIMIT 1; Enter fullscreen mode Exit fullscreen mode How the query works Step 1: Traverse the graph

MATCH ( d: Document ) - [:UNLOCKS ] -> ( a: Account ) Enter fullscreen mode Exit fullscreen mode This finds document nodes connected to account nodes through the UNLOCKS relationship.

WHERE a.status IN [ 'blocked', 'in_progress' ] Enter fullscreen mode Exit fullscreen mode Only accounts with the specified statuses are considered.

count ( DISTINCT a ) AS accounts_unlocked, sum ( a.amount_inr ) AS total_value Enter fullscreen mode Exit fullscreen mode The query counts distinct connected accounts and calculates their combined recorded value.

ORDER BY accounts_unlocked DESC LIMIT 1 Enter fullscreen mode Exit fullscreen mode The query returns the document with the highest number of associated accounts.

This example prioritizes account count rather than total financial value. A different business objective could use a different ranking strategy.

The result is derived from the graph data and query logic, not invented by the language model.

An important implementation detail: The UNLOCKS relationship must be created using validated rules. It should not imply that submitting a document automatically guarantees claim approval. The summed value represents the accounts associated with the selected document, not necessarily the amount that will ultimately be recovered. If an account can be connected through multiple paths, aggregation must also be designed to avoid double-counting.

The intended workflow connects natural-language interaction with structured graph querying.

User question → Gemini 2.5 Flash agent → Cypher query execution → FalkorDB → Structured query results → Natural-language response

"Which document is associated with the highest number of blocked accounts?"

Gemini helps interpret the user's intent and identify the appropriate graph operation.

The application executes the relevant Cypher query against FalkorDB.

The database returns the matching documents and the requested aggregate values.

The agent converts the structured result into a readable explanation, ideally including the relevant account count, associated value, and supporting context.

The language model handles natural-language interpretation and explanation, while the graph query performs the explicit traversal and aggregation.

The architecture makes it easier to inspect how a result was calculated and test the underlying query independently.

Vector retrieval and graph databases solve different problems, and they can complement each other.

Vector search is useful for finding relevant passages in lengthy documents, such as official bank procedures, legal guidance, and claim instructions.

A graph database is particularly useful when the question depends on explicit relationships between entities.

For Waaris, consider the difference between these two questions.

Question A: "What documents does a bank's published guidance mention for a particular type of claim?"

This can benefit from document retrieval and source-grounded summarization.

Question B: "Which document is connected to the largest number of blocked accounts in our graph?"

This requires structured traversal and aggregation.

A vector similarity score alone does not answer Question B reliably.

By representing relationships explicitly and executing Cypher queries, Waaris can calculate the answer from the available graph records.

The broader lesson is not that vector RAG is unnecessary. It is that the retrieval and reasoning strategy should match the question being asked.

A more comprehensive system could combine document retrieval for evidence with graph queries for relationship-based analysis.

Inheritance-related applications require particular care because incorrect guidance can cause financial and legal harm.

Waaris is a prototype intended to explore how connected context can support administrative workflows. It should not be treated as a legal authority or a guarantee of financial recovery.

A production implementation would need several safeguards:

Nomination, succession, and legal ownership are not interchangeable concepts. The applicable rules depend on the asset, the institution, the relevant law, and the circumstances of the claim.

Reliable assistance requires more than a convincing AI-generated answer. It requires trustworthy data, explicit rules, and results that can be checked.

Building Waaris has highlighted an important architectural lesson: natural-language understanding and relational reasoning are different responsibilities.

A language model can interpret a question, but it should not be expected to perform every multi-entity calculation from memory.

A graph database can represent explicit relationships and execute repeatable queries, but it can only provide reliable results when the underlying data and relationships are correct.

Combining the two allows us to explore a more structured approach to agentic AI.

The most important design principle is simple:

Let the agent understand the question, let the database calculate the result, and make the evidence behind the answer inspectable.

This approach can be useful beyond inheritance-related workflows. Similar patterns may help in compliance analysis, document dependency management, financial operations, and other domains where relationships between entities matter as much as the entities themselves.

Our future development priorities include:

These improvements would help move Waaris toward a more reliable and transparent assistant for complex administrative processes.

Project: Waaris — Agentic AI Inheritance Assistant

Hackathon: Graph Hacks – Context for AI Agents

Waaris explores how agentic AI can become more useful when it operates over explicit, connected context.

By combining Gemini's natural-language capabilities with FalkorDB's graph representation and Cypher's structured querying, we are exploring a way to answer relationship-heavy questions with results that can be inspected and tested.

The goal is not simply to generate an answer that sounds correct. It is to connect the relevant information, execute a verifiable operation, and explain the result clearly.

For us, that is the potential of graph-powered context for AI agents.

Built by Team Legacy Labs for Graph Hacks – Context for AI Agents.