The version-skew incident covered earlier in this series happened in the middle of a larger piece of work: bumping a shared plugin dependency across a WordPress VIP-style multisite network, validating it, and rolling out five accompanying index migrations. That whole sequence — composer bump, push to a validation branch, catch the branch drift, resolve it, run the migrations, open a documented PR — ran as a single supervised agent loop rather than six manually-prompted steps. Worth writing up on its own, because the interesting part isn’t the dependency bump. It’s what made it reasonable to let an agent carry a multi-step infrastructure task without a human re-prompting at every step, and where the guardrails still had to stay manual.
What "the loop" actually did
A self-pacing agent loop was set to check on the work and continue the plan if it wasn’t already finished — not a fixed-interval poll, but a loop that re-engages when there’s something to act on and stops itself when the task is genuinely done. Across its run:
- Bumped the shared plugin dependency via
composer update. - Pushed the bump onto a validation branch to sanity-check it before touching
main. - Discovered, from the validation run rather than from any prior assumption, that the validation branch’s existing dependency version was further behind than the diff being applied accounted for — the version-skew problem covered in the earlier post.
- Resolved it by replacing the dependency tree wholesale rather than patching around the gap, then confirmed a clean load with zero warnings before proceeding.
- Ran all five index-migration commands against the validation environment, with an explicit
statuscheck both before and after, across every site in the network. - Opened a PR against
mainwith the exact commands documented for whoever handles the production deploy.
None of these steps individually needed a human in the loop to decide how to do them — each one has a clear, checkable success condition (does the dependency load cleanly, does the index exist, does the PR contain the right diff). What they needed a human for was different: deciding whether to proceed at all past certain checkpoints, and giving explicit go-ahead before anything became visible outside the working branch.
Where the loop stayed autonomous
The version-skew discovery is the case worth dwelling on, because it’s exactly the kind of thing that would traditionally stall a scripted automation pipeline — a composer update script with no branching logic would have either failed opaquely or, worse, "succeeded" while silently leaving the plugin in a broken partial state. An agent evaluating the result at each step, rather than a fixed script assuming success, caught it: the post-bump load produced warnings that didn’t match the expected clean state, which was enough signal to stop, investigate the actual branch version instead of trusting the diff, and change approach — full-tree replacement instead of a narrow diff — without needing a human to notice the anomaly first.
That’s the practical case for a loop over a fixed script here: the failure mode wasn’t a clean error code, it was a subtly-wrong state that only shows up if something is actually checking the result against what "correct" should look like, not just whether the previous command exited zero.
Where it stopped and asked
Two points in the sequence were deliberately not autonomous. Before pushing the branch and before opening the PR, the loop paused for explicit confirmation — because both actions are visible outside the working environment: a push updates shared branch state other engineers might see, and a PR is a public artifact. Everything upstream of those two points — running composer, inspecting warnings, running index commands against a non-production validation environment — stayed inside the loop’s own judgment, because none of it was visible or consequential until one of those two gates.
The same discipline applied to the actual index migrations: every one of them ran with an explicit --dry-run=false requirement rather than a default-to-execute flag, and every one targeted a validation environment first, never production directly. The loop had latitude to decide when to run a command; it did not have latitude to skip the flag that makes "this actually mutates state" an explicit, visible choice in the command itself.
What made this a reasonable task to loop
Not every multi-step task is a good candidate for this. The ones that are share a few properties, present here: each step has a checkable, mechanical success condition rather than a subjective one; the risky steps are a small, identifiable subset of the whole (push, PR) rather than scattered throughout; and the loop’s own output — a documented PR with exact commands for the deployer — hands off the actual production change to a human rather than the loop reaching all the way to production itself. The loop compressed a sequence of individually-simple, mechanically-checkable steps into one supervised run. It did not compress the two decisions that were never mechanical in the first place.
The generalizable version
- A multi-step infrastructure task is a reasonable candidate for an autonomous loop when each step has a checkable, mechanical success condition — not when success is subjective or requires judgment a script can’t express as a check.
- The value over a fixed script isn’t speed, it’s handling the failure mode a script can’t: a step that "succeeds" by exit code while leaving the system in a subtly wrong state. That needs something evaluating the actual result, not just the return code.
- Keep the boundary between "the loop’s judgment" and "requires a human" at the point where an action becomes visible or irreversible outside the working environment — a push, a PR, a production deploy — not at some arbitrary point earlier in the sequence.
- Explicit-intent flags (
--dry-run=falseover a default-to-execute) matter as much inside an agent-run sequence as in a human-run one. Don’t relax a safety default just because a loop is running the commands instead of a person typing them. - The loop’s actual deliverable, for anything touching production, should usually be a documented, human-reviewable artifact — a PR with exact commands — rather than the loop reaching all the way to the production system itself.