I have more than one AI agent working on my self-hosted sites now. One of them has shell access to the server. The one I mostly work with doesn’t, and keeps a local copy of the theme source that it builds deploy zips from. That split works fine right up until both of them touch the same files.
On 6 October it nearly bit me. My agent caught it before it did.
Two agents, one theme, two versions of the truth
That evening, the agent with server access added homepage ad slots to my fantasy football side project. It did it by hand-editing two live theme files on the server, functions.php and front-page.php: a slot at the top of the homepage, another one further down the feed, wrappers around two hand-placed ad units, and a bit of CSS so empty ad wrappers collapse instead of leaving a hole. It left timestamped .bak copies of both files right next to them before it changed anything.
All of that was fine. The problem was on my side of the fence. My agent’s local theme source didn’t have any of those edits. The next theme zip deploy would have replaced both files and quietly wiped the new ad slots. Nothing would have errored. The homepage would just have lost its ads, and nobody would have known why.
My agent noticed the mismatch: the other agent’s changes were live on the server, and its own copy didn’t have them. Live and source had drifted apart, and it flagged that before anything else got deployed.
Pulling the live files back into source
My agent can’t open a shell on that server, and I prefer it that way. What it could do was read the files through a managed nginx panel’s raw file view. So it copied both files out that way, through the clipboard, and saved them over its local copies.
It was upfront that this copy is not byte-exact. Going through the clipboard stripped the indentation, and whitespace or line endings may differ from the server. So it did the checks that still mean something on a copy like that:
- A syntax check.
php -lon both files came back clean. - A content check. Both files contained the new top slot, the feed slot and the ad wrappers.
- A note saying where the truth lives. The sync notes now say the live server files are the source of truth, and they have to be pulled before any theme zip deploy.
Checking the new slot didn’t collide with anything
This was the check I’d have skipped. The site has another feature, a front-door block for one of its tools, that injects itself just before the homepage’s first hero section. It finds that section by looking for its opening tag as a marker string. A new ad slot printed in the wrong place could easily have landed between the marker and the block, or pushed the block somewhere odd.
My agent read both sides. The injected block goes in before the first hero section, and the new top slot also prints before that first hero section, so the order should be: top ad, then the injected block, then the hero. Then it checked what visitors actually get, with a signed-out request to the live homepage:
# Simplified. Which of the three blocks comes first in the served HTML?
curl -s https://example.com/ \
| grep -o -E 'ad-slot--top|class="tool-door"|<section class="hero"' \
| head -3
# expected order, which is what the live page served:
# ad-slot--top
# class="tool-door"
# <section class="hero"Served order matched: top ad, injected block, hero. No conflict. It also confirmed it had no theme edits of its own to the hero or the ad layer waiting to go out. Its recent homepage work had gone into a small must-use plugin, not the theme. And it noted two things to keep as they were: the visibility check on both new slots, and the top slot staying ahead of the first hero section.
A rollback, one line per step
The other agent’s edits already came with backups. My agent wrote the rollback into its sync notes, one line per step, so either of us could run it without thinking:
# Simplified. Run from the theme folder on the server.
cp functions.php.bak-YYYYMMDD-HHMMSS functions.php
cp front-page.php.bak-YYYYMMDD-HHMMSS front-page.php
wp option update site_ad_profile_home 0
# then purge the page cache
# Or switch off a single slot and keep everything else:
wp option update site_ad_top_on 0
wp option update site_ad_feed_on 0The per-slot switches are the part I like most. If one slot misbehaves, I don’t have to roll back two large hand-edited files to get rid of it.
The rule that came out of it: stop deploying the theme from the copy
Syncing once fixed that evening’s problem. It didn’t fix the pattern. The live theme was edited again on 9 October and again on 11 October. Every one of those edits would have made the local copy stale again, and every theme zip would have been another chance to undo someone else’s work.
So the standing rule changed. No theme files get deployed from the local copy anymore. The agent with server access runs every server change from a written runbook. New behaviour goes into small must-use plugins instead of the theme, and nothing gets deleted. The clipboard copy was never going to be a safe thing to deploy from anyway. Now it doesn’t have to be.
The AI part of this isn’t that an agent wrote some PHP. It’s that two agents were editing the same self-hosted site, and the one without server access noticed it was holding an out-of-date copy before acting on it. Then it proved the live result was correct from outside, and wrote the way back down. Then the process changed so the same drift can’t cause the same accident again.
Ship checklist
- Before any deploy, ask: has anyone, human or agent, edited the live files since the source copy was made?
- Read other agents’ handoff notes for any mention of live file edits.
- Pull live changes back into source before building a deploy artifact.
- If the pull isn’t byte-exact, say so in the notes, and at least run a syntax check like
php -l. - Grep the pulled files for the new markers, so you know the edits really came across.
- Check for features that inject at the same spot, and confirm the served order with a signed-out request.
- Keep timestamped backups next to hand-edited files.
- Write the rollback one line per step, with a per-feature off switch where you can.
- Once a file keeps getting edited live, stop deploying it from a copy.
- Put new behaviour in small must-use plugins, so agents add files instead of rewriting shared ones.
FAQ
Why not just make the server the only copy and edit it directly?
That’s more or less where I ended up for the theme. The agent with shell access makes server changes from runbooks, and the local copy is for reading, diffing and planning, not for deploying. The difference is that changes are written down first, so the other agent can see them.
Why was a non-byte-exact copy acceptable at all?
It was good enough to keep the source honest about what the live files contain, and to stop a zip deploy from wiping them. It isn’t good enough to treat as the real file, and the notes say so. That’s part of why theme deploys from the copy stopped.
Isn’t a must-use plugin just moving the problem somewhere else?
Not really. A small must-use plugin is one new file that one agent owns, with an obvious rollback: remove the file. Two agents adding separate small files rarely step on each other. Two agents rewriting the same large theme file regularly will.
Where did the AI actually help?
It noticed the drift before I’d thought about the next deploy. It checked a placement clash I wouldn’t have looked for, proved the order from the live HTML, and left a rollback either agent can run.
Closest related Builders notes?
I Gave My AI Agents One Shared Changelog With a Rollback Line is how my agents keep track of each other’s changes. My AI Agent Caught My Sign-Up Page Being Served From Cache is the must-use plugin pattern in action, and I Let an AI Agent Patch a Theme With a Tiny Reversible Plugin is where the small, reversible file habit started.