DEV Community: Manoj Kumar Gogula

Five Cypher patterns I keep reaching for when building agent memory

Manoj Kumar Gogula — Fri, 11 Sep 2026 09:30:08 +0000

Cypher is easy to read and surprisingly easy to write badly. The syntax is so close to plain English that your first few queries work, and then one of them quietly returns 40,000 rows because you matched two unrelated patterns in the same clause.

These are the five patterns I keep coming back to when the graph is backing an agent's memory. Nothing exotic — just the ones that saved me the most time. All of them run on any Bolt/Cypher endpoint.

1. MERGE for writes you'll run more than once

Agents re-observe the same facts constantly. The same entity gets extracted from three different documents, the same relationship gets inferred twice. If you CREATE, you get duplicates; if you check-then-insert, you get a race.

MERGE matches or creates in one atomic step:

MERGE (p:Person {id: $person_id})
  ON CREATE SET p.name = $name, p.first_seen = timestamp()
  ON MATCH  SET p.last_seen = timestamp()

The important and frequently-missed detail: MERGE matches on the entire pattern you give it. MERGE (p:Person {id: $id, name: $name}) will create a second node when the name changes, because the pattern no longer matches. Merge on the identifying property only, then SET the rest. And put a uniqueness constraint on that property before you rely on any of this — without one, concurrent merges can still both create.

2. Bounded variable-length paths

"What does this depend on, transitively?" is one line:

MATCH path = (s:Service {name: $name})-[:DEPENDS_ON*1..4]->(dep)
RETURN DISTINCT dep.name AS name, min(length(path)) AS distance
ORDER BY distance

Note the upper bound. Writing * or *1.. unbounded on a well-connected graph is how you hang a query — in a social-ish graph almost everything is reachable within six hops, so an unbounded traversal degrades into "scan the graph." Pick a real depth. If you don't know it, start at 3 and measure.

DISTINCT matters too: multiple paths reach the same node, and without it you'll return the same dependency once per route.

3. OPTIONAL MATCH instead of a second round trip

The reflex from SQL is a LEFT JOIN; the reflex from ORMs is a second query. Cypher lets you attach the optional part inline, so a node with no attachments still comes back:

MATCH (d:Document {id: $doc_id})
OPTIONAL MATCH (d)<-[:AUTHORED]-(author:Person)
OPTIONAL MATCH (d)-[:CITES]->(cited:Document)
RETURN d.title AS title,
       collect(DISTINCT author.name) AS authors,
       collect(DISTINCT cited.title) AS citations

A plain MATCH here would drop the document entirely if it happened to have no citations, which is the kind of bug that only shows up on the one record your demo uses.

4. The neighbourhood fetch

This is the query that actually feeds the model. Resolve the entities in the question, walk out a fixed radius, return the subgraph — and nothing else:

MATCH (seed) WHERE seed.id IN $seed_ids
MATCH path = (seed)-[*1..2]-(neighbour)
WITH collect(DISTINCT neighbour) AS nodes,
     collect(DISTINCT relationships(path)) AS rels
RETURN nodes, rels

The discipline here is the radius, not the syntax. Two hops is usually plenty; three often doubles the context for very little extra signal. Whatever you pick, cap the result size explicitly — one unexpectedly popular hub node can drag half the graph into your prompt, and you'd rather truncate deliberately than discover it in a token bill.

5. Provenance as an edge property

If an agent is going to act on a fact, you need to know where the fact came from. Put it on the relationship when you write it:

MATCH (a:Person {id: $a}), (b:Company {id: $b})
MERGE (a)-[r:WORKS_AT]->(b)
  ON CREATE SET r.source   = $source_doc,
                r.method   = $extraction_method,
                r.confidence = $confidence,
                r.asserted_at = timestamp()

Then a retrieval query can return the path and its justification together:

MATCH path = (a:Person {id: $a})-[:WORKS_AT]->(c:Company)
RETURN c.name AS company,
       [rel IN relationships(path) | rel.source] AS sources

No separate audit table, no reconstructing the reasoning by hand. "Why do you believe this?" becomes a column.

The mistake behind most slow queries

Worth stating plainly, because it caught me more than once: two unconnected patterns in the same MATCH produce a cartesian product.

-- accidental: every Person paired with every Company
MATCH (p:Person), (c:Company)
RETURN p, c

That's every Person times every Company. Either connect the patterns with a relationship, or split them across WITH boundaries. Most engines will warn you; read the warning.

And always run EXPLAIN or PROFILE before you blame the database. PROFILE shows rows per operator, and the culprit is usually an unindexed label scan sitting at the bottom.

Trying these somewhere

All of the above is standard Cypher, so it runs against any Bolt endpoint. I've been using CognoDB for prototypes because the official Neo4j drivers connect unchanged (Bolt 5.0–5.4, one-line URI change) and the free tier comes up in about a minute with no card — which is the difference between trying a graph idea on a Tuesday evening and not trying it.

Full disclosure: I work on CognoDB. The patterns aren't specific to it, and I'd rather you learn Cypher on whatever endpoint is closest to hand.

What did I miss?

I'm genuinely curious about the ones I haven't internalised yet — especially around modelling time-varying relationships and pruning stale agent memory, which I still don't have a clean pattern for. If you've solved either, I'd like to read it.

When an agent's question is a path, not a similarity score

Manoj Kumar Gogula — Fri, 11 Sep 2026 09:23:40 +0000

Most retrieval stacks start with a vector index, and for good reason: "find me things that look like this" is the single most common question an agent asks. But a meaningful slice of agent questions aren't about similarity at all. They're about connection — what depends on this, who touched it, how did we get from A to B. Cosine distance has no concept of an edge, so it cannot answer those. A relational store can, but you pay for it with a join per relationship type and a recursive CTE tuned per query.

This post is about that second class of question, and what changes when you model it as a graph.

Depth as a parameter

Suppose an agent has to answer "what depends on service X?" You don't know the depth in advance. It might be two hops today and five after the next deploy. In Cypher the depth is just part of the pattern:

MATCH path = (s:Service {name: $name})<-[:DEPENDS_ON*1..5]-(dependent)
RETURN DISTINCT dependent.name AS name, length(path) AS hops
ORDER BY hops

The same question in SQL means a recursive CTE, a termination condition you have to get right, and a rewrite every time someone adds a new kind of relationship. The graph version doesn't change shape when the schema grows — typed edges are the data model, so a new relationship type is data, not a migration.

Retrieval bounded by neighbourhood, not by corpus

The usual RAG failure mode is stuffing everything plausibly relevant into the prompt and hoping the model sorts it out. Graph retrieval inverts that: resolve the entities in the question, walk out a couple of hops, and send only that.

The difference is easy to underestimate. On a 3,700-entity knowledge base, dumping every node and edge rendered to 202,285 tokens per query; fetching the two-hop neighbourhood around the query entities rendered to 2,668. Same text, same tokenizer (GPT-4 cl100k_base). The gap widens with scale, and that's the actual point — baseline tokens grow with the corpus, while neighbourhood retrieval stays bounded by the neighbourhood.

The path is the explanation

The part I find most underrated: when you traverse for the answer, you get the justification in the same result set. A vector hit gives you a score and no account of itself. A graph query returns the route it took, and provenance can live on the edge as a property, so "why do you believe this?" is answerable without a separate audit table.

That matters a lot once an agent is allowed to act on what it retrieved.

Where this doesn't apply

It's not graph versus vectors. Similarity search is still the right tool for fuzzy recall over unstructured text, and most real systems end up using both: embeddings to find the entry points, traversal to assemble grounded context around them. If your data has no meaningful relationships, a graph buys you nothing but a new thing to operate.

Trying it without standing up a cluster

This is the part that used to stop me from prototyping graph ideas. CognoDB is a managed graph database that speaks Bolt 5.0–5.4 and Cypher, so the official Neo4j drivers connect unchanged — migration is a one-line URI change:

from neo4j import GraphDatabase

driver = GraphDatabase.driver(
    "bolt+s://db-7f3a2c1e.databases.cognodb.cloud",
    auth=("cognodb", DB_PASSWORD),
)

with driver.session() as session:
    result = session.run(
        "MATCH (p:Person)-[:FOLLOWS]->(f) "
        "WHERE p.name = $name RETURN f.name AS name",
        name="Ada",
    )
    for record in result:
        print(record["name"])

There's a free tier with no card, plus a built-in MCP server if you want an agent querying the graph directly. Published benchmark numbers (0.27 ms two-hop p95, ~74K read queries/s, ~80 bytes per edge on disk) come with full methodology on the site rather than as round marketing figures — worth reading the footnotes before you trust any vendor's graph benchmark, including ours.

If you're new to this, the concepts explainers on graphs, Cypher and GraphRAG are short and run on the free tier.

Over to you

What are you using for agent memory right now — vectors, a relational store, something hand-rolled? And if you've tried traversal-based retrieval, did the token savings hold up in production or did prompt-stuffing creep back in? I'd genuinely like to hear where this breaks.

We'll be posting more under #cognodb: Cypher patterns, GraphRAG walkthroughs, and honest benchmark write-ups. Questions welcome in the comments.