**
Beyond Chat History: Building Rooted, a Multi-Agent Plant Care System with Shared Memory in FalkorDB
**
How graph-based memory can help AI agents preserve context, coordinate tasks, and build continuity across interactions.
What happens when an AI agent finishes a task, a session ends, and another agent needs to continue the work later?
In many AI applications, the answer depends on how much information was included in the current prompt, what was saved in conversation history, or whether the application explicitly retrieves the right context. As applications become more complex, this creates an architectural challenge: how can multiple agents share knowledge and continue working without treating every interaction as an isolated event?
I explored this question while building Rooted, a multi-agent plant care application developed for Graph Hacks, the FalkorDB hackathon.
Rooted is built around a simple principle: caring for a plant is a continuous process, and the information that matters today may have been recorded days or sessions ago.
Rather than treating plant care as a sequence of independent questions and answers, Rooted maintains a connected history of observations, care events, tasks, and follow-ups in a shared FalkorDB graph.
This article explains the problem behind the project, the architectural decisions I made, how the agents interact with shared memory, and why graph databases are worth exploring when building AI systems that need continuity.
**
The problem: AI agents need more than conversation history
**
Imagine that you are taking care of a plant.
On Monday, you record that some of its leaves are turning yellow. On Tuesday, you water it. On Thursday, you return to the application and want to understand what has happened since your last visit.
A basic chatbot might answer the latest question using the information currently available to it. A conversation-history system might preserve the previous messages. But a useful plant care application needs to connect several different kinds of information:
What was observed?
Which plant was involved?
What care event happened afterward?
Is there a pending task?
Has a previous observation been updated or superseded?
What should the system carry forward into the next session?
These are not simply questions about retrieving text. They are questions about relationships, chronology, state, and continuity.
A plant's history is meaningful because its individual events belong together.
The same challenge appears in many other domains. An AI assistant supporting a developer needs to remember unresolved tasks. A research agent needs to connect findings across multiple sessions. A workflow agent needs to know what another agent has already completed.
In all these cases, memory is not just about storing information. It is about making the right information available at the right time.
That became the central design question behind Rooted: how can shared, persistent memory become part of the architecture of a multi-agent application?
**
Why FalkorDB?
**
Rooted uses FalkorDB as its shared graph memory layer.
A conventional record-based approach can store plant profiles, observations, and care events in separate structures. That is useful, but the application must still determine how those records relate to one another and which connections matter for a particular task.
A graph provides a natural way to represent entities and their relationships.
In Rooted, the relevant concepts include plants, observations, care events, tasks, and the history surrounding each plant. These are not independent records: they participate in a broader context that agents need to retrieve and update.
Conceptually, the information can be understood as a connected structure:
Plant → Observation → Care Event → Follow-up Task
This is a simplified illustration of the relationships that matter to the application, not a complete schema diagram.
The important point is that the system can preserve connections between pieces of information instead of relying exclusively on a flat conversation transcript.
FalkorDB provides the graph database foundation for that approach, while Rooted's application services determine how the graph is queried, updated, and used by the agents.
I did not choose a graph database simply because graph technology sounds interesting. The project is specifically about connected history: information becomes more useful when the application can follow the relationships between past observations, actions, and future work.
**
What graph-based memory changes
**
The difference is architectural.
Without a shared memory layer, each agent would need some other mechanism to receive the context it needs. That could mean passing large amounts of conversation history between agents, duplicating information, or implementing separate retrieval mechanisms for different workflows.
With shared graph memory, the agents can interact with a common persistent representation of the garden's history.
The graph does not automatically make an agent intelligent or guarantee that it retrieves the correct context. The application still needs explicit retrieval logic, well-defined tools, and rules for managing updates.
What the graph provides is a foundation for representing relationships that would otherwise need to be reconstructed repeatedly.
**
The architecture: three agents, one shared memory
**
Rooted is organized around three agents with distinct responsibilities: the Care Agent, the Observation Agent, and the Coordinator Agent.
Rather than giving every agent unrestricted access to everything, the application separates agent responsibilities from the services that manage plants, tasks, sessions, and graph operations.
The result is a multi-agent architecture in which specialized agents work within the same persistent context.
**The Care Agent
The Care Agent focuses on plant care interactions.
Care-related interactions can produce tasks that the application records and makes available for subsequent work. This connects a care interaction to the broader history of the plant rather than leaving it only in the current session.
The Observation Agent
The Observation Agent works with plant observations.
Observations are important because they capture information about a plant at a particular point in time. Rooted preserves their relationship to the plant's history, and its graph model supports the SUPERSEDES relationship for representing when a newer observation supersedes an earlier one.
This distinction matters: preserving history does not mean treating every recorded observation as equally current.
The Coordinator Agent
The Coordinator Agent helps coordinate work between agents.
Care and observation workflows can create tasks for the Coordinator. When a new session begins, Rooted retrieves pending tasks and can hand them off to the Observation Agent.
This is one of the most important architectural decisions in the project.
*A session ending does not have to mean that the work ends with it.
*
The application can preserve pending work in persistent storage and bring that work into a later session. The agents do not need to depend exclusively on the messages exchanged during a single conversation.
**
How the pieces fit together
**
The application uses Streamlit for its interface and separates its internal responsibilities into distinct areas:
agents/ contains the agent implementations.
graph/ handles FalkorDB connectivity, queries, seed data, and graph tools.
services/ manages sessions, tasks, handoffs, plants, and history.
This separation is intentional. Agents handle specialized interactions, services manage application workflows, and the graph layer handles persistent connected data.
The agents share memory through the application architecture rather than through an assumption that an LLM will remember everything on its own.
**
Following a workflow: from observation to future action
**
To understand why this architecture matters, consider a simplified workflow.
A user records an observation about one of their plants. That observation becomes part of the plant's persistent history, and the workflow creates a task for the Coordinator.
Later, the user opens another session.
Instead of relying solely on the new conversation, Rooted retrieves pending tasks. The Coordinator can hand off relevant work to the Observation Agent, which can continue from the context preserved by the application.
The flow can be summarized as follows:
Capture: A user supplies information about a plant or a care event.
Persist: The application records the relevant information in the graph.
Coordinate: The interaction can generate a task for the Coordinator.
Resume: A later session retrieves pending tasks.
Hand off: Relevant work is passed to the Observation Agent.
Continue: The agent works with the available plant history and task context.
This is not a claim that the system independently monitors plants in the background. The workflow is driven by user interactions and application logic.
The value lies in the continuity between those interactions.
The application has a mechanism to preserve unfinished work, retrieve it later, and make it available to another agent.
That is a more concrete form of multi-agent coordination than simply having several agents answer different types of questions.
**
Memory is not one thing
**
Another important design consideration was that different kinds of information serve different purposes.
Rooted's memory model distinguishes three useful concepts: episodic, semantic, and procedural memory.
These terms describe different roles that memory can play in an AI application.
Episodic memory: what happened?
Episodic memory concerns events and experiences associated with a particular history.
In Rooted, observations and care events contribute to the record of what happened to a plant and when.
This allows the application to preserve context across interactions rather than depending entirely on conversation history.
Semantic memory: what do we know?
Semantic memory concerns information and relationships that provide context.
A plant's recorded information and its connections to relevant observations and care events help form a more structured representation of what the application knows about that plant.
The goal is to make relevant context accessible without requiring every detail to be repeated in a new conversation.
Procedural memory: what needs to happen?
Procedural memory concerns the processes and actions that support continuing work.
In Rooted, tasks and pending follow-ups represent work that needs to be carried forward. The task and handoff mechanisms help the application resume that work in a later session.
These distinctions are useful as a design framework, but they should not be confused with three independent AI models or three separate databases. They describe different functions of memory within the application's architecture.
Together, they help explain why persistent memory should be designed around the needs of the workflow, not just around saving messages.
**
Preserving history without losing context
**
Persistent memory introduces another challenge: information changes.
Suppose a user records an observation and later provides an updated observation. Simply storing both records is not enough to communicate their relationship.
Which observation supersedes the other? Which one represents the newer information? Should the earlier record remain available?
Rooted uses the SUPERSEDES relationship to represent when a newer observation supersedes an earlier one.
This is valuable because history and current state are not necessarily the same thing.
Keeping previous observations can preserve context, while explicit relationships help communicate how records relate to one another.
This design also supports a broader principle: memory systems need to account for change, not merely accumulate data indefinitely.
In an AI application, preserving the history of information can be just as important as preserving the information itself.
**
Making graph access predictable
**
A graph database does not remove the need for careful application design.
In fact, giving AI agents access to persistent data introduces important engineering questions:
Which operations can an agent perform?
How are queries constructed?
How can writes be controlled?
Can the model invent a query that behaves differently from what the application intended?
How can the application make retrieved information traceable?
Rooted addresses these concerns by keeping graph operations within an explicit application layer.
Its graph access uses parameterized Cypher queries and a fixed tool catalog. The read-only ro_query path is separated from writes, which are handled through graph/db.py.
An optional Anthropic-based router can support the routing layer, but it does not generate Cypher queries. The application retains control over the available tools and the operations those tools perform.
This separation is important.
Rather than asking an LLM to generate arbitrary database queries and trusting the output, the application defines the available operations and controls how they interact with the database.
That does not eliminate every possible application or data-security risk, but it establishes a more predictable boundary between model-driven decisions and database operations.
Rooted also uses separate FalkorDB graphs for individual gardens, with a namespace such as rooted:demo-garden.
This provides a way to organize garden data separately at the graph level. It should not, however, be mistaken for a complete user authentication or authorization system; application authentication is not implemented in the current version.
These details may seem less exciting than the agents themselves, but they are part of building an AI system that can work with persistent data responsibly.
**
Traceability: understanding where an answer comes from
**
An AI system becomes more useful when its results can be related to the information that supports them.
In Rooted, graph-based answers can include paths and traces through the graph.
The idea is to make relevant relationships inspectable rather than treating the final response as an isolated piece of generated text.
For example, an application may need to understand how a plant's recorded history connects to a particular observation or care event. A graph path can provide a way to inspect that relationship.
This is not the same as guaranteeing that every natural-language answer is correct. The quality of an answer still depends on the data, the retrieval logic, and the agent's behavior.
However, preserving the relationships used in an application workflow creates a foundation for better inspection and debugging.
It also makes the graph more than a storage layer: it becomes part of how the application represents and explains context.
**
What Rooted does — and what it does not
**
It is important to define the boundaries of the project clearly.
Rooted is designed to organize user-provided plant information, maintain connected history, and support care workflows through specialized AI agents.
It does not currently diagnose plant diseases, identify plant species, or evaluate photographs. It also does not independently monitor plants or verify their physical condition.
These are deliberate distinctions between maintaining contextual information and making claims about the real world.
A recorded observation is information supplied to the application; it is not automatically a verified diagnosis.
Similarly, graph relationships can help organize a plant's history, but they do not independently prove that one event caused another.
Being explicit about these boundaries helps establish what the current implementation can demonstrate and what would require additional capabilities, validation, and testing.
There are also limitations in the current implementation. Rooted does not yet include application authentication, and its architecture has not been validated through concurrency benchmarks.
These are meaningful areas for future engineering work, particularly if the project evolves toward a multi-user production application.
**
Lessons from building Rooted
**
Building Rooted reinforced several ideas about AI application architecture.
Agents are only part of the system
Adding multiple agents does not automatically create a coordinated system.
The application still needs shared state, task management, explicit handoffs, and clear responsibilities. Otherwise, agents can become separate conversational interfaces with little continuity between them.
Memory needs structure
Conversation history can be useful, but it is not a substitute for a deliberate memory architecture.
The application must determine what information to preserve, how to relate it to other information, and how to retrieve it when a later task needs it.
Persistence is not the same as continuity
Saving information is only the first step.
Continuity emerges when the application can use that information to resume work, retrieve pending tasks, and connect new interactions to previous events.
Guardrails belong in the architecture
The model should not have to be the only line of defense controlling database access.
Explicit tools, parameterized queries, and application-managed writes help keep data operations within defined boundaries.
Graph databases should solve a real problem
Using a graph database is not valuable simply because an application contains connected data.
The choice becomes meaningful when relationships are central to the problem being solved.
In Rooted, the relationship between a plant, its observations, its care history, and its pending work is fundamental to the experience the application is designed to provide.
That is the reason graph-based memory fits the project.
**
Conclusion: From Remembering Conversations to Continuing Work
**
Rooted started with a practical problem: plant care evolves over time, but individual interactions do not always capture the full picture.
By combining specialized AI agents, persistent graph memory, and explicit task handoffs, Rooted explores a different approach to building AI systems that can carry context forward.
The Care Agent, Observation Agent, and Coordinator Agent operate within an architecture where plant history and pending tasks can persist beyond a single session. FalkorDB provides the graph foundation for connecting the information that makes this possible.
The idea extends far beyond plant care.
As AI applications evolve from answering isolated questions to supporting long-running workflows, memory becomes an architectural concern. Systems need ways to preserve context, connect events, manage changing information, and resume unfinished work.
A conversation history tells a system what was said. A well-designed memory architecture helps it connect that information to what happened before and what needs to happen next.
That is the idea behind Rooted: shared memory for continuous plant care.
Built for Graph Hacks with FalkorDB.
By: CapybaraBR
