Your agent doesn’t know what your other agent did
Agni Tripathi
SubscribeSign in
Your agent doesn’t know what your other agent did<br>Agni Tripathi<br>Jul 21, 2026
Share
A coding agent shipped code to my live site three times in 24 hours. Every deploy succeeded, and every one of them erased fixes that a different agent session had already shipped. Each session did exactly what I asked. Untangling it cost me four hours on a hobby project.<br>The setup that produced this is quickly becoming the default way people build. The pitch of agentic work is parallelism: separate agents on separate parts of a project, in the same week or the same hour. The pitch is real. It also quietly removes a layer human teams have leaned on for decades, the machinery that checks whether your view of shared state is still current before you act on it. I call what’s left behind the reconciliation gap, and right now the human in the loop is the only thing that closes it.<br>Thanks for reading! Subscribe for free to receive new posts and support my work.
Subscribe
What actually happened
The project is small. A static hobby site, no backend, a single contributor. Across a few days I delegated chunks of it to separate AI coding sessions (Claude Code, in my case, though the tool is beside the point). Content polish in one session, gameplay tuning in another, analytics wiring in a third. Each session opened the project, made its edits, committed them, ran the deploy.<br>Session A made fixes, committed them, pushed to the shared repo. The live site updated. All good.<br>Session B started the next day. It read the files on disk to plan its edits, and it never asked whether those files matched the shared repo. They didn’t. Session A’s fixes had landed on the remote, but the local copy on my machine was still the older version. Session B made its edits on top of that stale snapshot, committed them, and ran the deploy, which uploads whatever sits in the local working tree as the new production version. Session A’s fixes vanished from the live site. They were still sitting safely in the shared repo the whole time.<br>I noticed the regression and fixed it again in a third session, which pushed cleanly. A few hours later a fourth session, opened for an unrelated task, repeated the failure. Same root cause, same symptom: bugs that reappear after the agent commits, even though nothing the agent touched should have affected them. (Finding the pattern took most of an evening. The fix, once I saw it, took a minute.)<br>Why nothing caught it
Every agent session acts on a snapshot: whatever happens to be on disk, in the database, in the memory file it inherits. It rarely stops to ask whether the snapshot is still true. That is fine while the agent is the only writer, since the snapshot is the truth by definition. The moment a second writer shows up, the snapshot turns into a guess that looks exactly like the truth, and the last writer wins even when the overwritten work was the right work.<br>Engineers on human teams get protection from this for free. Pull before you push. Merge conflicts surface in the terminal. Branch protection blocks pushes that aren’t current, and a reviewer types “rebase please.” The checking has been baked into the tooling for so long that nobody notices it running. Solo agentic work has none of those gates, and if the human skips the checkpoint between commit and ship, nothing else supplies it. The agent has no incentive to slow down. The human has no easy way to notice, because stale files look like normal files.<br>The quiet version
A visual regression is the loud case; it gets noticed within minutes. A quieter version was running underneath it.<br>The same overwrite removed a set of cache-control headers an earlier session had added to the deploy configuration. Those headers force browsers to re-fetch the HTML after every deploy, so visitors always get the latest version of the site. With the headers gone, browsers and CDN edges (the cached copies of the site sitting near users) kept serving older HTML to a fraction of visitors. Their pages rendered fine. They were just the pages from before I had installed any analytics, so the pageview events for those visits never fired.<br>The dashboard showed undercounts. I almost wrote it off as ad blockers or iOS privacy mode (the usual suspects for undercounting). Neither was the cause. My stale deploys had quietly revoked a fix that existed to prevent exactly this. Corrupted analytics feed every decision you make from that dashboard afterward, and they can run for weeks before anyone squints at the numbers.<br>The same gap, everywhere
Last month I wrote about coding agents quietly rewriting the tests they are graded on. This is the sibling failure. In both cases the agent’s output looks clean, every check passes, and the damage sits in state the agent never inspected.<br>The same failure shows up anywhere agents share state. The local filesystem is a cache, the local database is a cache, the agent’s memory of...