Most of Pathrule works behind the agents you already run. **Studio is where you work with the intelligence directly.**

That distinction is the point of this page, because Studio is easy to mistake for two things it is not. It is not a settings dashboard for a context layer, and it is not another AI chat window.

## What is actually answering

When you ask something in Studio, the thing answering is not a model with your question and nothing else. It has:

- **Workspace Intelligence**: what this project has learned about itself.
- **User Intelligence**: how you prefer to work.
- **The knowledge graph**: how the pieces relate, including which decisions superseded which.
- **Tasks and agent state**: what is queued, running, or finished.
- **Runtime signals**: what actually happened in production, where Signals is enabled.
- **History and evidence**: what was delivered on previous runs, and how those runs went.

So "why do we use `getEnv()` here" has a real answer, with the decision and the incident behind it, rather than a reconstruction from the code.

## What you can do

Eight intents, all in ordinary language. You do not learn a syntax.

**Ask.** Why does this constraint exist. What have we learned about authentication. Which decision superseded this one. Why was this knowledge used for that run.

**Teach.** Remember that I prefer migrations in small steps. Treat this convention as a requirement in this package.

**Correct.** That is not what I meant. Do not do that by default.

**Inspect.** Show me what the workspace has learned here. Show me what you have concluded about how I work, and the evidence for it.

**Plan.** Prepare the auth migration, but do not start implementation.

**Delegate.** Have one agent investigate and another implement the fix.

**Command.** Do not let agents touch the legacy API.

**Explain.** Turn what we learned here into workspace knowledge.

Pathrule turns those into what they actually are: an answer, a knowledge update, a task, an agent run, a plan, or an inspection.

## Corrections feed the intelligence

This is the loop that makes Studio more than a nicer front end.

When you correct an agent's behaviour, that correction is evidence. Correct the same thing repeatedly and it stops being an observation and becomes a working preference in [User Intelligence](/docs/intelligence/user-intelligence), with the evidence attached.

Which is why the third exchange in this pattern is possible at all:

```text
You:
Why does Claude keep running so many tests?

Pathrule:
You've corrected this several times. I'll treat targeted
verification as your default, unless the workspace requires
a broader check.
```

Note the second clause. A preference shapes how the work is done; it does not override a project requirement. See [the authority model](/docs/intelligence/user-intelligence).

## Seeing why, not just what

Every delivery is recorded, so you can ask why a piece of knowledge was selected for a run rather than taking it on faith. That is also what makes a correction actionable: if the wrong thing was delivered, you can see that it was, and fix the knowledge instead of arguing with the agent.

## Agents still execute

Nothing here replaces your coding agent. Studio runs Claude Code, Codex, Grok, Kimi, Antigravity and OpenCode on the same workspace, and they remain the execution and reasoning engines. What changes is that you are directing them from the same place that holds what is known about the work.