Your agent remembers an outdated decision. Repair the memory index without erasing history.
Propose changes before editing; preserve sources and route unresolved conflicts to an accountable owner.
The agent still gives a quote fourteen days of validity. The commercial owner changed the rule to seven. A restriction from a finished project follows every new job, while an enduring editorial preference disappears into an old conversation.
Before changing models, inspect the index the agent reads. Does it distinguish current rules, project history and suggestions nobody accepted?
Buda separates memory into three layers: the current session, the compact MEMORY.md index and the full archive in Drive. The index points to knowledge; it is not the archive. Maintenance should improve that map without quietly rewriting the past.
Start with a small, inspectable inventory
The following files, people and dates form a fictional teaching example, not a real team's records.
# MEMORY.md — before
- Standard quotes remain valid for 14 days.
- Atlas: do not use external material for this project.
- Brand voice: name concrete actions; substantiate benefits.
- We could try extending quotes to 30 days next time.
Three authorized files add necessary context. policies/quote-v2.md records a seven-day standard-quote rule accepted by commercial owner Lin, effective October 1, 2026. projects/atlas/closeout.md records that Atlas closed on September 30. brand/voice-approved.md contains the preference accepted by editorial owner Chen. Nobody has accepted the thirty-day suggestion.
Inventory these paths and their versions first. Do not scan an entire private Drive merely to clean a short index. If access, provenance or permission is missing, list the gap and stop that item's revision. A recent modification timestamp is a reason to inspect a file, not proof that its contents supersede an accepted decision.
Separate the type of statement from the editing decision
Classify each entry as a lasting preference, time-bounded fact, task progress or unaccepted suggestion. Split statements that mix categories. Then propose an action:
| Entry | Verified basis | Proposed change |
|---|---|---|
| Fourteen-day quote | Accepted v2 changes it to seven days | Replace the current summary; retain the old version's pointer |
| Atlas restriction | Project closed; this says nothing about new projects | Mark historical and preserve its project scope |
| Brand preference | Accepted and not superseded | Keep it; add source and accountable owner |
| Thirty-day idea | Discussion only | Remove from current rules; mark for confirmation |
Keep, replace, mark historical and confirm are editorial decisions, not an automatic truth engine. When owners disagree, present the scope and acceptance evidence to them. Do not resolve a business conflict by choosing whichever file was edited last.
Build a replacement index with explicit pointers
Save the original text, for example as memory-history/index-before-review.md, and show the proposed edits before applying them. Record exactly which changes a person accepts. Keep historical files; do not copy sensitive source text into a shared Space as a shortcut.
An accepted replacement might read:
# MEMORY.md — current summary
## Current rules
- Standard quote validity: 7 days.
Source: policies/quote-v2.md; accepted by Lin.
Effective: 2026-10-01; replaces the 14-day rule.
- Brand voice: state the action; evidence any benefit.
Source: brand/voice-approved.md; accepted by Chen.
## History pointers
- Atlas's external-material restriction applied to Atlas.
Closeout: projects/atlas/closeout.md.
- Previous index: memory-history/index-before-review.md.
## Needs confirmation
- The 30-day suggestion was not accepted; do not apply it.
Ask Lin; retain the original discussion reference.
The source still holds the full rule. The index carries enough scope, provenance and navigation to retrieve it. If v2 covers standard quotes, do not shorten that to “all contracts expire after seven days.” Summarization must not expand authority.
Keep an editing ledger with entry ID, old and new summary, source path/version, acceptance owner, effective date, review decision and replacement relationship. Write “not recorded” or “needs confirmation” rather than inventing missing fields to make the ledger look complete.
Run three retrieval checks in a fresh session
Start a new session in the Agent tab. Supply the index and authorized source paths, not the explanatory chat that led to the edit. These are proposed acceptance requests, not completed test results.
- “Draft a standard quote today. Which validity period applies, and where does it come from?” Expect seven days, its scope and the accepted v2 source—not an unsupported answer copied from the summary.
- “Atlas has closed. Does its old restriction automatically govern a new project?” Expect a distinction between historical scope and new-project permissions. Missing new rules require confirmation, not an assumption that outside material is now unrestricted.
- “Why did you not choose thirty days, and can you still locate the fourteen-day record?” Expect the unaccepted suggestion to remain unresolved and the prior index to remain discoverable.
Record the actual answer, source opened, stale constraint still misapplied and any unresolved disagreement. Accept the maintenance only when the answer and its evidence agree. One successful retrieval does not cancel another answer that still treats an obsolete rule as current.
Questions that change the maintenance decision
Should every project detail live in MEMORY.md?
No. Keep recurring summaries and useful pointers there. Full project history belongs in the authorized archive. Otherwise temporary restrictions become hard to distinguish from standing rules, and the index becomes another large document to maintain.
What if an important statement has no acceptance record?
Retain its original wording and source, mark it for confirmation, and identify who should decide and which tasks depend on it. Do not promote it to a lasting instruction. Pause the dependent decision if the current job cannot proceed without it.
Does editing these files train the model or update every agent?
It does not change model weights. Agent Drive and Space Drive have different sharing scopes. Inspect which index and path each agent actually uses and what it can read; do not assume a private edit propagates across a team.
Review the proposal before changing the map
Ask the Buda agent for a keep/replace/history/confirm proposal with a source for each entry. A person accepts the edits; a fresh-session check then tests the resulting map.
If maintenance repeats, search for and install a suitable Skill in the Buda AI Marketplace. Inspect its input boundaries, stopping conditions and proposed outputs. If none fits, create a method for the team. Installing a method is not approval of its future edits.