How I extended Genesis Agent with a FalkorDB knowledge graph and built something that actually learns across sessions.

I've been building Genesis Agent from scratch in pure Python — no LangChain, no frameworks, just the fundamentals one layer at a time.

Part 1 was the basic LLM loop. Part 2 added web search. Part 3 added URL browsing and article reading. Part 4 added LLM-as-Judge verification.

Every version had the same problem: the agent forgot everything the moment you closed the terminal.

Ask it about FalkorDB today — it searches the web, reads 3 pages, extracts facts, gives you a great answer. Ask it the same question tomorrow — it does the exact same work again. Re-fetches the same URLs. Re-extracts the same facts. Re-verifies the same claims. Complete amnesia.

For this hackathon — Graph Hacks: Context for AI Agents by WeMakeDevs × FalkorDB — I fixed that.

The wrong solution I almost built

My first instinct was a vector database. Store embeddings of everything the agent reads, do similarity search before fetching new URLs.

It would have worked. But it would have missed the point.

A vector DB finds similar content. A graph finds connected content. Those are fundamentally different things.

When the agent reads that "FalkorDB uses Cypher" and "Neo4j uses Cypher" — a vector DB sees two similar sentences. A graph sees two nodes that share a relationship edge pointing to the same concept. The second time you ask something related, the graph doesn't just find similar text — it traverses connections.

That's not a subtle difference. That's the whole point of graph memory for agents.

What I built: Genesis Agent + FalkorDB

The idea is simple. Every time the agent does something, it writes to a graph:

• Searched for a query → Query node
• Visited a URL → WebPage node, linked to the query
• Extracted a fact → Fact node, linked to the page
• Verified the fact → Verdict node, linked to the fact

(Session) -[:CONTAINED]-> (Query)
(Query)   -[:FOUND]->      (WebPage)
(WebPage) -[:MENTIONS]->   (Fact)
(Fact)    -[:VERIFIED_BY]-> (Verdict)

Every research session builds up a persistent knowledge graph. The next session inherits it.

Before every single LLM call, a Context Builder reads the graph and injects what the agent already knows into the system prompt:

## What you have already searched for:
- what is FalkorDB
- FalkorDB vs Neo4j

## Verified facts you already know:
- [0.94] FalkorDB is a graph database built on Redis (source: falkordb.com)
- [0.91] FalkorDB uses the Cypher query language (source: falkordb.com)

## Related facts from prior research:
- [0.89] Cypher is a declarative graph query language (source: neo4j.com)

The LLM sees this before making any decision. It knows what it already knows. It doesn't repeat itself.

The multi-hop query that makes it real

This is the part that actually impressed me when I saw it work.

MATCH (s:Session)-[:CONTAINED]->(q:Query)
      -[:FOUND]->(w:WebPage)
      -[:MENTIONS]->(f:Fact)
WHERE toLower($topic) CONTAINS toLower(q.text)
  AND f.verified = true
RETURN f.text, f.confidence
ORDER BY f.confidence DESC
LIMIT 5

One query. Four hops. Traverses the entire research history in milliseconds and returns only the verified, high-confidence facts relevant to the current topic.

No embeddings. No vector similarity. Pure graph traversal.

The demo that sold me on this approach

Run 1 — fresh session:

Enter session ID (or press Enter for new): [Enter]
Enter prompt: What is FalkorDB?

🆕 New session: sess_a1b2c3
🔍 Search needed — gathering context...
🌐 Browsing top 3 URLs...
   📌 [0.94] FalkorDB is a graph database built on Redis...
   📌 [0.91] FalkorDB uses Cypher query language...
   📌 [0.88] FalkorDB supports multi-graph architecture...
✅ GOAL COMPLETED
🆔 Session: sess_a1b2c3

Run 2 — same session, related question:

Enter session ID: sess_a1b2c3
Enter prompt: How does FalkorDB compare to Neo4j?

♻️  Resuming session: sess_a1b2c3
🧠 Found relevant facts in graph memory — skipping redundant search
✅ GOAL COMPLETED
Result: 1 iteration, completed: True

Second run. One iteration. No web requests. Answered from memory.

The agent didn't just remember — it used what it remembered to skip work it didn't need to do.

The key file: context_builder.py

The whole memory system comes down to 30 lines:

def build_context(session_id: str, current_query: str) -> str:
    
    prior_queries  = get_prior_queries(session_id)
    known_facts    = get_known_facts(session_id, limit=8)
    related_facts  = multihop_related_facts(session_id, current_query)

    if not prior_queries and not known_facts:
        return "No prior knowledge found. Start fresh research."

    parts = []

    if prior_queries:
        lines = "\n".join(f"- {q}" for q in prior_queries)
        parts.append(f"## What you have already searched for:\n{lines}")

    if known_facts:
        lines = "\n".join(f"- {f}" for f in known_facts)
        parts.append(f"## Verified facts you already know:\n{lines}")

    if related_facts:
        lines = "\n".join(f"- {f}" for f in related_facts)
        parts.append(f"## Related facts from prior research on '{current_query}':\n{lines}")

    return "\n\n".join(parts)

This runs before every LLM call. The LLM never makes a decision without seeing what the agent already knows. That's it. That's the whole memory system.

What was hard

1. Getting Cypher direction right

I had this query:

WHERE toLower(q.text) CONTAINS toLower($topic)

It always returned zero results. The bug: prior queries are short ("FalkorDB"), current topics are long ("What makes FalkorDB fast?"). The short string needs to be contained in the long string — not the other way around.

WHERE toLower($topic) CONTAINS toLower(q.text)  -- correct

One word swap. Took me an embarrassingly long time to catch.

2. Fallback confidence scores polluting the graph

When the LLM-as-Judge API call fails — rate limit, timeout, malformed JSON — I was defaulting to confidence = 0.5. That's "uncertain", which means those facts were being included in context injections.

The fix: fail to 0.0. A fact that couldn't be verified has zero confidence, verified = false, and gets filtered out by WHERE f.verified = true. Failures stay out of the graph context.

3. The model name mystery

Groq's free tier in India (ap-south-1) doesn't have llama-3.3-70b-versatile. I discovered this mid-build when the API kept returning model_not_found.

The fix was listing available models programmatically:

models = client.models.list()
for m in models.data:
    print(m.id)

openai/gpt-oss-120b is available and works great. Better than expected for structured JSON outputs.

RAG vs Graph — the honest comparison

I keep seeing people reach for vector DBs by default. Here's when a graph is genuinely better:

For an agent that needs to reason over what it knows — not just retrieve similar text — the graph is the right tool.

What's next

This is Part 5 of the Genesis Agent series. Part 6 will add:

• Cross-session memory: one shared graph across all users, not per-session isolation
• Agent self-reflection: the agent queries its own mistake history before acting
• Graph pruning: automatically remove low-confidence facts after N sessions

The codebase is on GitHub at github.com/recxcoder/genesis-graph.

If you're building agents and haven't tried FalkorDB yet — the free cloud tier takes 5 minutes to set up and the Python client is clean. Worth experimenting with.

Built for Graph Hacks: Context for AI Agents by WeMakeDevs × FalkorDB
by Shivam Vishwakarma — @recxcoder