How LocusGraph remembers

An agent reviews user-service.ts and spots email logic tangled into the user code. It suggests pulling it out into an EmailService. Good call.

The next day it reviews notification-service.ts. Same tangle, same fix, worked out from scratch. Nothing about the first review survived. The agent didn't get worse overnight. It just never kept anything.

This post is about how LocusGraph fixes it: what a memory looks like inside it, how memories link up, and what stops the store from turning into a junk drawer.

A memory has a shape

The easy way to give an agent memory is to save what it said. You end up with something like this:

{
  "memory": "Reviewed user-service.ts, found separation of concerns issue, suggested EmailService"
}

That is a sentence in a box. To use it later, the agent has to find it, read it again and guess what mattered.

LocusGraph stores the parts instead. The file. The problem it found. The fix it suggested and why. Each part is a node, and the links between them say how they relate:

{
  "type": "code_review",
  "entity": "user-service.ts",
  "pattern": "separation_of_concerns_violation",
  "suggestion": { "type": "extract_service", "target": "EmailService" },
  "relationships": [
    { "to": "EmailService", "type": "suggested_creation" },
    { "to": "separation_of_concerns_violation", "type": "exemplifies" }
  ]
}

The exact fields here are only an illustration. The point is that the memory has handles. The agent can grab "separation of concerns" without rereading every review that mentions it.

What goes in is what an agent learns on the job: skills it worked out, decisions it made, mistakes it shouldn't repeat.

Memories link up

One review is a note. Twelve reviews that all point at the same pattern are a lesson.

Because each memory links to the patterns and files it touches, they cluster. The review of user-service.ts and the review of notification-service.ts both point at the same pattern node. If a later run notes that those tangled services were also the hardest to test, that outcome links in too.

Now the agent can follow the links: this pattern, seen here and here, led to that. Nobody wrote "tangled services are hard to test" down as a rule. The graph holds it because the pieces sit next to each other.

A diary keeps events in the order they happened. A graph keeps them next to what they are about. Agents need the second kind.

Not everything gets in

Most of what an agent produces is scaffolding: half-plans, retries, chatter between tool calls. Store all of it and you have a transcript, not a memory.

LocusGraph puts an admission gate in front of the store. A candidate memory has to earn its place before it is written. The gate has no dependencies of its own, so it runs the same everywhere and is easy to test.

Memories fade unless they're used

A store that only grows gets worse. The more it holds, the more stale results crowd out the good ones.

So memories decay. One that never gets recalled fades. One that keeps proving useful gets promoted and becomes easier to reach. A planner decides which is which. It is pure logic with no I/O, which means you can test its decisions without a database.

Recall is a walk, not a lookup

The common way to recall is to embed the question and pull the nearest few vectors. That finds text that sounds like the question. It doesn't find what is connected to it.

LocusGraph starts from the nearest memories and then walks the graph: from the review to the pattern, from the pattern to the other reviews, from those to what happened next. The walk has a budget, so it stops before it drags in half the graph. The agent gets the few memories that matter, joined up, instead of a pile of near-matches.

Read before, write after

The loop is simple. Before it acts, the agent reads from the graph. After it acts, it writes back what it learned. The next session opens with yesterday's lessons instead of a blank page.

That loop only works if memory lives somewhere stable. LocusGraph has one core with no platform code in it, and adapters around it: Cloudflare Workers with D1 and Vectorize on one side, Postgres with pgvector on the other. Same engine, same rules, wherever the agent runs.

What it changes

An agent that has done a hundred reviews should know more than one that has done its first. Without memory, it doesn't. Every agent is on its first day, forever.

LocusGraph is my answer to that. Memory also opens two more questions: when did the agent learn this, which is Temporal Chain, and what did it cost, which is SpendGraph.

An agent that forgets can't be held to anything. One that remembers can.

The docs cover the API and how to run it.