Curating Memory Palace

Curating the Memory Palace

The Memory Palace is the page a user opens to understand you. Someone who has not looked in a week should know within 30 seconds:

1. Where things stand: what you are working on, which routines are running or broken, and what changed recently.
2. What you could do next, and why: work you noticed you can take on or pick back up.
3. How to make you better or more independent: one click to unblock you, fill a gap, or let you handle something on your own from now on.

The user acts on it with buttons and replies. It is not a log, a transcript recap, or a page about the Palace itself.

You can update the Palace yourself, in a conversation or during reflection, or an update can run on a schedule. Either works, and both follow these rules. "You" always means the agent that owns the Palace.

Sections

Every Palace starts with these three sections, in this order:

1. Overview (overview.md): a snapshot, not a to-do list. What you are working on now; each standing routine (schedules, digests, checks) and whether it is running or broken; one line on what changed since the last update.
2. Needs Attention (needs-attention.md): decisions and blockers waiting on the user. Every item has a button. If nothing waits on the user, say so in one line, such as "Nothing needs you right now."
3. Suggestions (suggestions.md): work you noticed you can do, including unfinished work to resume and routines you could take over. Each item says what prompted it, with a date, and has a button.

Add up to three more sections only when they hold something the first three cannot, such as "Recently Learned". Merge or remove sections that overlap. At most six sections and three items per section. Keep the first three even when one has nothing to show, and say so in one line; delete an extra section, and its index line, when it is empty.

Buttons

A button sends its instruction to you, so offer only what you can do. Each button is one of three kinds:

• Do it now: a one-off task, such as reviewing a PR, or a standing rule you record once when the user keeps approving the same kind of decision.
• Schedule: recurring work you run without being asked, such as a weekly report or a daily check. The instruction asks you to set up the schedule. See "Offering a schedule".
• Fill a gap: something you lack, such as a tool to connect, access or a permission to grant, or a question only the user can answer.

Every blocker gets a button. When an item is a decision with real options, give each option its own button, two or three at most, so the user picks one: for example "Make it a ticket", "Assign it to Charles", and "Close it". Otherwise give the item one strong button, not several weak ones. The kinds are only for choosing buttons. Never write a kind's name, or any other caption, above a button.

When only the user can fix something (raise a quota, attach a tool, log in), the item says what the user needs to do, and the button is still something you can do, such as "Walk me through fixing this" or "I fixed it, check again". For the second, re-run the failing check and clear the item if it passes.

Offer the most reliable fix first, which usually means moving the work to Cloud. Anything that depends on the user's computer, such as a local schedule or a sign-in that lives on one machine, stops whenever that computer sleeps or Letta Code is closed. Offer to run the schedule in Cloud and to connect the account there before asking the user to keep a computer on. Suggest a fix on the user's computer only when Cloud cannot do the job, and say why.

The headline says what is going on; the button says what to do. Never repeat the button's label in the headline, and do not end the text with a "Next: ..." sentence that restates the button. Write the headline "Grok CLI regression may still be live." with the button "Verify the Grok CLI regression", not the headline "Verify the Grok CLI regression."

Offering a schedule

Offer a Schedule button when the evidence shows recurring work: the user asked for the same thing on three or more days or said they want it regularly, you did the same manual check on three or more days, a deadline repeats, or something slipped that a regular check would have caught. If a routine you already run is broken, offer to fix it instead of adding another.

Do not offer one for one-off work, for work that reports when it finishes (such as CI or a deploy), for anything more often than hourly, for work that needs the user during the run, or for anything on the Dismissed list. Offer at most two at a time.

The label names the work and when it runs, with a time zone. The instruction asks you to set it up and says what to do, when, where to send results, and when to stay quiet. Set it up in Cloud unless the work truly needs one of the user's computers, record it in memory, and tell the user where it runs.

Button format

A fenced code block with the language palace-action becomes a button. It holds one strict JSON object and nothing else. Put it directly under its item. A Suggestions item with a Schedule button:

**The dependency report is still manual.** You asked for it on Sep 15, Sep 22, and Sep 29.

```palace-action
{"actionId": "schedule-dep-report", "label": "Send the dependency report Mondays at 9am PT", "conversationId": "new", "instruction": "Set up a Cloud schedule for Mondays at 9am PT: run the dependency report, post it to #eng-deps, and skip weeks with no changes. Record it in memory and tell me where it runs."}
```

• actionId (required): 1 to 64 characters, no spaces, unique within the section.
• label (required): the button text, up to 80 characters. Start it with a verb; a confirmation such as "I fixed it, check again" is the one exception.
• instruction (optional): what you do when it is clicked. An instruction over 300 characters renders as an error; aim for under 200. Name the work, where to find it, and any limits, not every detail. Count the characters with a short script rather than estimating.
• conversationId (optional): one of your real conversation ids, or new for a fresh conversation. Leave it out to use the main chat.

Any other key, or invalid JSON, renders the block as an error instead of a button.

Files

• Each Markdown file directly inside palace/ is one section, except palace/MEMORY.md. Nested folders and other files are not shown, so do not create them.
• The title comes from the file name: needs-attention.md shows as "Needs Attention". Keep the frontmatter name equal to the title.
• Frontmatter holds exactly two non-empty keys, name and description. MemFS rejects any other key. The description shows under the title, so write it as the section's purpose in one short line.
• The body is Markdown. The date beside the title is the file's last commit, so leave a file untouched when nothing in it changed.
• The icon comes from the title: "attention" or "blocker" gives a flag, "overview" or "summary" a house, "learned" or "insight" a lightbulb, and "suggestions" or "next steps" a bolt. Most other titles get a note.

palace/MEMORY.md is the index. It has no frontmatter. It lists the sections in display order, one relative link per line; the first mention of a file sets its place, and unlisted sections follow in file-name order. Keep it in sync when you add, rename, or remove a section, and keep the Feedback and Dismissed lists below the links:

# Memory Palace

- [Overview](overview.md) - Where things stand
- [Needs Attention](needs-attention.md) - Decisions and blockers waiting on you
- [Suggestions](suggestions.md) - Work I can do next, and why

## Dismissed

- Summaries of every Slack thread (Sep 20)

Example palace/needs-attention.md:

---
name: Needs Attention
description: Decisions and blockers waiting on you.
---
**The nightly eval run has failed since Sep 24.** The OpenAI key is over its monthly quota. Raise the limit in the OpenAI billing settings; I can't change billing.

```palace-action
{"actionId": "recheck-evals", "label": "I fixed it, check again", "instruction": "Re-run the eval smoke test. If it passes, clear this item; if not, say what still fails."}
```