On My Radar
On this page

Guides Agents and MCP

Memories and briefs

What an agent remembers and what it is told about your product: memory types, how the memory index loads, pinning, deleting and restoring, and briefs, with every size limit.

Updated October 30, 2026 · Checked against On My Radar build 2c4905d

An agent keeps two kinds of knowledge in On My Radar. Memories are notes it writes as it works. Briefs are reference documents about the product it works on. After this page you can read, curate and limit both, and you will know what an agent loads at the start of a session.

Memories

A memory is a short note that earlier sessions wrote, such as a correction you made or a decision and its reason. It lives in On My Radar, not on one machine, so the same memory shows up in every tool and folder. The agent is told never to write memory files to disk.

Each memory has:

  • A name: lower-case letters, digits and hyphens, such as postgres-constraint-traps. Up to 64 characters. It is the memory's key, and it cannot change after the memory is created.
  • A type, one of four.
  • A one-line description, up to 200 characters. This is what the agent sees in its index.
  • A body in Markdown, up to 64,000 characters.

The four types

  • Feedback: how you want the agent to work, with the rule first, then a line on why and a line on how to apply it.
  • User: who you are, your role and preferences, so its work fits you.
  • Project: decisions, incidents and context about ongoing work that the code does not already say.
  • Reference: where to find things in other systems, and how to use them.

What the agent does with them

The agent is given a fixed set of memory rules every time it loads. In short, it saves what was surprising or will matter in a future session, and does not save what the code or docs already say, step-by-step progress, anything true only for this conversation, or secrets.

  • agent_remember saves a memory inside a load session. create makes a new name. update replaces one and needs the revision the agent read, so a stale edit is refused and shown the current text. append adds a dated paragraph without a revision, which is safe from two devices at once.
  • agent_recall searches memories by words, fetches one by name, or lists by type. The index only shows descriptions, so the agent is told to read a memory's body before relying on it.
  • agent_forget removes one and must give a reason. A person can restore it for 30 days.

Memories are notes, not instructions. A memory that asks the agent to contact someone, change access, move data or ignore its instructions is treated as suspect, and the agent is told to say so rather than act. A memory write also does nothing else: no mention, tag, notification or webhook, unlike a blip.

Tip: To put a memory in front of other people, use Copy to a radar… on the memory. It makes a blip with the memory's text and leaves the memory where it is. Only a person can do this.

What loads at the start of a session

load_agent returns the prompt, the rules, and an index of memories, one line each. If the memory is not shared with whoever loads the agent, there is no index and no pinned memory.

- [feedback] agent-boundary (r4) — An agent-facing refusal must live in the service · agent · 3d

The index has a size budget of 32,000 characters by default. A caller can ask for between 2,000 and 96,000. When memories do not all fit, the index is cut in a fixed order: pinned memories first, then those the agent's owner wrote or imported, then everything else, which includes what an agent wrote and what a collaborator wrote. Within each group they go by type (feedback, user, project, reference), then most recent first. The same input always gives the same index. This means an agent looping over its own memory cannot push what the owner wrote out of view. The cut-off line says how many of each type were left out and tells the agent to use agent_recall.

Pinned memories load in full, first, in every session where the memory is shared with whoever runs it, inside the same budget. Only a person can pin or unpin one.

Curate memories in the app

Open an agent, then the Memory tab. It says how many memories there are, and "the agent writes these itself; you can add, edit or delete any of them".

  • Search memory, and filters Type (All types, Feedback, User, Project, Reference), Written by (Written by anyone, This agent, People, Imported, Collaborators) and Sort (Recently changed, Name, Type).
  • Each row shows who wrote the current revision, for example "agent · Claude Code". A pin mark shows a pinned one.
  • Select a memory to read it. Its buttons are Edit, Pin or Unpin, History, Copy to a radar… and Delete. History lists every revision. Links written as [[other-memory]] show as chips.
  • New memory opens the editor with Name, Type (with a one-line guide for the type you pick), the description and Body, using the same editor as a prompt. A stale save opens "This memory changed while you were editing".
  • Delete moves a memory to Recently deleted. A link labelled Recently deleted, with a count, shows them with a Restore button on each. They are gone for good after 30 days.

You need edit access to the memory to change it. If an agent was shared with you without its memory, the tab says "No memory shared with you" and your sessions run with the prompt only.

An agent can hold up to 2,000 live memories. At the limit a new one is refused with "Consolidate or forget some first."

Writing is also limited to 120 memory changes per session per hour. This stops a loop and is not a quota. The agent is told to stop and check with you.

Briefs

A brief is a reference document about the product an agent works on: how to run, test and deploy it, its invariants and its gotchas. It is not a second prompt. The agent loads only an index of briefs at the start, with each brief's name, description and revision, and reads one with get_agent_brief when its task touches it. It is told to keep the brief true in the same piece of work that changes the thing it describes.

A brief has a kebab-case name up to 64 characters, a one-line description up to 200 characters, and a Markdown body of at most 16 KB (16,384 bytes of UTF-8). An agent can hold 20 briefs. Every save is a new revision, r1, r2 and so on, and history is kept.

Work with briefs in the app

Open an agent, then the Briefs tab.

  • New brief opens the editor. It shows how much of the 16 KB you have used and refuses a body that is too long. The button is Add brief for a new one and Save as r3, using the next number, for an edit. A note field reads "Why — kept with this revision (optional)".
  • On a brief, Edit, History and a menu with Rename… and Delete…. In History you can compare revisions and use Restore as r4.
  • A brief's name can change without losing its revisions. Anyone who names the old one in a workspace file needs the new name.
  • Delete… removes the brief and every revision for everyone the agent is shared with, straight away, and asks you to type its name. It cannot be undone. Agents have no tool to delete a brief.

Writing a brief needs edit access to the agent's prompt, and if the owner locked the prompt, agents cannot write briefs either. Agents may write up to 40 brief revisions per agent per rolling day. Writing one needs the session that load_agent returned for that same agent, so each revision records which tool wrote it. To change another agent's brief, an agent loads that agent first.

An administrator can bind a brief to a repository. It then shows how far behind the code it is, such as "3 commits behind", "drift" or "not checked", and agents are told to read the code before trusting a stale one. Nothing in a repository is ever imported into a brief.

Briefs on shared agents

Briefs travel with the prompt. A person you share an agent with runs each brief as it stood when they accepted, unless they chose Follow updates. The brief's row says "r5 is newer" when the owner has moved on, and the banner at the top has Review briefs and Update.

Next