Introducing Pathrule Intelligence

A memory is a record of something that was true when someone wrote it down. That is genuinely valuable, and almost everything here starts with one. It is also, on its own, the wrong thing to hand an agent.

The problem is that a memory has no shape. A paragraph a person writes routinely says several different kinds of thing at once: that something must never happen, that something else has to be verified before you are finished, and why the whole arrangement exists. Delivered as one block of prose, those three collapse into a single undifferentiated instruction: here is some text, please bear it in mind.

An agent on turn forty of a long session, weighing that paragraph against everything else in its context, has no way to know which sentence was the requirement. And it will not ask, because prose does not announce its own authority.

So memory is an input. The question is what you turn it into.

The standard answer to "which memory should the agent get" is retrieval: embed everything, find what looks relevant to the prompt, put it in the context window. It works, up to a point, and the point where it stops is worth naming precisely.

Retrieval optimises for relevance. What you actually need is importance, and the two come apart constantly. The paragraph that mentions your function name is not necessarily the paragraph that says the thing you must not do. The memory about the payment module is not necessarily the memory that would have prevented this specific mistake.

There is a second problem, which is that retrieval scales by sending more text. Find the relevant prose, send the prose. If the prose is long, send a lot of it. Nothing in that loop ever asks whether the fifteen sentences it just sent contain three that mattered.

The honest conclusion is that finding the right text is not the hard part any more. Deciding what the text means, and what should be done about it, is.

The first of the two layers is the one closest to where we started, but its scope is wider than a memory store.

Workspace Intelligence is the answer to a single question: how does this project work? Not what the files contain, which an agent reads perfectly well. The working knowledge a repository accumulates around its code. The architecture decisions and the arguments behind them. Constraints that are nowhere in the source. Verification that has to happen before something counts as done. The fix that worked the last three times this specific thing broke. Conventions nobody wrote down, procedures, contextual facts, superseded decisions, and the failures a team has already paid for once.

It is scoped to paths inside the repository, because everything true about a monorepo is not relevant to a change in one package, and a layer that ignores that becomes the problem it was built to solve.

Most importantly, it is the layer that can hold hard requirements. Two of the things it learns are not advice at all: what must not happen, and what must be verified. Those are properties of the project, and the rest of the system treats them differently from everything else.

The second layer is the one we had been missing entirely, and the one that changed how we describe the product.

Two engineers working in the same repository do not want the same thing from an agent. One wants to see options before an implementation; the other finds that friction. One expects a broad test run; the other treats that as a research project standing in for shipping. One wants the agent to proceed on a class of change; the other expects to be asked.

None of that is decoration. It is how the work gets done, it is stable over time, and today it lives entirely in the corrections you type again in every new session. You correct the same behaviour in January and you correct it again in March, because nothing between you and the agent was learning.

User Intelligence is the layer that does. It builds from what you actually say to your agents: a preference voiced once in passing waits as a candidate, said again in another session it becomes active, and one you state as a lasting way of working is active at once. Every preference is grounded in words you typed, never in what an agent wrote. It models execution preferences, decision patterns, quality expectations and collaboration style.

It models working preferences, not personal traits. You can see the words a preference rests on with pathrule me explain, keep it to one workspace or let it apply everywhere with pathrule me scope, or forget it. Project rules and required checks remain above a preference.

And it is scoped to you rather than to a repository. Open a different project and what the workspace knows changes completely. How you work does not, so it comes with you.

Putting a second authority into the system raises an obvious question, and the answer has to be stated rather than left to emerge.

Suppose User Intelligence has learned that you prefer minimal testing, and Workspace Intelligence holds a requirement that migration verification runs before completion. The check applies. It is a requirement of the project, and a personal preference for less verification is not a reason to drop it.

The general rule: Workspace Intelligence represents project truth and project requirements, and its hard requirements are hard. User Intelligence shapes collaboration, which is how the work is approached, how much is done autonomously, how it is reported back. It does not redefine what correct means.

Where the two are simply about style, your preference wins. Where the workspace states a safety or correctness requirement, that requirement stands and Pathrule says so rather than quietly resolving it in the background.

Both of those layers need something to read them, and what they contain is the most sensitive material a team has: internal decisions, incidents, the reasoning behind architecture, how individual people prefer to work.

Sending that to someone else's inference service to be understood is a hard thing to ask, and a harder thing to keep asking as the layer grows. We tried the other obvious answer, a model on the user's own machine, and took it out again: it narrowed who could run Pathrule to one kind of hardware, and the learning that mattered turned out not to need it. What Pathrule learns locally, it learns from shape, not meaning. A sentence that announces something lasting, in any of thirteen languages, is saved as you wrote it. A command that failed and a variant that passed is a lesson, saved once. A preference an agent names is kept only if every quoted word is one you actually typed. None of that asks a model what you meant, which is also why it never paraphrases you.

Being precise about what this claims matters more than the claim sounding good. Nothing on your machine runs a model. Pathrule also has cloud services: accounts, teams, billing, sync of the workspace knowledge a team chooses to share, and on a Cloud workspace a model tier that reads the prompts the phrase rules found nothing in, paid from AI Credits. And when you run Claude or Codex, that agent's own provider boundaries apply to whatever you send it, exactly as they do today. Three boundaries, not one. We do not write "nothing ever leaves your device", because it is not true and a privacy claim that is not true is worse than no claim.

What compilation does is turn narrative knowledge into structured knowledge. Not a summary: a summary is a shorter version of the same prose, and a shorter paragraph has exactly the same problem as a long one, which is that nothing in it says which sentence was a requirement.

A memory compiles into typed atoms, in eight primitives. What must not happen. What must be verified. What worked when this problem occurred. What should be preferred under a condition. How something should be done. What is true and useful here. Why it works this way. Which decision wins when two of them apply.

One document usually produces several. A memory saying environment access must go through a gateway, that this exists because direct access bypassed validation three times, and that new modules should be checked against it, is a constraint, a rationale and a check. A rule is a container; the primitive is the unit.

Two properties are preserved through all of it. The wording stays the source's: an action, a preferred choice, a procedure step is verbatim, and a person approves every atom before it carries authority. And the authority is carried explicitly, so a remedy is never rendered at the same weight as a constraint, which is exactly the flattening that made a well-delivered paragraph fail in the first place.

Selecting the atoms a task needs and compiling them into what the agent receives is pure, deterministic, and makes no model calls, which is why it is fast enough to land before the first tool call and why what arrived is reproducible rather than reinterpreted every turn.

This is the part of the design I would want to read first if someone else had built it, because a system that turns prose into structure can lose the part that mattered, and the failure is silent.

The concrete case: a memory says to use one helper instead of another. Compilation produces a clean, well-formed, correctly grounded atom naming the winner and drops the loser. The atom count is non-zero. Everything looks right. The agent learns what to use and never learns what to avoid, which is the entire reason someone wrote the memory.

So a non-zero atom count is explicitly not the test. Before compiled knowledge is delivered in place of the source, a gate compares the source text against the exact text the agent will receive. Not the atom's internal evidence, which can be grounded on a span that mentions the loser while the delivered projection kept only the winner. What arrives is what gets judged.

The gate has no model in it. It is deterministic, so the same source and the same delivery always produce the same decision, and it fails closed: when the compiled form does not clearly represent the source, the answer is not "probably fine", it is to deliver the source prose instead.

A smaller, tidier delivery that lost the operative clause is a worse outcome than a longer one that kept it. When Pathrule is not sure, it does not pretend.

The last architectural piece is the one that closes the loop back to the failure I started with.

Understanding what a paragraph means is work for a model. Making sure a forbidden action does not happen is not, and leaving it to one means depending on an agent weighing a sentence correctly deep into a long session, every time, forever.

So the semantic layer and the enforcement layer are separate. A constraint can be handled by the runtime rather than delivered as advice. A required check can be required rather than mentioned. Everything advisory is still advisory, and still renders subordinate to the things that are not.

This is the line between a memory product and a runtime, and it is why "we deliver the right context" was never going to be sufficient on its own.

One consequence falls out of the architecture rather than being designed for, and it is the one I would defend hardest.

None of this lives inside an agent. A memory feature inside Claude is knowledge held hostage to Claude: switch to Codex and it stays behind. Everything Workspace Intelligence and User Intelligence accumulate lives in Pathrule, and the compiled representation an agent receives is engine-neutral, rendered as plain markdown with the per-engine envelope applied afterwards by whichever channel that client supports.

There is no Claude-shaped knowledge and no Codex-shaped knowledge. So switching agents changes who executes, not what is known about the work. The agent can change. The intelligence stays.

Pathrule works through the tools you already use. The CLI sets up a repository, connects coding agents and lets you inspect and correct your working preferences with pathrule me. The VS Code extension brings the same knowledge into your editor.

For local knowledge, pathrule ui opens the Local Console in your browser. It lets you browse, search, edit and restore memories, rules and skills, inspect activity and review Local Signals. It needs no account. Pathrule Cloud has a separate console for shared workspaces, members, settings and billing.

Your coding agent still performs the coding work under its own provider account. Pathrule supplies task-scoped knowledge and checks where the client supports them.

PathruleBench gives two channels the same team knowledge, the same agent (Claude Code with claude-sonnet-5-5), the same prompts and the same hidden checks: eight sessions of four turns on a small Python, Go or TypeScript toolkit, and 26 memory probes checked by executable tests and structural checks. One channel is well-kept CLAUDE.md files. The other is the open-source Pathrule CLI in local mode, with no Cloud, no embeddings and no model. No model judges anything.

At 2,000 items of team knowledge, the same agent read 2.7 times fewer input tokens and cost about 55% less a chain with Pathrule, in all three languages, and passed more of the probes. An instruction file is read whole on every step, so from 500 to 2,000 items a Python chain went from $2.06 to $3.89 with CLAUDE.md and from $1.70 to $1.76 with Pathrule.

The reading matters more than the numbers, and it is not a criticism of the agent or of the file. What a session costs with an instruction file grows with the knowledge base. With Pathrule the root file stays around 6k characters and the rest arrives per prompt, so it stays flat.

The probes are where the two kinds of learning show. A habit stated once reached later sessions 6.3 to 7 times out of 7 with Pathrule and 4.3 to 6.7 with CLAUDE.md. A lesson a failing command taught was kept in 8 of 9 Pathrule chains in Python and in none of the CLAUDE.md chains there. A changed decision was applied 3 of 3 times in every Go condition with Pathrule, 1.7 to 2.7 with CLAUDE.md.

We publish where they tie: seeded team knowledge, decisions stated in prompts, knowing when to ask, and the whole TypeScript 500-item condition, where the memory interval includes zero. At 500 items a plain file is cheap to read and hard to beat, and we say so. The fixtures, the scenarios, the hidden checks and every chain with its token usage are at github.com/pathrule/benchmark under Apache-2.0, and the method is in how we measure.

A context layer answers the question "what should the agent receive". That is a real question and we still answer it. But it is downstream of two harder ones: what does this knowledge actually mean, and which parts of it should not have been left to the agent in the first place.

Answering those turned a delivery mechanism into a system with a lifecycle. Observe, understand, compile, enforce, verify, learn. And it made room for the second body of knowledge that was sitting in plain sight the whole time, which is not about the repository at all.

Memory is what was recorded. Knowledge is the structured understanding of it. Intelligence is the system that decides what it means and when it matters. Those are three different things, and we had been calling all of them memory.

The full architecture is at /intelligence, the technical reference is in the Intelligence docs, and both go further than this piece does.