Today’s tip: give your AI agent memory file a shrink alarm. Before a run, record the file’s size. After the run, check it again. If the file got smaller, stop, restore it, and tell a human.
The reason is simple. My agents’ notes file should only grow. Yesterday one run cut it from 10,460 lines to 8.
收據
Every agent in my fleet reads a shared memory file at startup and adds a short entry when it finishes. On Monday at 10:35, my link-outreach research agent finished its run and saved its entry. But instead of adding to the file, it replaced it.
- Memory file: 2.42 MB and 10,460 lines before the run, 8 lines after. The only thing left was that run’s own entry.
- Work log: 6.72 MB and 44,115 lines before, about a dozen after. Same run, same mistake.
- Nothing was actually lost. That agent copied both files to a dated backup before it wrote anything. That habit is the only reason this post is a tip and not a disaster story.
The part that matters most came next. Nine more agents ran over the next 13 hours, and all nine noticed. Each one wrote some version of “the memory file is truncated, the full copy is in the backup, restoring it is your call” into its report. None of them restored it, and they were right not to. They’re told to add to that file and never overwrite it, so they left the decision to me.
Then the nightly watchdog graded the day: 16 of 16 runs passed. That was also accurate. Every run exited cleanly and reported success. The watchdog checks whether jobs ran, not whether the files they depend on survived.
So the fleet had nine written warnings, a perfect health score, and a memory file that was 99.9% gone. That is the same pattern as a warning that repeats until it becomes wallpaper, just faster.

⚡ 取得人工智慧優勢
每週提供真正省時省錢的AI小技巧。沒有廢話,沒有誇大其詞——只有切實有效的方法。.
Why a size check beats a smarter agent
Last week’s tip was make your agent read before it writes. That fixes a single field. This is the same mistake at file scale: one “save” call that means “replace” when you wanted “append.”
You can’t count on every agent getting that right every time. Different skills, different prompts, different days. What you 能 count on is arithmetic. An append-only file should never get smaller, so if it did, something went wrong, and you don’t need to know what.
The fix: a 10-line guard around every run
- Before the run: save the file’s size in bytes and copy the file to a dated backup.
before=$(wc -c < MEMORY.md) - After the run: measure again.
after=$(wc -c < MEMORY.md) - If
後is smaller than前: move the shrunken file aside (don’t delete it, because the new entry is in there), put the backup back, and append the new entry to the end. - Alert a human once, with both sizes in the message: “MEMORY.md shrank from 2,421,795 to 1,277 bytes. Restored. Check the run.” One alert with numbers beats nine polite notes.
- Put the guard in the scheduler, not the prompt. The agent that made the mistake shouldn’t be the one checking for it. A wrapper script that runs before and after every job catches all of them, including the ones you write next month.
My fleet doesn’t have this guard yet, and that’s the gap. The backup step worked. Detection worked nine times. What was missing was the one dumb rule that turns “noticed” into “fixed”: this file can’t get smaller.
If backups are piling up on you, pair this with 3 ways to make an agent cleanup rule stick. And if your memory file is getting huge to begin with, read why more memory doesn’t make an agent smarter.
要點: list every file your agents are only supposed to add to (memory, logs, history, ledgers), and add a before-and-after size check to each one today. It’s ten lines of shell and it never needs to understand what went wrong.
Want a second pair of eyes on what your agents could quietly erase? 預約策略會議.

📥 免費:《人工智慧劇本》
我用來經營一人代理公司的所有工具和工作流程。 25 年的行銷經驗濃縮成一份實用指南。免費贈送。.
