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 do: instructions you give, corrections you repeat, approaches you accept and the ones you send back, decisions you make in Studio. It models execution preferences, decision patterns, quality expectations and collaboration style.

It does not model you. There is nothing in it about who you are, and the unit is always a working preference about how software work should be done, which is to say something you could have said out loud. A single event is an observation. Several that agree are a pattern. Only a pattern with enough evidence becomes something that shapes how an agent works, and it keeps the evidence that got it there so you can argue with it.

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. So Pathrule Intelligence runs a model on your own device. It is installed once under your Pathrule home directory and shared by Studio and the CLI, so both surfaces drive the same install rather than each keeping a copy. It loads on demand and unloads after an idle window. A bundle is activated only after its bytes match a signed manifest checksum, and activation is atomic, so a failed download never touches the version that works.

Being precise about what this claims matters more than the claim sounding good. Pathrule Intelligence inference runs locally. Pathrule also has cloud services: accounts, teams, billing, sync of the workspace knowledge a team chooses to share, distribution of the model bundle. 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 the local model 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 where the extractor had to paraphrase a condition, that paraphrase is flagged as one rather than presented as something your team said. 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.

The expensive part of this happens once, at write time. 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.

Everything above can run invisibly, and most of the time it does. But a layer that has spent months learning about your project and how you work is a strange thing to only ever talk to through an agent.

Pathrule Studio is where you work with it directly. Ask why a constraint exists and get the decision and the incident behind it rather than a reconstruction from the code. Ask what the workspace has learned about authentication. Tell it to prepare a migration without starting it. Teach it something you would rather not correct again. Look at what it has concluded about how you work, with the evidence, and change it.

What answers there is not a model with your question and nothing else. It has the workspace knowledge, your working preferences, the knowledge graph, the task board, agent state, runtime signals and the record of what actually happened on previous runs. That is the difference between an interface to an intelligence layer and another chat window.

It is also where the loop closes: a correction you make in Studio is evidence, and a correction you make repeatedly stops being an observation and becomes something future agents work from.

Twelve tasks, twenty-four runs, one agent, one pinned model. Each task ran twice from a byte-identical fresh copy of the same repository with the same prompt, which contained no hints, and each hid a project convention that a code scan cannot surface. The scoring script was written and frozen before any run.

Without Pathrule: twelve of twelve functionally correct, three of twelve compliant with the project's own conventions, eight violations. With Pathrule: twelve of twelve functionally correct, twelve of twelve compliant, zero violations. Identical tool-call totals.

The reading matters more than the numbers, and it is not a criticism of the agent. Claude could complete the tasks either way. What changed was whether it completed them according to what the workspace already knew. The knowledge existed the whole time; the difference is whether it reached the work.

Three of the twelve did not discriminate, and we report them rather than dropping them: in those, the convention was recoverable from the repository itself, so both conditions were compliant. They mark the boundary of the effect honestly. Pathrule changes the outcome when the knowledge is genuinely not in the code.

Separately, the compiled task-scoped delivery of a narrative memory measured roughly 104 to 234 tokens where the same knowledge as prose took about 3,000: a 13 to 30 times smaller knowledge payload. The same measurement found that this did not reduce the agent's total token usage, and we publish that alongside it. It is a knowledge-payload figure. We do not claim a token saving, because when we measured one, there was not one.

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.