Crew Memory Graph 以 FalkorDB 圖取代提示詞傳遞多智能體上下文

Every multi-agent system has the same plumbing problem hiding under the demo: the
agents pass context to each other through prompts.

One agent researches and produces a summary. The summary is pasted into the next
agent's prompt. That agent adds its part and pastes a longer summary onward. It
works — for exactly one session, at exactly demo scale. The context is long, it is
lossy (every hop summarizes the last hop), and it evaporates the moment the process
ends. Start a new session tomorrow and the crew knows nothing.

For Graph Hacks — WeMakeDevs' hackathon built around FalkorDB as the context layer
for AI agents — Lusavio built Crew Memory Graph: a three-agent crew (Planner,
Researcher, Executor) whose shared notebook is a graph.

The removal test

The event's central requirement is that FalkorDB be load-bearing, not decorative.
We turned that into a design rule before writing any code:

Remove FalkorDB, and nothing should remain.

No memory between sessions. No shared state between agents. No company knowledge.
No answers. That rule forced an honest architecture: agents are stateless by
design. In deployment, all state — everything the crew learns, plans, decides, and hands off — lives in exactly one place: one FalkorDB graph per tenant, accessed only through parameterized Cypher traversals.

Three layers, one graph

Memory in Crew Memory Graph is organized the way the Track 02 brief asks for it:

• Episodic — what happened. Sessions, episodes, and handoffs, in order, each write carrying provenance: which agent, which session, when, from what source.
• Semantic — what is true. The company itself: people, teams, projects, documents, tickets, decisions, topics, chat threads — plus every fact the crew learns along the way, linked to the entities it concerns.
• Procedural — how we do things. Plans and workflows stored as step graphs, so a plan one agent writes is a structure another agent can execute, not a paragraph it has to interpret.

The demo company, Meridian Labs, is fully synthetic — procedurally generated from
a fixed seed around a hand-fixed core, and labeled synthetic in the UI. That
matters: every question has exact, checkable ground truth. The demo is not
impressive because the answers sound good; it is verifiable because the answers
are right or wrong against a known graph.

The handoff is the demo

The centerpiece is a two-session handoff.

In Session 1, the Researcher is taught a launch briefing for the Beacon Mobile
App — a launch date, a beta cohort size, a blocker. The Planner converts that
briefing into a step plan and files a handoff to the Executor. The handoff does
not contain the briefing. It references the exact memory nodes. Nothing is passed
agent-to-agent as text, because there is nothing to pass — there is only the graph.

In Session 2, a fresh Executor starts. A different process, an empty context.
It finds its open handoffs by traversal, follows their REFERENCES edges to the
memory Session 1 wrote, and answers the handoff's question — when is the Beacon
launch, and how large is the beta cohort? — from memory it never saw written.
Then it performs the next plan step and closes the handoff, writing its own
results back as new episodes.

The same flow runs headless, as two genuinely separate processes — because a
handoff that only works inside one process is not a handoff. It is a variable.

Answers that show their work

The same graph answers company questions: who owns X? who decided Y, and why? who
knows Z? what does this project depend on? The seeded company carries 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 the heavy lifting:

1. Evidence paths are query results, not decorations. Ask why the company adopted usage-based pricing for Atlas and the answer composes the actual chain — Project —HAS_DECISION→ Decision —MADE_BY→ Person —DOCUMENTED_IN→ Document — and the UI highlights that path in the graph visualization. The citation is the traversal.
2. Expertise is computed, not hand-written. KNOWS_ABOUT strength is computed at ingest from two inputs: seed expertise assertions in the synthetic dataset set a minimum floor for a person–topic pair, and artifact evidence — documents authored, decisions made, and tickets resolved — adds strength on top of that floor; each edge keeps its evidence count, including the seed assertion itself. That is why a ranked answer can show why a name ranks.

And a third choice, the one we are most stubborn about: there is no LLM in the
query path. A deterministic, pattern-based planner resolves questions against
the graph's own entities and compiles them into traversals. When the graph does
not know something, the system returns a graceful "no evidence" — on purpose. A
memory system that invents answers is worse than one that admits a gap, because
you will build on whatever it tells you.

Measured, not asserted

Everything above is checkable, which was the point of building it this way:

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

What comes next

An MCP tool surface over the same traversal plans, so other agent frameworks can
use the graph as their memory layer without adopting our agents. Ingestion
connectors for real document, ticket, and chat sources behind the same schema.
And multi-crew coordination on one tenant graph — the handoff protocol is already
process-agnostic; crews are just processes with better branding.

The honest footnotes

The dataset is synthetic and says so everywhere it appears. The build was made
with an AI coding assistant, which the event rules expressly allow; the
architecture, the graph schema, the honesty constraints, and every verification
step are the entrant's own responsibility, and every claim in this post is limited
to what the test suite and benchmark actually measure.

One scoping note, because the code is public: the repository also ships a labeled
in-memory development backend used for tests and offline development. It holds
no deployed state — in the deployed system, FalkorDB is the only state store:
the live deployment runs FalkorDB only, and no agent keeps state in process
memory.

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

Try it: https://crew-memory-graph.onrender.com
Code (MIT): https://github.com/AI-conn/crew-memory-graph
Demo video: https://www.youtube.com/watch?v=s3ceR7nJKyY
Entered in Graph Hacks — Track 02 (Agent Memory and Coordination) and Track 03
(Company Brain). By Lusavio.