A persistent intelligence layer for you, your workspace, and every coding agent you use.

A coding agent is extremely capable and almost entirely new to your work. It reads the code in front of it and reasons well about what it sees. What it cannot see is the decision that was argued out six months ago, the constraint that exists because of an incident, the fix that worked the last three times this broke, or the fact that you have corrected the same behaviour in it four times already.

That knowledge is not missing. It is just somewhere a session cannot reach: in a closed conversation, in a pull request comment, in someone's head. So each session rediscovers, re-asks, or quietly does the reasonable thing that your project decided against a year ago.

Writing it all into one instruction file moves the problem rather than solving it. The file grows, the relevant three sentences compete with two hundred irrelevant ones, and nothing in it knows which of its own paragraphs mattered for the task at hand.

Workspace Intelligence is the answer to how does this project work. Not the files, which the agent can already read, but the working knowledge a repository accumulates around them.

Architecture decisions and the reasoning behind them. Constraints that are not visible in the code. Verification that has to happen before something is called done. Fixes that worked when a specific problem appeared. Conventions, procedures, contextual facts, preferred implementations, decisions that superseded earlier ones, and the recurring failures a team has already paid for once.

It stays with the workspace rather than with the session that discovered it, and it is scoped to the path it belongs to, so work in one part of a repository is not weighed down by everything true elsewhere in it.

Workspace Intelligence is only half the picture. Two engineers working in the same repository do not want the same thing from an agent, and the difference is not decoration. It is how much autonomy the agent should take, when it should stop and offer options, how much verification counts as enough, and which trade-off you make when two reasonable designs are available.

User Intelligence is the answer to how do you work. It builds from what you actually do: the instructions you give, the corrections you repeat, the approaches you accept and the ones you send back, the decisions you make in Studio.

It is yours rather than the repository's, so it comes with you when you move to a different project. What your workspace knows changes when you switch repositories. How you work does not.

Your workspace is understood where it lives. Pathrule Intelligence runs a model on your own machine, installed once and shared by Studio and the CLI, and that is what reads your knowledge and works out what it means.

This is the part that would otherwise require sending your team's decisions, incidents and internal reasoning to someone else's inference service in order to have them understood. It does not. The interpretation, the structuring and the compilation all happen locally.

Pathrule still has cloud services around that: accounts, teams, billing, workspace sync for the knowledge you choose to share, and distribution of the model itself. And when you run Claude, Codex or any other agent, that agent's own provider boundaries apply to what you send it, exactly as they do today. Those are three separate things, and the security page keeps them separate.

A memory is a record of something that was true when it was written. That is worth having, and it is where most of this starts. It is not the thing an agent should receive.

Memory is what was recorded. Intelligence is knowing what matters now. Between the two sits a step most memory systems skip: understanding what a written paragraph actually means for the work, in a form that survives being delivered.

So memories, rules, corrections, sessions and runtime evidence are sources. What comes out of them is structured knowledge, and what reaches an agent is the part of that knowledge the task in front of it needs.

The common approach is retrieval: find the prose that looks relevant, put it in the prompt, hope the model reads the right sentence. It treats knowledge as text to be located, and it scales by sending more text.

Pathrule's path is different. Narrative knowledge is understood once, at write time, into structured knowledge. For a given task, the relevant part of that structure is selected and compiled into a compact representation, the Agent IR, and that is what the agent receives. Nothing is interpreted at delivery time: compilation is deterministic and makes no model calls.

On narrative memories this is a large difference in what actually arrives. In a live A/B on real tasks the task-scoped Agent IR carried the same knowledge in about 104 to 234 tokens where the prose form took roughly 3,000, a measured 13 to 30 times smaller knowledge payload. That is a claim about the knowledge payload and nothing else; the benchmark page is explicit that it did not reduce an agent's total token usage.

A system that turns prose into structure can lose the part that mattered. A memory that says to use one helper instead of another can compile into a clean atom that names the winner and silently drops the loser, and an agent that receives it learns what to use but not what to avoid.

So compilation is not trusted on its own. Meaning is grounded in the source text, validated, and then put through a completeness gate that compares what would actually be delivered against what the source actually said. The gate is deterministic, has no model in it, and fails closed.

When the compiled form represents the source well enough, the agent gets it. When it does not, the delivery falls back to the source knowledge instead. Producing something confident and incomplete is the failure mode worth avoiding, and the gate exists to choose the honest option rather than the impressive one.

Understanding what a sentence means is a job for a model. Making sure a forbidden action does not happen is not.

Pathrule separates the two. Semantic work happens once, locally, at write time. Enforcement is deterministic and runs in the runtime, where a CONSTRAINT can intervene when an agent is about to do the thing your project has decided it must not do, and a CHECK can require that a verification actually happened before work is treated as finished.

This is the line between a memory product and a runtime. A paragraph in a prompt is advice that a model may or may not weigh correctly on turn forty. A constraint that the runtime holds is not depending on that.

Claude today, Codex tomorrow, something else next year. Each of them is an execution and reasoning engine, and each is genuinely good at that job.

None of them is where your project's knowledge should live. A memory feature inside one agent is knowledge held hostage to that agent: switch, and it stays behind. Everything Workspace Intelligence and User Intelligence have accumulated lives in Pathrule, so switching agents changes who does the work, not what is known about it.

Studio runs Claude Code, Codex, Grok, Kimi, Antigravity and OpenCode on the same workspace. Cursor, Windsurf and GitHub Copilot connect through Pathrule CLI. They all start from the same compiled knowledge.

Everything above can run behind the agents you already use, and most of the time it does. Pathrule Studio is where you work with the intelligence directly.

Ask why a constraint exists and get the decision and the incident behind it, not a guess from the code. Ask what the workspace has learned about authentication. Tell it to prepare a refactor without starting it. Teach it something you would rather not correct again. Look at what it has concluded about how you work, and change it.

It is not a chat window with a model behind it. The thing answering has the workspace knowledge, your User Intelligence, the knowledge graph, the task board, runtime signals and the record of what actually happened on previous runs.

The measurable claim is about compliance rather than speed. In a 12-task, 24-run grid on identical repositories with the same prompts, an agent working alone finished every task correctly and followed the project's own conventions on 3 of 12, with 8 violations. The same agent with Pathrule finished every task correctly and followed the conventions on 12 of 12, with none.

The reading matters more than the numbers. Claude could complete the tasks either way. What changed was whether it completed them according to what the workspace already knew. That is the whole proposition: the knowledge existed, and the difference is whether it reached the work.