A New Paradigm for Multi-Agent Collaboration: Replacing Prompt-Based Context Passing with a Graph Database

Multi-agent system demos are often impressive, but when it comes to production, there's an awkward truth that's hard to avoid: agents pass context between each other essentially by relaying prompts. One agent does research and produces a summary, the summary gets pasted into the next agent's prompt, the next agent adds more content and produces an even longer summary to pass along. This approach barely works for a single session at demo scale, but the context is both long and lossy—each hop loses a layer of information—and once the process ends, the memory evaporates. Start a new session the next day, and the whole team knows nothing about what happened before.

This is exactly the starting point for Crew Memory Graph, built by Lusavio at the Graph Hacks hackathon (organized by WeMakeDevs around FalkorDB as an AI agent context layer). Their approach is straightforward: give three agents (Planner, Researcher, Executor) a shared graph database as a "notebook" instead of having them paste summaries to each other.

Design Principle: Remove FalkorDB and Nothing Remains

The hackathon's core requirement was that FalkorDB must play a critical role, not be decoration. Lusavio turned this requirement into a design rule before writing any code: remove FalkorDB, and nothing should remain in the system.

No cross-session memory, no shared state between agents, no company knowledge base, no answers. This rule forced an honest architecture: agents are stateless by design. At deployment, all state—everything the team learned, planned, decided, and handed off—exists in exactly one place: one FalkorDB graph per tenant, accessible only through parameterized Cypher traversals.

This solves the three fundamental problems of prompt relay: context is no longer lossy (data in the graph is exact, not a summary of a summary), no longer evaporates (the graph is persistent and survives across sessions), and no longer requires the act of "pasting" (agents read the same data through traversal).

FalkorDB is a sparse-matrix-based graph database designed for low-latency graph traversal and path queries. It is compatible with the openCypher query language and natively supports vector indexes, which is why it is often used as a context storage layer for AI applications. Unlike keeping state in process memory or a vector store, a graph database persists relationships between entities as nodes and edges, so multi-hop reasoning (e.g., "who decided what, and based on which document") can be completed in a single traversal. In the agent context, this means memory is not a block of text that can be summarized, but a set of structured facts that can be queried precisely. FalkorDB's tenant isolation is typically achieved through separate graph instances or namespaces, which is the basis for the "one graph per tenant" approach in this article.

Three Layers of Memory, One Graph

Crew Memory Graph organizes memory in three layers corresponding to the requirements of Track 02.

Episodic Memory: What Happened

Sessions, episodes, and handoffs are recorded in order, and every write carries provenance: which agent, which session, when, and from what source. This layer lets the system answer "what happened before" instead of relying on the current session's context window.

Semantic Memory: What Is True

The company's own structure—people, teams, projects, documents, tickets, decisions, topics, chat threads—plus every fact the team learns along the way, all linked to the entities they involve. This layer is the skeleton of company knowledge.

Procedural Memory: How We Do Things

Plans and processes are stored as step graphs, so a plan written by one agent is a structure another agent can execute, rather than a paragraph that needs to be reinterpreted. This layer turns collaboration from "passing text" into "passing structure."

The demo company, Meridian Labs, is fully synthetic—programmatically generated from a fixed seed, with core parts manually pinned, and labeled as synthetic data in the UI. This is critical: every question has a precise, verifiable ground truth. The impressiveness of the demo is not that the answers sound plausible, but that the answers are right or wrong with respect to a known graph.

The Handoff Is the Real Demo

The centerpiece is a cross-session handoff.

In Session 1, the Researcher is taught a launch brief about the Beacon mobile app—release date, beta tester count, a blocker. The Planner converts the brief into a step plan and initiates a handoff to the Executor. The handoff itself contains no brief content; it references precise memory nodes. No text is passed between agents, because there is nothing to pass—only the graph.

In Session 2, a brand-new Executor starts up. A different process, an empty context. It finds the unfinished handoff through traversal, follows the REFERENCES edge to the memory written in Session 1, and answers the questions in the handoff—when Beacon launches, how many beta testers there are—using a memory it never saw being written. Then it executes the next step of the plan, closes the handoff, and writes its own results back to the graph as a new episode.

The same flow also runs in headless mode as two genuinely separate processes—because a handoff that only works within a single process isn't a handoff, it's a variable.

In agent systems, a handoff refers to one agent transferring an unfinished task and its context to another agent to continue processing. Traditional implementations often serialize the context into natural language or JSON and stuff it into the next agent's prompt, which leads to information compression and distortion. Graph-based handoffs are different: the handoff itself is a node that points to specific entities and events in memory via edges such as REFERENCES, and the new agent simply traverses the graph starting from the handoff node to obtain precise original information. This approach makes handoffs inherently process-independent—whether the new agent runs in the same process, another process, or another machine, as long as it can access the same graph, it can fully recover the context. This is why the article emphasizes that only "two genuinely separate processes" can prove the handoff works.

Answers Can Show Their Reasoning

The same graph can also answer company questions: who owns X? Who decided Y, and why? Who knows Z? What does this project depend on? The seed company contains 48 people, 6 teams, 8 projects, 32 documents, 48 tickets, 20 chat threads, and 8 decisions with rationales and source documents. Two design choices do most of the work:

Evidence paths are query results, not decoration. Ask why the company adopted usage-based pricing for Atlas, and the answer combines the actual chain: Project —HAS_DECISION→ Decision —MADE_BY→ Person —DOCUMENTED_IN→ Document, and the UI highlights this path in the graph visualization. The citation is the traversal itself, not a reference tacked on afterward.

Expertise is computed, not hand-written. The strength of KNOWS_ABOUT is computed at ingestion time from two inputs: seed expertise assertions in the synthetic dataset set a minimum strength for "person-topic" pairs, and artifact evidence—documents written, decisions made, tickets resolved—adds strength above that minimum; each edge retains its evidence count, including the seed assertion itself. This is why ranked answers can show why a person ranks where they do.

The third choice is the one they hold to most firmly: no LLM in the query path. A deterministic, schema-based planner resolves questions against the graph itself and compiles them into traversals. When the graph doesn't know something, the system politely returns "no evidence"—and that's intentional. A memory system that fabricates answers is worse than one that admits a gap, because you'll keep building on whatever it tells you.

A multi-hop query refers to a question that requires traversing multiple edges in a graph consecutively to answer, for example, "which document records a decision made by the project that a given person owns." The difficulty of such queries is that each step may branch, and the path length is not fixed. In the benchmark described in this article, 8 multi-hop questions are scored by evidence path length, meaning the system must not only give an answer but also return the complete sequence of nodes and edges supporting it. The core challenge for a deterministic planner that compiles questions into parameterized Cypher traversals is entity resolution—mapping names, pronouns, and references in natural language to unique nodes in the graph, then selecting the correct edge types and traversal directions according to the schema. Since the path itself is the evidence, highlighting the path in the UI is equivalent to showing the reasoning chain, with no need to generate additional explanatory text.

Measurable, Not Asserted

Everything above is verifiable, which is precisely the point of building it this way:

• 25 tests pass in the published repository; the only skips are 2 live FalkorDB integration tests that require a configured server to run—an honest way to handle a dependency you can't fake. There is also a test proving tenant isolation: one tenant's graph cannot see any of another tenant's memory.
• A frozen benchmark of 14 questions—8 of them multi-hop, scored by evidence path length—scores 14/14.
• The app runs live on a real FalkorDB Cloud instance; its /api/status endpoint reports the backend and graph size (206 nodes and 616 edges at last check), so "it's really connected to FalkorDB" is a fact you can fetch, not a claim you have to trust.
• Concurrency is stated as measured: sending 10 questions simultaneously to the live demo, 10 got answered—on free-tier hosting, median answer time is about 21 seconds. Functional, not fast, and reported honestly.

Next Steps

An MCP tool interface over the same set of traversal plans, so other agent frameworks can use this graph as a memory layer without adopting their agents. Ingestion connectors for real documents, tickets, and chat sources, backed by the same schema. And multi-team coordination on a single tenant graph—the handoff protocol is already process-independent; teams are just processes with better branding.

An Honest Footnote

The dataset is synthetic, and this is labeled everywhere it appears. AI coding assistants were used during the build, which the event rules explicitly allow; the architecture, graph schema, honesty constraints, and every verification step are the participants' own responsibility, and every claim in this article is limited to what the test suite and benchmark actually measured.

One scope note, since the code is public: the repository also ships an in-memory dev backend labeled as such, for testing and offline development. It does not hold deployment state—in the deployed system, FalkorDB is the only state store: the live deployment runs only FalkorDB, and no agent keeps state in process memory.

If your agents are passing summaries to each other, they're not collaborating—they're playing telephone. Give them a notebook they can all read. Make it a graph, and the notebook can answer—with receipts.

One-line Summary

Crew Memory Graph replaces prompt relay with a FalkorDB graph database, enabling lossless, cross-session shared memory for multi-agent systems.

Paragraph Summary

Crew Memory Graph is a multi-agent memory system built by Lusavio at the Graph Hacks hackathon, designed to solve the information loss and cross-session loss caused by agents passing context through prompt relay. Its design principle is "remove FalkorDB and nothing remains," forcing agents to be stateless and storing all state in a graph database, one per tenant. The system organizes memory into three layers: episodic, semantic, and procedural, recording events, facts, and processes respectively. The core demo is a cross-session handoff: an Executor in a new process traverses the graph to find an unfinished handoff and answer its questions, without any text being passed. No LLM is used in the query path; a deterministic planner compiles questions into Cypher traversals, and returns blank when there is no evidence. The system provides verifiable evidence through 25 tests, a 14/14 frozen benchmark, and a live status endpoint.