The Northgate integrations team uses an agent to add a timeout field to a client module of roughly 2,000 lines in a legacy payments service. The agent reads part of the module, then calls the Write tool on that path with a payload containing the new field and the surrounding class. Afterwards the module on disk is 40 lines long and the rest of the original code is gone, although the tool call itself reported success. What does that tell the team about the Write tool?
- AWrite replaces the entire contents of the target path with exactly the text supplied, so anything the agent did not include in that call is lost rather than merged with the existing file. Correct
- BWrite appends its payload to the end of an existing file, so the original body is still present further down and the visible 40 lines are only the newest section of the module.
- CWrite applies its payload as a patch relative to the last read of the file, so the missing body was dropped because the file on disk changed between that read and the write.
- DWrite refuses a payload larger than a single call allows, so the tool kept the first 40 lines of what was supplied and quietly discarded the remainder of the module before saving.
Why A is correct: Write is a whole-file operation, so its success signal means the supplied text was saved in full and nothing else survives; a targeted change to an existing file belongs to Edit instead.
Why B is wrong: Append is a familiar file operation and would explain a successful call, but the team can see that the earlier code is absent, so the payload clearly did not land after it.
Why C is wrong: Read-then-write races are a real hazard, which makes this plausible, but Write is not a patch operation and no concurrent change is needed to explain the loss.
Why D is wrong: Payload limits exist on some tools, so this reads as a reasonable failure mode, but the truncation here is of the original file rather than of the agent's payload.