Comparison
Pathrule vs Zep
Zep is agent memory as a temporal knowledge graph: entities, relationships and facts about a user or a subject, with each fact carrying a validity window so a contradiction closes the old one instead of erasing it. Retrieval happens when you call it. Pathrule's unit is not a subject, it is a repository path, and its delivery is not a call, it is an injection before the agent's first tool call.
What Zep is genuinely good at
Time. Every fact in Zep's Context Graph carries temporal metadata, so when new information contradicts an old fact the system closes the old one's validity window rather than deleting it. The agent reasons over the current state and the history stays queryable, which is how you answer "what was true before this changed" at all. Most memory systems cannot.
Its retrieval is a real pipeline rather than a single vector lookup, composing similarity, full-text and graph traversal with reranking, and it is served from a governed store with sub-200ms retrieval at enterprise scale. Graphiti, the temporal graph engine underneath, is open source and runs on a graph database if you self-host.
For an agent whose job is to know things about a person, an account or a case over time, that is the right architecture and Pathrule is not built for it.
Side by side
| Zep | Pathrule | |
|---|---|---|
| The unit of memory | Facts about a user or subject, as a temporal graph | Memories, rules and skills attached to a repository path |
| How knowledge arrives | `graph.search` or `thread.get_user_context`, on call | Studio injects it at hook time, before the first tool call |
| Time | Facts carry validity windows; history stays queryable | History per item, plus stale knowledge raised for review |
| Retrieval | Similarity, full-text and graph traversal, reranked | Path scope first, then semantic ranking within it |
| Constraints that can block a change | Returns context | Rules carry scope, priority and an enforcement level |
| Self-hostable open source | Graphiti, on a graph database | The core, on embedded SQLite, no infrastructure |
| Built for | Agents that must know a subject over time | Pathrule Studio and the coding agents it runs, inside a repository |
Zep claims are from its own documentation, read August 2026. If a row is wrong, tell us and we will fix it.
The two differences
A subject is who the knowledge is about. A path is where the work is.. Zep organises around the entity a fact concerns, which is exactly right when the agent's job is to know a customer. A coding agent's question is different: not who is this about, but what governs the directory I am editing. Pathrule keys on that, so the routing needs no query to resolve.
On call versus before the call. Both
graph.searchandthread.get_user_contextare things something has to invoke. Pathrule reads the working directory and injects the matching slice before the agent's first tool call, so a constraint nobody thought to look up still arrives in time to change what the agent does.
Which one you actually want
Choose Zep when the value is in what your agent knows about someone or something over time: support histories, account state, anything where the right answer depends on when it was true. The temporal model is the feature, and it is a hard one to build yourself.
Choose Pathrule when the value is in what your coding agents know about your codebase: the conventions attached to a directory, the constraint that must stop a change before it lands, and the work that follows from it. If your problem is that an agent keeps making a decision your team already made and wrote down nowhere a code scan can find, that is the problem Pathrule is shaped around.
Sources
Official product documentation reviewed August 20, 2026.
- Zep: key concepts
Official Context Graph, Context Block and retrieval model.
- Zep: facts
Official temporal validity and fact invalidation behavior.
Frequently asked questions
Is Pathrule a knowledge graph like Zep?
Pathrule does keep a knowledge graph, but it is indexed by repository path rather than by subject, and it is read by position rather than by query. Zep's graph answers what is true about an entity, and when. Pathrule's answers what governs this directory, delivered before the agent acts.
Does Pathrule track when a fact stopped being true?
Not with validity windows the way Zep does. What Pathrule does instead is raise knowledge that has drifted or stopped matching anything as a proposed edit for you to approve, so the correction happens deliberately rather than accumulating silently. If temporal reasoning over facts is your core requirement, Zep is built for that and Pathrule is not.
Can I use both?
Yes, and they do not overlap much. Zep for what your product's agents know about people and accounts, Pathrule for what your coding agents know about the repository they are editing.
Both are partly open source. What is the difference in practice?
Graphiti, Zep's temporal graph engine, is open source and expects a graph database when self-hosted. Pathrule's open core runs the whole loop on embedded SQLite with no account, no Docker and no network, which is a different tradeoff: less infrastructure, no temporal graph.