AgentMesh 利用 FalkorDB 為 AI 智能體提供持久記憶

AI agents can answer questions, use tools, and automate tasks. But building agents that maintain context across sessions and stay consistent when decisions change presents a different challenge.

During FalkorDB Graph Hacks 2026, I built AgentMesh, a graph-powered persistent memory and coordination layer designed to help AI agents retain project knowledge, retrieve previous decisions, and identify contradictions.

The central idea is simple: instead of treating project knowledge as isolated text, represent it as a connected graph of memories, relationships, agents, and decisions.

The Problem: AI Agents Need More Than Conversation History

Imagine working with an AI assistant on a software project.

On Monday, you decide to build your mobile application using Flutter. You also establish an API rate limit and choose a date for beta testing.

On Tuesday, you start a new session and ask the assistant about those decisions. If the relevant context is unavailable, you may need to explain everything again.

The problem becomes more complicated when requirements change. If you replace Flutter with native iOS and Android development, the system should recognize that the new decision conflicts with the old one rather than treating both as simultaneously valid.

This motivated three questions:

How can an agent retrieve relevant information from previous sessions?
How can it understand relationships between stored decisions?
How can it detect conflicting information without losing historical context?

AgentMesh explores these questions through graph-based memory.

Introducing AgentMesh

AgentMesh is a persistent memory layer for multi-agent AI systems.

It uses three specialized agents:

Researcher: Extracts important information from user interactions and stores it as structured memories.
Planner: Retrieves relevant memories and uses them to answer questions with supporting context.
Reviewer: Identifies contradictions between existing information and new decisions, helping the user resolve them.

Each agent has a distinct responsibility, while the graph database provides a shared representation of project knowledge.

The goal is to separate memory management, retrieval, and conflict review instead of placing every responsibility inside one general-purpose agent.

Why FalkorDB?

The key technology behind AgentMesh is FalkorDB.

Traditional conversation histories are primarily sequential. However, project knowledge is rarely just a sequence of messages. A decision can relate to a task, affect another decision, belong to a session, or conflict with a newer requirement.

A graph provides a natural way to represent these connections.

In AgentMesh, the data model can represent entities such as:

Memories
Agents
Sessions
Tasks
Conflicts

Relationships connect these entities and capture how information is created, related, supported, or contradicted.

For example, a stored decision about Flutter can be connected to the project session in which it was created. If a later decision introduces Swift and Kotlin, the system can associate the new information with the earlier decision and flag the conflict.

This makes relationships part of the memory model rather than relying exclusively on keyword matching.

How the Architecture Works

The workflow follows four main stages.

1. Extract and Store
The user provides project information. The researcher identifies useful facts and decisions, which are stored in FalkorDB as graph data.

For example, a user might specify the mobile technology, API rate limit, and planned beta date. These facts become retrievable memories.

2. Retrieve Relevant Context

The user asks a question in a later interaction.

The Planner retrieves relevant memories from the graph and uses them to construct an answer. The objective is to provide useful project context without requiring the user to repeat every earlier decision.

3. Detect Contradictions

Suppose the user changes the mobile application strategy from Flutter to native development using Swift and Kotlin.

The reviewer compares the new information with the relevant existing memory. If the two decisions conflict, AgentMesh can surface the contradiction for review.

4. Preserve the History

Changing a decision should not necessarily erase the fact that the earlier decision existed.

Preserving the historical record provides useful context about how a project evolved. It also helps distinguish an earlier decision from the current direction.

This is an important design principle: a change in knowledge should be traceable, not silently destructive.

Demonstrating AgentMesh

The demonstration follows a simple project workflow.

First, the user provides several architectural decisions. AgentMesh extracts and stores the information.

Next, the user asks the system to summarize previous technology decisions. The planner retrieves the relevant context.

Then, the user changes the mobile development strategy. The reviewer identifies the contradiction between the earlier and newer decisions.

Finally, the user starts a new session and asks about the previously established API rate limit. AgentMesh retrieves the stored value from persistent memory.

This sequence demonstrates the intended lifecycle of project knowledge: creation, retrieval, revision, and recall.

Technical Challenges and Design Decisions

Building a graph-powered memory system involves more than storing text in a database.

Representing information meaningfully: Memories need enough structure and relationships to support useful retrieval. Poorly modeled data can make even a graph database difficult to query effectively.

Retrieving the right context: Retrieving every stored memory would be inefficient and could introduce irrelevant information. The system needs to identify memories relevant to the user's current question.

Handling conflicting decisions: A new statement does not always replace an earlier one. It may contradict it, refine it, or apply under different circumstances. Making these distinctions is important for maintaining consistency.

Maintaining traceability: Answers are more useful when users can inspect the memories that support them. Connecting retrieved information to its source provides a foundation for explainable retrieval.

These challenges shaped the design of AgentMesh and highlighted the importance of treating memory as structured, evolving project knowledge.

What I Learned

Working on AgentMesh reinforced several lessons.

First, memory is not just storage. A system can retain large amounts of information and still fail to retrieve the right facts. Relationships and retrieval strategy matter.

Second, graph modeling should follow the problem. The purpose of using a graph is not simply to store nodes and edges. The model should represent relationships that help solve the application’s actual problems.

Third, changing information requires careful handling. When requirements evolve, preserving the distinction between historical and current decisions is essential.

Finally, a multi-agent architecture needs clear responsibilities. Separating extraction, planning, and review creates a more understandable design than treating every operation as the same task.

FalkorDB provided a way to explore these ideas using connected data as the foundation for persistent agent memory.

What's Next?

There is plenty of room to improve AgentMesh.

Potential next steps include more sophisticated retrieval strategies, stronger conflict classification, richer memory provenance, and evaluations that measure retrieval accuracy and conflict detection quality.

I would also like to explore how the architecture behaves as the graph grows and how it can support more agents working on longer-running projects.

These improvements would help establish whether the approach remains useful beyond a controlled demonstration.

Conclusion

AgentMesh explores a practical challenge in agentic AI: helping agents maintain useful context as projects evolve.

By combining specialized agents with FalkorDB's graph-based data model, the project brings together persistent memory, relationship-aware retrieval, and contradiction review.

The broader lesson is that useful AI memory should do more than remember what was said. It should help systems understand how information connects, identify when decisions change, and make past knowledge available when it matters.

The goal is to build AI agents that do not just respond to the current message but can work with the evolving history of a project.

Project Links

GitHub repository: https://github.com/MOHITPRADHAN35/agentmesh
Technology: FalkorDB, Python, FastAPI, React, and an LLM provider

Built for FalkorDB Graph Hacks 2026.