Commit before you brief the AI

I gave an AI agent a job against my repository. It returned a clean diff against the wrong world.

The agent had not ignored my work. My work did not exist for it.

This is how my fusion lane runs today. One household, one laptop, no clients. A worker claims a job, the system copies the repository into an isolated worktree, and the worker edits that copy. The isolation is useful: several agents can work without trampling the same files. The copy also draws a hard line through time.

Anything committed before the claim is inside. Anything still sitting in my working tree is outside.

The order I got wrong

I had made a change locally. Then I briefed the worker as if that change were part of the repository. Somewhere around the same moment, the job was claimed. I committed after the claim.

From my side, the sequence felt continuous: edit, explain, commit, receive. From the worker’s side, history stopped at claim time. Its worktree came from the last commit before mine. The brief referred to files it could not see.

That creates a particularly convincing failure. The worker reads every file available to it. Its reasoning is coherent. Its tests can pass. Its diff can be internally correct. Review still feels wrong because the reviewer and worker are standing on different revisions.

I first reach for prompts when an agent misses context. This one was not a prompt problem. More explanation would only describe the missing bytes more precisely.

The claim is the contract

I now treat a job claim like handing a physical folder across a desk. The pages inside at that moment are the job. Notes written afterward stay on my side unless I explicitly start another handoff.

The operating rule is short: commit before I brief.

That means the dependency lands first. Then I verify the commit contains it. Then the worker claims the task. The returned diff is reviewed against the exact base it received.

There are more elaborate fixes. A scheduler could refuse a dirty source tree. A job record could stamp the source commit and show it beside the result. A dependency could be expressed as another claimed job rather than an informal sentence. I want all three. The small rule works now because it aligns my mental timeline with the system’s real one.

Git did exactly what I asked. The agent did too. I was the stale component.

The wider fusion system, including its current stage and live operating record, is at senku.im/alive.

Update, 2026-08-20: the second of those three fixes shipped

I wrote above that a job record could stamp the source commit and show it beside the result, and that I wanted it. Four days later the same failure arrived twice in one evening, so it got built.

A job now records the commit its copy was taken from. A separate command reads a finished job and answers one question in four states: current, the repository has not moved. Behind, no overlap, it moved but not under the files this diff touches, so applying it is still correct. Behind with an overlap, and it names the files, which is the state that costs an hour. Unknown, which every job recorded before this change reports, and which never reads as current.

The overlap case exited zero when it was first built and I changed it. Behind-with-no-overlap really is fine. Behind-with-an-overlap is the exact condition described in this post, and a green light on it would have made the whole check decorative.

What it caught first was reassuring in a boring way: a job that returned an empty diff and refused its task. The record showed the base was current, so I knew the empty diff was an honest refusal rather than a stale copy. Before this, those two look identical from the outside.