Track: Track 1 — Agents That Act on Connected Data
Event: Graph Hacks 2026 by WeMakeDevs and FalkorDB
Introduction
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.
The Problem: Data Without Context
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:
- Which accounts are connected to a particular transaction?
- Are multiple accounts using the same device?
- Which transactions are associated with an account under review?
- What evidence supports an investigation alert?
- What should an analyst inspect next?
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.
Introducing GraphGuard
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:
- Investigating an account and its outgoing transactions.
- Tracing a transaction from sender to recipient.
- Identifying accounts connected through shared devices.
- Flagging configurable risk indicators.
- Displaying the evidence behind an investigation.
- Suggesting follow-up checks for a human analyst.
The application uses synthetic demonstration data. It is an educational prototype, not a production fraud-detection platform.
Why FalkorDB?
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?
Designing the Graph Data Model
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.
Following Connections with Cypher
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.
How the Investigation Workflow Works
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.
Exploring the Dashboard
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.
Technology Stack
The prototype uses the following technologies:
- Python: Core application logic and investigation workflows.
- FalkorDB: Graph storage and relationship queries.
- Cypher: Query language for traversing the graph.
- Streamlit: Interactive dashboard.
- Docker Compose: Local database setup.
- Pytest: Basic tests for investigation behavior.
The application is designed to run locally and uses synthetic data so the demonstration does not depend on real financial records.
What I Learned
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.
Limitations and Future Improvements
GraphGuard is an early-stage prototype. There are several improvements I would like to make next:
- Add an LLM-powered agent that selects from a controlled set of investigation tools.
- Implement deeper multi-hop graph traversal and explainable relationship paths.
- Add an interactive graph visualization.
- Expand automated tests and validate behavior against a live FalkorDB instance.
- Improve data validation, error handling and configuration.
- Add evidence-linked natural-language reports.
- Explore agent tool integration through MCP, with access controls and read-only query tools where appropriate.
- Evaluate investigation quality against a larger, carefully designed synthetic dataset.
These improvements would move the project closer to an agent that actively uses connected data to investigate a question and explain its findings.
Running the Project
The project repository includes a README with the setup instructions.
The basic workflow is:
- Install Python and, optionally, Docker Desktop.
- Install the dependencies with
pip install -r requirements.txt. - Start FalkorDB using Docker Compose.
- Launch the interface with
streamlit run app.py. - Select a sample account or transaction and inspect the returned evidence.
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.]
Conclusion
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.
Top comments (0)