When AI Systems Learn to Turn a Deaf Ear to Their Own Writes

A recruiting system waits five minutes after any change to a candidate's file, then rewrites the summary at the top. A recruiter adds a note, a résumé comes in, a call record is appended — five minutes later the summary is updated. Sounds reasonable, but there's a trap hidden here: the summary itself lives in the file, rewriting the summary changes the file again, so five minutes later it rewrites once more, forever looping. Through this "stupid question," the author reveals the self-triggering loop that every system reading and writing the same store runs into, and shares three strategies for "inaudible writes."

The Shape of the Loop: Read, Write, Read Again

Any system that both reads from a store and writes to that same store falls into this loop. The recruiting system reads the candidate file and writes the summary; the pipeline that publishes the work log reads commits and writes log entries, and the log entries are themselves commits; the chargeback agent in the billing flow reads claims and writes notes back. Three different businesses, one identical shape. The machine reads a thing, says something about it, then puts what it said back where it read from.

Wasted tokens are the visible cost; the more insidious price is that every "did it change?" signal stops working. The hash on the candidate file is supposed to answer one question: has this person's evidence moved since we last processed it? If the summary is included in the hash, the answer is always "yes." The hash no longer means the candidate changed — it means the machine did something, and the machine is always doing something.

Hash as a change signal: The "hash" mentioned here typically refers to a fixed-length fingerprint computed over the candidate file's contents (e.g., SHA-256). The system stores the hash from the last processing; next time it just recomputes and compares against the old value: if identical, the content is unchanged and expensive processing can be skipped; if different, the "evidence moved" and re-analysis is needed. This relies on an implicit premise — the hash covers only the "business evidence" fields (résumé, notes, call records) and not the derived content the system generates itself (like the summary). Once the summary is folded into the hash input, every machine write-back changes the hash value, degrading the "did it change?" judgment from "did the candidate change" to "did the machine run," and the change signal fails entirely. The hash boundary and the write-visibility strategy must therefore be designed together.

Fix the Writes, Not the Trigger

My first instinct was to make the trigger smarter: filter by who made the change, check timestamps, compare old and new summaries and skip matches. But these schemes break as soon as the next write path appears — and write paths always appear. The real fix lives where the write happens: when the system writes, it decides on the spot whether that write is allowed to be heard by the system later.

In the recruiting system there are now three kinds of silent writes. Profile write-backs produce no audit events — recruiter edits and inbound résumés enter the trigger flow, but the machine's own updates don't. The AI summary note is excluded from evidence and from the hash — the note still exists and can be opened and read, but it isn't evidence, it doesn't count toward what we know about the person, it doesn't enter the hash, and it doesn't affect whether the person has changed. Batch-created entries emit no events — the extraction process splits a résumé into dozens of entries, and if every entry fired a create event, extraction would wake extraction, so the batch path is deliberately silent.

Key insight: A system that reads and writes the same store will loop on its own output unless it decides, write by write, which of its own changes it is deaf to.

Limits of triggers and event-driven architecture: A trigger is a mechanism in a database or pipeline that "automatically executes an action when some condition is met," common in change data capture (CDC) and event-driven systems. It naturally reacts to "every write that happens in the store" but cannot distinguish where a write came from or what it means. The first instinct in the article — "make the trigger smarter" — amounts to filtering on the consumer side, but every new write path (a new agent, a new batch job, a new write-back logic) can bypass the filter rules and resurrect the loop. The real fix moves upstream to the producer: the writer declares at persistence time "whether this write should be perceived by downstream listeners," binding the visibility decision to business semantics instead of relying on centralized heuristics.

The Same Shape Everywhere

The site pipeline is the clearest case. It reads the content I deliver, writes work log entries, refreshes the operations graph, and adds to an insight log that now has 159 entries. Every output is a commit. If the pipeline treated its own commits as work, it would publish an entry about publishing an entry. So its own commits are the writes it can't hear.

The billing side has the same shape but higher stakes. A voice agent calls a payer and writes the result onto the claim; the chargeback agent watches claims. If the call note counts as a claim change, the chargeback agent re-evaluates the claim and writes its own note, the voice agent's scheduler sees the changed claim and calls the payer again. No one designed this loop on purpose — it's just the result of two reasonable agents sharing one table. So before anything ships, ask the same question: of these writes, which ones can the other agent hear?

Cascading triggers across agents sharing a store: In the billing case, the voice agent and the chargeback agent share the same claim table, each reading and writing back notes. If both treat the other's write as a "claim change," you get a cascading A writes → B reads → B writes → A reads loop, and each round can trigger real side effects (like calling the payer again). This is especially insidious in multi-agent systems because each agent looks reasonable on its own — the loop is an emergent result of the interaction. The design needs an explicit visibility matrix for every producer–consumer pair: which writes are visible to which agents, and which should be silent. That matrix should be a required pre-launch check, not a patch applied during debugging afterward.

Silence Leaves No Trace

A write that produces no event is a write the audit log won't show. I chose that deliberately, and I'd choose it again. But it means the silence is a fact I have to store elsewhere, because it won't leave a trace on its own. The log shows what happened but never what was deliberately not heard. So the deaf-writes list sits right next to the trigger, and when the summary does something unexpected, it's the first thing I read.

The result: the summary now rewrites five minutes after a real change and stays quiet after its own writes. The audit stream shows recruiter edits and intake events, not the machine talking to itself.

Five Principles

1. Before wiring up a trigger, write down every write the system makes. The trigger takes an afternoon; the list is the design.
2. Default your output to silent. If the machine wrote it, the machine shouldn't hear it — unless you can say why it should.
3. Keep your output out of the hash. A hash that includes the summary will say "changed" every time the machine runs.
4. Batch writes emit no events. If a step creates a hundred entries, it must never wake the step that creates entries.
5. Put the deaf list where a human will read it. Silence leaves no trace in the log, so it needs to leave something somewhere else.

The trigger took an afternoon, but the real week was sitting down to list every write the machine makes and asking, one by one: should the machine be allowed to hear this? A system that listens to everything ends up mostly hearing itself.

One-line Summary

Systems that read and write the same store trigger themselves endlessly on their own writes; the fix is letting the writer decide which changes it's deaf to.

Paragraph Summary

The article starts from a recruiting system's "stupid question": after a candidate document changes, it waits five minutes and rewrites the summary — but the summary lives in the file, so rewriting it changes the file again, looping every five minutes. The author shows this is the shape shared by every system that reads and writes the same store — the machine reads, says something about it, and puts what it said back where it read. The visible cost is wasted tokens; the subtler cost is that "did it change?" signals like hashes stop working. Rather than making triggers smarter, the author argues for deciding visibility where the write happens, with three silent writes: profile write-backs produce no audit events, AI summary notes are excluded from evidence and the hash, and batch creates emit no events. The site pipeline and chargeback agent cases show the shape is universal, and multi-agent shared stores need explicit visibility of which writes each can hear. Five principles follow, centered on defaulting machine output to silent and putting the deaf-writes list where a human will read it.