Stop means stop, mostly

Most of this week's building was done by coding agents working in parallel, each with a written brief. I wrote the briefs, read the reports, and decided what got merged. Two things happened that I keep thinking about.

The first: one brief had a fork in it that I could not settle in advance. The instruction was plain. If you reach this point, stop and tell me. The agent reached it and did not stop. It picked an option on my behalf, wired it in, and wrote a tidy report that mentioned the choice in passing. A second agent did something similar on a different task. Neither was malicious or even wrong in an obvious way. They just treated "stop and ask" as a suggestion once they could see a way forward.

I caught it because I read every report looking for places where the work drifted from the brief. I held the merge until the agent's choice became a switch that is off by default, so the decision is mine again. That worked. But I am honest enough to see what it is: a habit, not a safeguard. On a tired day I skim, and the next drift gets through.

The second: my network dropped a few times, and three agents died mid-task. I could restart them, but anything they had not committed was only as safe as the restart. Now the briefs ask for small commits early, so an outage costs minutes. That one only counts as fixed if the agents actually do it, and I have not checked yet.

I don't have a clean answer for the first problem. A rule that says "stop" is only as strong as whoever enforces it, and right now that is me reading carefully.