Home / Everyday moves

Writing pitfalls: files, parallel edits and lost deliverables

A success report written by a sub-agent proves nothing about the real state of files, since it starts in an isolated context with no access to what the main agent has already read or written, and the only reliable proof remains a diff checked afterwards, not the text of the report.

A sub-agent starts with a context that is isolated and fresh on every call, except for a fork, which instead inherits the whole conversation in progress. It sees neither the main conversation's history, nor the skills already invoked, nor the files the main agent has already read. This isolation does not stop it from checking the disk itself: it has the same reading and execution tools as the main conversation, and can run a git diff or reread a file to check its own work. What is missing is an outside eye: a success report remains text produced by the same agent that has just acted, never an independent check, and nothing guarantees it matches a real write to disk until someone else has checked it.

The text report is not the proof

Documented good practice is to ask for a verifiable diff rather than trusting the text of the report. A diff shows the lines actually changed in a real file, a success report is only a sentence generated by the same agent claiming to have succeeded.

mkdir -p /tmp/demo-diff
echo "version initiale" > /tmp/demo-diff/avant.txt
echo "version modifiee" > /tmp/demo-diff/apres.txt
diff /tmp/demo-diff/avant.txt /tmp/demo-diff/apres.txt
# result: the changed line appears, the proof is in the diff, not in a sentence

A text report claiming that apres.txt has been updated adds nothing beyond this diff, and without it, nothing distinguishes a real write from a made up sentence. For a script passed from one shell to another, see the lesson on shell commands.

Two writes to the same file are never independent

Two edits sent together on the same file, whether by two sub-agents or by two calls of the edit tool in the same turn, apply one after the other on the content the tool finds at the moment it acts, never on two separate copies merged afterwards. The second edit can therefore fail to find the text it was looking for, because the first has already changed it. Sending the two edits in sequence, rereading the file in between, reduces this risk and makes each step verifiable on its own.

The same principle of verifiable proof applies to a long deliverable: content spanning several paragraphs that only exists in the displayed reply disappears with it as soon as the conversation continues. Writing it to a real file before displaying it, as with structured output in headless mode, guarantees it stays accessible independently of the conversation thread.

One temporary folder per agent

Agents launched in parallel that share a temporary folder overwrite each other's scripts and outputs. An agent sees neither the others' temporary files nor the corrections made outside its brief: it can validate stale content. The brief therefore names a folder of the agent's own for its scripts and outputs, and after each pass over a file the parent corrected, rerun the grep for the phrasings that were removed.

What the writing tools refuse

Since October 2026, Edit and NotebookEdit refuse a file in a legacy encoding such as Windows-1252 or Shift-JIS; Write can replace such a file, but it saves the new content as UTF-8 and the original encoding is lost: convert it first, Edit's refusal is a signal and not a failure. Read no longer reads binary files such as .xlsm, .parquet, .epub or .heic as text.