Pathrule vs Supermemory: A Memory API Answers When Asked
Two products that both store what your team knows, with opposite assumptions about when that knowledge should show up.
Short answer
Both store team knowledge, with semantic recall, team sync and an open self-hostable core. The difference is delivery timing. A memory API answers when it is queried; a path-scoped layer reads the path an agent is about to work on and delivers before the first tool call. An agent rarely asks about a constraint it does not know exists.
What this covers
- Pathrule works the other way round: its path-indexed context layer reads the path an agent is working on and delivers the memories, rules and skills that govern that path before the first tool call, without waiting to be queried.
- The difference is delivery timing, and it decides the failure mode. An agent that does not think to ask gets nothing from a memory API, and an agent rarely thinks to ask about a constraint it does not know exists.
- Rules are the second difference. A memory API returns text; it does not carry scope and priority or gate work. A rule in Pathrule has a scope, a priority and an enforcement level, so a strict rule can stop a matching change before it lands.
- The third difference is that Pathrule stays with the work after delivery: branches, task cards with prepared context, design handoff and runtime incidents mapped back to code, none of which a memory API attempts.
- Claims are dated August 2026 and taken from what each product publishes.
Comparison
| Capability | Pathrule | Supermemory |
|---|---|---|
| Semantic recall across what you wrote | Yes | Yes |
| Team sync without a commit | Yes | Yes |
| Open core, self-hostable | Yes | Yes |
| Stale knowledge flagged, refreshed on your approval | Yes | Partial |
| Works with every engine you run | Yes | Partial |
| Scoped to the path you are editing | Yes | No |
| Arrives before the first tool call | Yes | No |
| Rules that gate the work, with scope and priority | Yes | No |
| Parallel agents in isolated checkouts | Yes | No |
| Tasks that arrive with their context prepared | Yes | No |
| Runtime incidents mapped back to code and tasks | Yes | No |
Before and after
| Area | Retrieval, waiting to be asked | Path-scoped delivery, arriving first |
|---|---|---|
| The agent opens a checkout file | Nothing happens until it queries | The rule governing that path is already in the turn |
| A constraint the agent does not know exists | Never retrieved, because nothing prompted the query | Delivered, because the path carries it |
| A strict constraint | Returned as text, if asked | Enforced: a matching change is stopped before it lands |
| Twenty files touched | Twenty chances to forget to ask | The slice for each path, each time |
What Supermemory is good at
Supermemory is a memory API. You write things into it and it gives them back when something asks, with semantic search over what you stored. It syncs across a team without going through your repository, and it has an open core you can self-host.
Those are real strengths and this comparison does not dispute any of them. If what you need is a place to put text that an application can query later, a memory API is the right shape and Supermemory is a good one.
The difference is when knowledge shows up
A memory API answers when it is asked. That single property decides its failure mode, and the failure mode is not obvious until you have watched it.
An agent asks about things it knows to wonder about. It does not ask about the constraint it has never heard of, because there is nothing to prompt the question. So the knowledge most worth having, the rule that would have prevented the mistake, is exactly the knowledge least likely to be retrieved.
Pathrule reads the path the agent is about to work on and delivers the memories, rules and skills that govern that path before the first tool call. There is no query, so there is no missed query. The agent that opens the checkout file receives the coupon rule whether or not it thought to look for one.
A rule is not a memory
The second difference is the object model. A memory API stores text and returns text. Pathrule distinguishes three kinds of knowledge, and one of them is not passive.
A memory records something worth remembering. A skill packages a procedure. A rule carries a scope, a priority and an enforcement level, which means a strict rule does not merely inform the agent; it can stop a matching change before it lands.
That distinction is what lets a team encode a constraint they actually care about, rather than hoping the retrieved paragraph is persuasive enough.
And what happens after delivery
A memory API's job ends when it returns the text. Pathrule stays with the work: a session can take its own branch and checkout, a task card arrives with its context already prepared, a design hands off carrying your token names and component paths, and a runtime incident maps back to the code and rules that touch it and then reports whether the fix held.
None of that is a criticism of Supermemory, which is not trying to do it. It is the reason the two products end up in different categories despite both being places your team's knowledge lives.
Every claim here is dated August 2026 and taken from what each product publishes. If something is out of date, [email protected] and it will be corrected.