Workspace Intelligence

Workspace Intelligence is the answer to one question: how does this project work?

Not what the files contain. An agent can read those, and it reads them well. What it cannot read is the working knowledge a repository accumulates around its code, which is exactly the knowledge that decides whether a change is right or merely plausible.

What it models

• Architecture decisions, and the reasoning that produced them.
• Hidden constraints that are not visible anywhere in the code.
• Verification requirements: what has to be checked before something counts as done.
• Previous fixes: what actually worked the last time this specific problem appeared.
• Conventions a team follows without writing down.
• Procedures: the ordered way a recurring job is done here.
• Contextual facts that change the right approach, such as a database being a read-only replica.
• Technical rationale, which is what stops an agent from helpfully undoing a deliberate decision.
• Preferred implementations among several that would all work.
• Superseded decisions, so an old one stops being treated as current.

All of it lives in three kinds of content your team can read and edit: memories, rules and skills.

Scope

Workspace Intelligence is scoped to a repository, and inside it to paths.

This is the mechanism that stops a knowledge layer from becoming the problem it was meant to solve. Everything true about a monorepo is not relevant to a change in one package, and delivering all of it makes the three sentences that matter compete with two hundred that do not. Knowledge attaches to the path it governs, and a task in that path receives what governs it.

Path scoping is also why a workspace can keep growing without each turn getting heavier. See how retrieval works.

Authority

Workspace Intelligence is the layer that can hold hard requirements.

Requirements live in rules. A rule states what must or must not happen in a scope, carries a priority, and arrives in its own section, separate from advice. A rule can also carry an executable constraint, a pattern a change must not contain. A constraint an agent proposes is stored as a proposal and is not enforced; once a person has approved it, the pre-tool hook can block a matching edit in clients whose hooks support that. See rules as guardrails.

These are properties of the project. They are not dropped because a personal preference would be more convenient, and User Intelligence cannot override them. Everything else Workspace Intelligence holds is advisory and is delivered as advice, so a past fix is never presented as if it outranked a rule.

Sources

Four kinds, and it matters which is which.

Authored. Memories, rules and skills a person wrote on purpose, or that an agent wrote through Pathrule's tools, usually after proposing them to you. These are the ones a team can point at and argue about, and they are the backbone.

Findings from the code. Conclusions an agent reached by reading your code, saved with the files they rest on and delivered as advice only while those files are unchanged. See project learning.

Evidence from real work. What agent sessions reported about themselves: which knowledge was delivered, which was actually consulted, which files moved together, where an agent kept getting stuck. See what Pathrule computes.

Seeded from your checkout, on a cloud workspace. The first time an agent asks Pathrule for deep context on a cloud workspace, the local runtime reads file paths from recent git history to learn which files have changed together, and lists file names in the top levels of the folder tree to recognise the technologies in use, such as a TypeScript, Docker or GitHub Actions configuration. The path pairs are saved to the workspace as the starting point of files that change together, so the signal is useful before your team has logged much work. Each technology it recognises becomes a short memory at the workspace root, such as "TypeScript project", written without asking; it is an ordinary memory you can edit or delete. A local workspace skips this step and learns which files change together from logged work alone.

What is not a source: your source code. Pathrule does not automatically upload your code, and the seed above reads file names and paths, not file contents, diffs or commit messages. On a cloud workspace, pathrule snapshot, when you or your agent run it, uploads the file tree, manifests, short documentation samples and recent git metadata so Pathrule can describe the project. What Pathrule computes lists what is read and what is kept.

Team Intelligence

On Pathrule Cloud, Team Intelligence looks across the evidence a team's work produces and proposes patterns: conventions, fixes and decisions that keep coming up. It is available on the Team and Enterprise plans, and organization owners and admins manage it in the web console, under the organization's Team guidance settings.

A pattern moves from draft to suggested, and a person either verifies it or rejects it; a suggestion nobody acts on expires. Only verified patterns reach agents. Nothing Team Intelligence infers is trusted on its own.

Lifecycle

1. Written or proposed. A person writes it with the CLI, the VS Code extension or their agent. An agent that discovered something worth keeping saves it through Pathrule's write tools, usually after proposing it to you, and the write is attributed, versioned and reversible. Asking your agent to "Set up Pathrule for this project" runs a guided scan in which the agent proposes memories, rules and skills and writes the ones you approve. On a cloud workspace, Pathrule also adds the short technology memories described above.
2. Approved, where something was inferred. Inferred knowledge waits for a person: a rule's executable constraint is enforced only after approval, and a Team Intelligence pattern reaches agents only once verified. Agent findings are the one exception, and they stay advisory. See Proposed Knowledge.
3. Delivered. The part relevant to a task reaches the agent through the mechanism its client supports. See Agent IR.
4. Measured. Delivery and what the agent did with it are recorded, so an entry's standing reflects what happened rather than who wrote it.
5. Refreshed, superseded or retired. Knowledge that looks stale can be flagged as a refresh task, and a person or an agent works through it. A decision that a later one replaced stops being treated as current. See suggestions and self-audit.

What changes when you switch projects

All of it. Workspace Intelligence belongs to the repository, and opening a different one means a different body of project knowledge, shared with whoever else works in it.

What comes with you is User Intelligence, which belongs to you: the preferences you taught Pathrule and chose to apply everywhere.