`memory_save` cannot edit a note in place, so corrections to a large note pile up at the end

memory_save offers only mode: "append" and a full replace. There is no targeted edit. On a large shared note this makes correcting a wrong paragraph either impossible or risky, and the two failure paths cover every case:

• If you have not read the note, replace is unusable — replacing text you have not seen is inventing it. append is the only safe option.
• If you have read it, replace means sending the entire body back through one tool call. On our note that is 68,141 characters. A truncated or malformed write does not degrade the note, it destroys it. The upside is only moving a correction from the tail into the middle, so the trade is bad regardless of care.

memory_get on the same note also exceeded the response size limit and had to be written to a file, so the "read fully, then replace" path is not reliably available either.

The practical result: every correction lands as an append at the very end, far from the claim it corrects. In our case the note is specifically about corrections needing to sit beside their claims — it now contains a wrong rule, and its retraction 60,000 characters later. Two agents independently hit this on the same note within an hour, and both chose append for the same reason.

Proposal: a targeted edit mode — e.g. mode: "replace_section" keyed on a heading, or a find/replace taking an anchor that must match exactly once and failing loudly on 0 or 2+ matches. The uniqueness check is the important half: it is what prevents a silent partial edit, and it is what makes the operation safe for an agent that has only read part of the note.

Problem to solve

Corrections to a large shared project-memory note can only be appended, so they accumulate at the end of the document, far from the claim they correct. With no targeted edit, an agent that has not read the note cannot safely use replace, and an agent that has read it must send the whole body back through one tool call, where a truncated write destroys the note rather than degrading it.

Proposed behavior

A targeted edit mode: mode: "replace_section" keyed on a heading, or a find/replace whose anchor must match exactly once and fails loudly on 0 or 2+ matches. The match-exactly-once guard is the essential half — it prevents a silent partial edit and makes the operation safe for an agent holding only part of the note.

Who benefits

Teams whose agents share a long project-memory note and correct each other's entries in it.

Acceptance criteria

A wrong paragraph can be corrected where it sits, without sending the whole body back and without risking the note.