Category
Persistent memory for AI coding agents
AI agent memory is the knowledge an agent keeps once a session ends. For a coding agent the useful kind is project memory: the decisions, gotchas and conventions a team has learned, attached to the paths they govern, delivered before the first tool call. Pathrule stores that memory and routes it; Pathrule Studio is the workspace built on top of it.
The knowledge an AI agent can use in a session it did not learn it in. For a coding agent that means project memory: decisions, gotchas, postmortems and conventions that are not stated anywhere in the source, stored outside the agent and delivered back when work happens near the code they apply to.
It is not the context window, which is per session and is lost on compaction. It is not a repository index, which can only return what the files already say. It is the layer that carries what the team learned, so the next session starts from it instead of rediscovering it.
Why coding agents forget
A coding agent's working knowledge lives in its context window, and a context window is a session-length object. Close the session, or let it compact under pressure, and everything that was reasoned out inside it is gone. The next session opens on the same repository with none of it.
This is not a model weakness, and reading more of the repository does not fix it. What gets lost is the half that was never written into the repository in the first place: that the orders.status enum needs its data migration run before the schema migration, and that the order is reversed from everywhere else in the schema. The files state the current shape. They do not state which way round to change it, or that someone already got it wrong. Long read: why AI coding assistants forget your codebase between sessions.
What is actually lost
Decisions and their reasons. Why this repository uses the client directly rather than an ORM. The code shows the choice, never the argument, so the next session is free to argue the other way.
The gotcha that cost a day. The migration that has to run in the reverse order, the flag that is still required because of an upstream quirk. Nothing in the file marks it.
What was already tried. The approach that looked right and did not work. Without it the agent proposes it again, plausibly, and someone spends the review cycle a second time.
Whatever the other agent learned. Teach Claude Code something and Codex does not know it. Each one reads a different file, and neither reads the other's.
Why conversational memory is not enough for code
Memory built for a chat product optimises for a person: preferences, recurring topics, who you are. That is the wrong unit for a codebase. A repository has hundreds of directories, and a fact that is load-bearing in one of them is noise in the rest. Memory that is scoped to a user rather than a path either arrives everywhere or arrives nowhere.
The second difference is timing. A memory store you have to query answers when it is asked. An agent that never thought to ask about the coupon convention never receives it, and the miss is silent: there is no error, just a confident change that is wrong in the way the team already knows about.
Conversational memory vs project memory
| Memory built for a chat product | Project memory for a coding agent |
|---|---|
| Scoped to a person and their preferences. | Scoped to a path, so a rule for `/services/billing` stays out of `/apps/mobile`. |
| Recalled when something queries it. | Delivered before the first tool call, whether or not the agent would have asked. |
| Private to the account that built it up. | Shared across the team, with membership enforced server-side. |
| Grows into one undifferentiated pile. | Typed as memories, rules and skills, each with its own job and its own review trail. |
| Lives inside one product. Switching tools resets it. | Lives outside every agent, so changing agent does not reset the team. |
The distinction in full: what a context layer is and how it differs from a memory API.
What project memory has to do to be worth having
Survive the session. Written down outside the agent, so compaction, a restart or a new machine does not touch it.
Arrive without being asked. Read the path the agent is about to work in and deliver the matching knowledge up front. Retrieval that waits for a query only helps an agent that already suspects what it is missing.
Stay scoped. A repository's knowledge is not uniform. Attaching each entry to a path is what keeps the slice small enough to be read and specific enough to be followed.
Be reviewable. Team knowledge goes stale. If nobody can see what is stored, nobody can correct it, and an agent confidently applying last quarter's convention is worse than one that knows nothing.
Outlive the tool. Agents change faster than codebases. Memory that lives inside one agent has to be rebuilt every time the team switches.
Where agent memory can live
| Where it lives | What it holds well | Who else sees it | When it arrives |
|---|---|---|---|
| The context window | Whatever this session worked out | Nobody | Already there, until it is compacted away |
| An instruction file | Repository-wide constants | Anyone with push access | Every turn, all of it, every directory |
| A memory API | Facts your own product stores and recalls | Whatever you build on top | When something queries it |
| A vector index of the repository | Text that is written down somewhere | Anyone who can query the index | When something queries it |
| A path-scoped context layer | Decisions that are in no file, keyed to the path they govern | The team, by membership | Before the first tool call, scoped to the path |
These are not all competitors. A memory API inside your own product and project memory for your agents can both be true at once. The five approaches and where each one breaks are set out on the category hub.
Memory is one of three things a team writes down
What is true here
Short notes on decisions, gotchas and conventions, attached to the path where they apply. Reach for one when the knowledge is not obvious from the code and will come up again. Writing memories.
What must not happen
Constraints with a scope, a priority and an enforcement level. A memory is weighed; a strict rule can block a violating change before it lands. Rules for AI coding agents.
How a job is done
Named procedures the agent invokes instead of re-deriving the steps. Reach for one past three steps or any required order. Skills for AI coding agents.
Fact, constraint, procedure
If it depends on the situation it is a memory. If it is non-negotiable it is a rule. If it is a sequence someone keeps walking through it is a skill. Long read: three kinds of team knowledge.
How Pathrule stores and delivers it
Pathrule keeps memories in a path-indexed graph that mirrors the repository's folder structure, and delivers the matching subtree at hook time, before the first tool call. A memory written at /apps/web surfaces when the agent is working under apps/web and stays out of the way everywhere else.
Around the written entries sits a derived layer nobody types, built from the entries themselves plus what each run reported about itself, never from reading the repository. It is what separates a context layer from a folder of markdown files: a directory does not know what was delivered, what the agent actually consulted, or which task type it is answering. What Pathrule computes is the full account.
Path scope. Every memory is attached to a path. Scope is a fact about relevance where similarity is a guess about it.
Delivered, not queried. Pathrule runs at the hook points the agent already exposes, on every turn. How hooks work.
Ranked by measured use. Weights are learned per kind of work, from which entries a run actually consulted rather than merely received. They reorder candidates and cannot lift one past the relevance bar. How retrieval works.
Versioned and reviewable. Each save carries a version token, so concurrent edits conflict cleanly instead of clobbering. The self-audit surfaces stale entries as suggestions; your assistant drafts the fix and you approve it.
One store, every agent. The memory an agent writes over MCP is the one a teammate reads in the UI. No private cache, no parallel store.
No source code. Pathrule never reads, scans or uploads source files. Only the typed memories, rules and skills the team writes. See Security.
Which agents receive it
Studio runs Claude Code, Codex, Grok, Kimi, Antigravity and OpenCode natively and switches between them mid-workspace, with the same memories following the work. Cursor, Windsurf and GitHub Copilot connect through Pathrule CLI. The full matrix of which surface runs what is on the products page.
Frequently asked questions
What is AI agent memory?
The knowledge an AI agent can use in a session it did not learn it in. For a coding agent the useful kind is project memory: decisions, gotchas and conventions that are stated nowhere in the source, stored outside the agent and delivered back when work happens near the code they govern.
Why do AI coding agents forget between sessions?
Because their working knowledge lives in the context window, which is a session-length object. Closing a session or compacting it discards everything reasoned out inside it. Nothing about the model fixes this: the knowledge has to be stored outside the agent to come back. Long read: why AI coding assistants forget your codebase between sessions.
Is a memory API the same as memory for a coding agent?
No, and the difference is delivery timing. A memory API answers when it is queried, which works when you own the call site inside your own product. A coding agent does not know what it is missing, so a constraint it never thought to ask about never arrives. Project memory reads the path the agent is about to work in and delivers the matching knowledge before the first tool call.
Can I not just put everything in CLAUDE.md?
For one person, one repository and one agent, yes, and that is the right answer. It breaks at the second person or the second agent: the file ships in full on every turn regardless of the directory being worked in, each tool reads a different file, and long instruction files lose their hold on the model as they grow. Side by side: Pathrule vs CLAUDE.md.
How is this different from vector search over my repository?
They answer different questions. An index over your repository can tell the agent what the code currently says, which is useful when the answer exists but nobody remembers where. It has nothing to return for a decision that was made in a review and written down nowhere, and that is most of what project memory holds. The two coexist: retrieval over the files, memory over the reasoning. Long-form: vector RAG vs path-scoped context.
Does team memory mean my whole team sees everything?
Membership decides. Memories, rules and skills live in a shared path-indexed graph with row-level security and per-node overrides, all enforced server-side rather than in the client. See roles and permissions.
Does agent memory mean uploading my source code?
It does not have to, and with Pathrule it does not. Pathrule never reads, scans or uploads source files. The cloud stores only the typed memories, rules and skills your team writes, plus the structural information needed to deliver them to the right path. Full breakdown on the Security page.
What happens to my memory when I change coding agent?
Nothing, which is the point of storing it outside the agent. The same memories drive every agent Studio runs and every client connected through the CLI or MCP, so switching agent does not reset what the team has written down. Long read: team memory should not change when AI tools do.
Do I need agent memory if I work alone?
You still forget, and so does the agent. Solo, the thing memory buys you is not sharing, it is the version of yourself from four months ago: the reason you rejected an approach, which you will otherwise re-litigate with an agent that has no idea it was ever settled. It compounds further if you run more than one agent, since none of them can read another's notes. Pathrule is free for individual use. Which approach fits covers when it is genuinely overkill.