PathruleAgent IR
What Pathrule delivers to a coding agent for one task, what it deliberately leaves out, how a memory arrives in full or by title, how authority survives delivery, and how the channels differ between clients.
On this page
Agent IR is Pathrule's name for what one agent receives for one task: the boundary between everything Pathrule knows and one execution by one agent.
The boundary matters. It is knowledge, selected for a task, then rendered for a client, not a query joined onto a prompt. What an agent receives is put together for the work in front of it, and its shape is a design decision rather than whatever a search happened to return.
What it carries
For one task, in one scope:
- The rules that apply, as rules, in their own section.
- The memories that matter most for the path and the prompt, in full, and the others that apply, listed by title.
- The skills that apply, by name, so the agent can load the procedure when it needs it.
- Your personal preferences, in clients with a prompt hook, under a heading that keeps the workspace's requirements first. See User Intelligence.
- Findings agents recorded about the code, framed as advice to verify, in the context an agent asks for. See project learning.
- Verified team patterns, on Pathrule Cloud. Suggestions that nobody has verified are not delivered.
What it deliberately leaves out
Everything that does not improve the execution.
No bookkeeping fields, no internal identifiers the agent has no use for, no knowledge scoped to other parts of the repository, and nothing a person has not approved where approval is required. A suggestion, a candidate preference or an unapproved rule constraint is not delivered.
Three properties that are load-bearing
Kind is preserved. A past fix is delivered as a past fix and a rule as a rule. Flattening both to "remember this" throws away the thing that made each useful.
Authority is encoded, not flattened. Advice renders into a clearly subordinate place rather than being concatenated after a hard rule at the same weight. An agent reading the delivery can tell a requirement from a suggestion, because the delivery said which was which. See Knowledge IR.
The full text is always one read away. A memory that does not fit the per-prompt budget is listed by title rather than dropped, and reading it by name returns everything your team wrote.
How a memory reaches the agent
A memory reaches an agent in one of three ways.
- In full, for the prompt. In clients with a prompt hook, Claude Code and Codex, Pathrule selects the memories that matter for the path and the prompt, ranks them, and delivers the most relevant in full before the agent starts, within a per-prompt budget. A memory already delivered in the session is not sent again.
- By title. Memories that apply but do not fit are listed by title, so the agent knows they exist and can read any of them with
pathrule_read_memory. - In the instruction files. The files Pathrule compiles for each client carry the workspace's knowledge, or an index of it, at the paths it governs, so even a client with no hooks starts from it.
Reading a memory by name is not delivery. It always returns the full text, because an explicit read is a request for the source.
What arrives in full, and what arrives as a name describes the budget in more detail, and how retrieval works describes how the selection is made.
Where compiled delivery applies
How much of this arrives without the agent asking depends on the client's hooks.
| Client | What arrives automatically |
|---|---|
| Claude Code, Codex | Instruction files at session start, plus a per-prompt delivery from the prompt hook. |
| Cursor, GitHub Copilot | Instruction files, plus context from session and tool hooks. No prompt hook. |
| Windsurf | Its rules file. No hooks; deeper context comes through MCP. |
| Remote MCP clients | Nothing automatic. The agent asks through MCP tools. |
Remote MCP is a hosted tool endpoint. It installs no hooks and writes no local files, so a remote client requesting knowledge is different from a local hook delivering it at the moment the agent acts. Any agent, on any of these routes, can ask for more with pathrule_get_context.
Engine-neutral
What is selected never depends on which agent is about to run. The same knowledge is rendered once, and each client receives it through its own native mechanism: its instruction files, its hooks where it has them, and MCP. See how hooks work.
This is what makes agent independence structural rather than aspirational. There is no Claude-shaped knowledge and no Codex-shaped knowledge, only the knowledge and the envelope it ships in. What differs between clients is how much of it can arrive without being asked for, which the table above makes explicit.