ClearMemory · Architecture
Where an agent gets its instructions, and how to see them
A task that follows a convention nobody wrote down is harder to correct than one that follows a convention open to inspection.
Last updated
Every agentic tool loads some form of standing instruction before it reads a request. A project convention, a house style, a rule about which test command to run. The question that decides how debuggable the result is: can you see what was loaded?
ClearFrame loads project instructions into a task and exposes them in a Memory panel. The panel describes itself in one line: the instructions ClearFrame loads into a task, and where they come from.
Two halves of the same claim
The wording carries two distinct promises, and both matter.
What is loaded. The instruction set is not an opaque prompt assembled somewhere in the runtime. It is presented as readable content, which means a task producing an unexpected result can be checked against the context it was given rather than guessed at.
Where it came from. Each instruction carries its origin. A rule that arrived from the project is a different kind of fact from one the application supplies, and the two should not be indistinguishable in a panel whose purpose is accountability. A convention the team agreed on and a default the vendor chose are both legitimate; conflating them makes an inherited default look like a decision.
The panel reports its own failures
The interesting design detail is what the panel says when it cannot answer.
- With no project open: "Choose a project folder to see its instructions."
- When the loader is missing: ClearFrame reports that it could not find the runtime that loads project instructions, "so it cannot say what is in context."
- When the read fails: "Memory could not be read yet."
Each of those is a specific statement about a specific failure. The middle one is the strongest: the application distinguishes "nothing is loaded" from "I cannot determine what is loaded" and refuses to present the second as the first. A panel that showed an empty list in that situation would be lying by omission, and the reader would have no way to tell an empty context from an unreadable one.
What is carried forward
A task's memory is what the next task in the same project starts from. That is the mechanism by which a lesson learned in one session reaches the next without being restated: the instruction is in the project, so a later task loads it along with everything else.
The limit is specific. This is bounded project memory, not an unbounded transcript. It carries instructions, not a recording of everything the agent has seen, and a reader expecting the second will over-trust it.
Memory is a setting, not a fixed behaviour
ClearFrame's own runtime configuration treats memory as a switch alongside the capabilities it enables. The settings enumerate instruction loading together with skills, the persistent shell and project tool permissions, and each can be enabled or disabled independently.
That matters because the alternative — memory always on, always opaque — leaves no way to answer a common question: is this behaviour coming from the project or from somewhere I did not intend?
The failure this prevents
Consider a task that refuses to use a library the project depends on. Without a view into its instructions, the explanations available to you are guesses: the model is wrong, the prompt is wrong, the file was not read. With the panel, there is a third possibility that becomes checkable first — a stale instruction in the project says not to use it, and it is being followed correctly.
That is the whole argument for making instructions inspectable. An agent obeying a rule the reader has forgotten looks exactly like an agent behaving badly, and only one of those is corrected by changing the instruction.
Stated limits
- Instructions, not history. The panel shows what is loaded into a task, not a record of what the agent has done.
- Bounded. Memory is deliberately limited rather than accumulating without end.
- Not a substitute for review. Reading the instructions tells you what the task was asked to respect. It does not tell you whether the result is correct, and the review surface exists for that.
Related reading: project memory and instructions in the documentation, and the permission model for the other half of what a task is allowed to do.