Today’s tip is one line: before your AI agent updates a record, make it read the record first.
It sounds too obvious to need saying. Then yesterday one of my agents wiped its own notes, and it was following my instructions exactly when it did.
The receipt
My content-research agent runs every Monday. One of its jobs is to update keyword rows in Airtable (mark the ones it won’t write about as “Skipped”, correct bad numbers) and leave a note explaining why. Yesterday it updated three rows that already had notes from earlier agents, including the keyword agent that ran that same morning: search volume, competition, and why the keyword was worth a look.
The update replaced those notes. It didn’t add to them. All three were gone.
The agent caught it on read-back, put the original notes back with its own note added at the end, and logged the mistake. Good recovery. But then I checked the instructions it was working from, and the example API call in its own skill file does exactly this:
PATCH … {"fields": {"status": "Skipped", "notes": "Skipped: near-duplicate of …"}}
That line doesn’t say “add a note.” It says “make the note this.” So I counted how often that has been happening quietly:
- The Keywords table has 274 rows. 168 of them have notes.
- Only 7 of those 168 notes show any sign of a second entry (a line break or a separator). Three of my agents write to this table.
- 3 notes start with the template’s exact “Skipped: near-duplicate” text, so if anything was there before, nobody can tell now.
I can’t prove what was lost, and that’s the problem. An overwrite doesn’t leave an error, a warning, or a log line. The old value just stops existing.

⚡ GET THE AI EDGE
Weekly AI tips that actually save you time and money. No fluff, no hype — just what works.
Why AI agents overwrite instead of append
Most APIs make “update” mean “replace this field.” The Airtable API update record call is a typical example:
- PATCH only touches the fields you send, but each field you send is replaced in full. Send
notesand the whole notes field becomes your new text. - PUT is worse. It clears every field you didn’t send.
A person editing a cell sees the old text before typing. An agent doesn’t see anything unless you tell it to look. It just builds a payload from what it knows right now. If it never fetched the record, it doesn’t know there was anything there to keep.
This is the third time in my fleet that a write silently replaced something. In July, two image jobs used the same temp filename and one overwrote the other’s files. In September, a script and a shell command wrote to the same file and corrupted it. Each time, the error showed up somewhere else, which made it hard to trace back.
The fix: read, merge, write, read back
- Read first. GET the record before any update to a text field like notes, history, or tags. It’s one extra API call.
- Merge, don’t replace. New value = old value + a line break + a dated note with the agent’s name:
content-researcher 2026-11-02: Skipped, near-duplicate of …. That way you can see who changed what. - Only send the fields you mean to change. Use PATCH, never PUT, unless you really want a full reset.
- Read it back. After the write, fetch the record again and check that the old text is still there. That’s how my agent caught yesterday’s mistake.
- Fix the example, not just the run. Agents copy the example calls in their instructions. If the example overwrites, every future run will too. Mine still does, and I’ve flagged that line for a fix.
For files, the same rule applies. Give every run its own temp filename (run date plus job name), so two agents can’t write to the same path. Pair this with the duplicate-work guard from keeping your agent from doing the same job twice and you’ve covered the two quietest ways an agent can damage its own data. When you report a number like “7 of 168,” keep the query that produced it (ship the query with the number).
This matters more as you add agents. One agent writing to a table is a script. Three agents writing to the same table is orchestration, and shared records are where agents step on each other.
The takeaway: an agent doesn’t know what it’s about to erase unless it reads first. Open your agent’s instructions today, find every update call that touches a notes or history field, and check whether it adds to the old value or replaces it.
Want a second pair of eyes on how your agents write to shared data? Book a strategy session.

📥 FREE: THE AI PLAYBOOK
The exact tools and workflows I use to run a one-person agency. 25 years of marketing experience distilled into an actionable guide. Yours free.
