Track: Track 1 — Agents That Act on Connected Data
Event: Graph Hacks 2026 by WeMakeDevs and FalkorDB
AI agents are becoming increasingly capable of answering questions, analyzing information and automating workflows. However, an important challenge remains: an agent can only make a reliable decision when it has the right context.
Consider a suspicious financial transaction. Looking at the transaction amount alone might not tell us much. But what if the sender shares a device with several other accounts? What if those accounts are connected through other transactions? What if some of those transactions are already under review?
The answer is no longer contained in one record. It depends on how multiple pieces of information connect.
That was the problem I explored while developing GraphGuard, a graph-powered fraud investigation prototype built for the Graph Hacks 2026 hackathon.
My goal was to explore how a graph database can help an agent investigate connected records, identify potentially relevant relationships and present an understandable evidence trail.
Traditional data analysis often starts with individual records, filters, tables and reports. These tools are useful, but complex investigations can require following relationships across multiple entities.
For example, an analyst might need to answer questions such as:
If an AI system receives only an isolated transaction record, it may miss important connections or produce an explanation unsupported by the available data.
GraphGuard explores a different approach: represent entities and their relationships explicitly, query those relationships, and use the resulting evidence to support an investigation.
GraphGuard is a prototype for connected-data investigation. It combines a Python application, FalkorDB graph queries and transparent investigation rules to help explore suspicious transaction patterns.
Its main capabilities include:
The application uses synthetic demonstration data. It is an educational prototype, not a production fraud-detection platform.
The central idea behind GraphGuard is that relationships are part of the data, not merely details to reconstruct later.
FalkorDB is a graph database that supports graph modeling and Cypher queries. It allows the application to represent entities as nodes and their connections as relationships.
Instead of treating accounts, devices and transactions as unrelated rows, GraphGuard models how they connect.
This is especially useful for investigations where the important question is not just what happened? but what else is connected to it?
I designed the prototype around three main node types.
1. Account
An account stores an account identifier, a display name and a configured demonstration risk score.
2. Transaction
A transaction stores an identifier, amount, status and timestamp.
3. Device
A device represents a device associated with one or more accounts.
The graph uses these relationships:
SENDS: an account sends a transaction. RECEIVED_BY: a transaction is associated with its receiving account. USES_DEVICE: an account uses a device. LINKED_TO: two accounts have a recorded relationship.
A simplified representation looks like this:
(Account)-[:SENDS]->(Transaction)
(Transaction)-[:RECEIVED_BY]->(Account)
(Account)-[:USES_DEVICE]->(Device)
(Account)-[:LINKED_TO]->(Account)
This model makes it possible to move between transaction records and related entities through graph queries.
One example is finding other accounts that share a device with a selected account.
MATCH (a:Account)-[:USES_DEVICE]->(d:Device)
<-[:USES_DEVICE]-(other:Account)
WHERE a.account_id = $account_id
AND other.account_id <> a.account_id
RETURN other.account_id AS related_account,
d.device_id AS shared_device
LIMIT 20
The query starts with an account, follows its connection to a device and then finds other accounts connected to that same device.
This is a simple example of why graphs are useful: a relationship can reveal relevant context that is not obvious when examining an account in isolation.
A shared device is not proof of wrongdoing. It is a relationship that may warrant further investigation, depending on the circumstances.
The prototype follows a straightforward workflow.
Step 1: Select an account or transaction.
The user chooses an entity to investigate from the dashboard.
Step 2: Retrieve connected evidence.
The graph layer retrieves relevant outgoing transactions, related accounts and shared-device connections.
Step 3: Evaluate transparent indicators.
The investigation logic checks configured conditions, such as a high demonstration risk score, transactions above a threshold, transactions pending review and shared-device connections.
Step 4: Present the results.
The application summarizes the findings and displays the evidence records in a table.
Step 5: Recommend follow-up checks.
The prototype suggests that an analyst review transaction context, investigate shared-device relationships and inspect existing review or decline reasons where applicable.
The current implementation uses graph queries and deterministic rules. An LLM-powered tool-selection and reasoning loop is a possible future extension, rather than a feature I claim is already complete.
The Streamlit interface is organized into four sections:
Account Investigation: Select an account and inspect its risk indicators and outgoing transactions.
Transaction Investigation: Trace a transaction to its sender and recipient and inspect connected-device evidence.
Graph Explorer: View a summary of relationships returned by the graph layer.
About: Review the architecture, intended workflow and limitations.
The project also includes a local demonstration fallback, allowing the interface to be explored when a FalkorDB server is unavailable. The fallback is useful for development, but a proper hackathon demonstration should verify the live FalkorDB integration.
The prototype uses the following technologies:
The application is designed to run locally and uses synthetic data so the demonstration does not depend on real financial records.
This project helped me explore several important ideas about building graph-powered AI applications.
1. Relationships can be more informative than isolated records.
An individual transaction may not tell the whole story. Connections between accounts, devices and transactions can reveal useful context for investigation.
2. Explainability should be designed into the workflow.
A system should not merely label something suspicious. It should show the records and relationships that contributed to its assessment.
3. Graph queries and language models have different responsibilities.
A graph query retrieves connected evidence. A language model can potentially help interpret a question or explain the returned evidence, but it should not invent records or relationships.
4. Risk indicators need careful interpretation.
A high configured score, large transaction or shared device does not establish fraud. Results should be treated as leads for human review.
5. A working prototype needs more than a user interface.
Database connectivity, query correctness, reproducible setup instructions and meaningful test cases are important parts of the project.
GraphGuard is an early-stage prototype. There are several improvements I would like to make next:
These improvements would move the project closer to an agent that actively uses connected data to investigate a question and explain its findings.
The project repository includes a README with the setup instructions.
The basic workflow is:
pip install -r requirements.txt. streamlit run app.py.
Source code: [Add your public GitHub repository URL here]
Demo video: [Add your public demo video URL here]
Project status: [Describe what you personally tested and verified before publishing.]
GraphGuard explores how connected data can make AI-assisted investigations more transparent and useful.
The main lesson is simple: when a question depends on relationships between multiple records, the system needs access to those relationships—not just a collection of isolated facts.
By combining a graph model, Cypher queries and evidence-based investigation rules, GraphGuard provides a foundation for exploring that idea. The next step is to develop a more capable agent that can select graph tools, follow multi-hop relationships and explain its findings with traceable evidence.
This project is my contribution to Graph Hacks 2026 — Track 1: Agents That Act on Connected Data, powered by WeMakeDevs and FalkorDB.
I'm continuing to learn about graph databases, agent architectures and responsible AI systems, and I'm excited to keep improving the project.
Disclosure: AI-assisted development tools were used during the development process. I am responsible for reviewing, testing and understanding the code and technical decisions included in the final submission.