During a long session, a parks-department agent read summer_program_roster.csv early on, then spent many turns on other work and went through a compaction. The user now asks it to update three campers' session assignments in that file. What should the agent do first?

The source of truth for anything an agent is about to modify is the file on disk, not the conversation transcript. That distinction is easy to ignore while a read is still fresh in context, and it becomes decisive once a compaction has condensed those turns, which is exactly where this parks-department session now sits.

Re-reading summer_program_roster.csv re-grounds the edit in the file's current verbatim contents. Compaction leaves the gist without the precise rows, columns, or ordering, and the file is mutable in its own right, so other staff or processes may have changed it across the many intervening turns. One tool call is cheap next to writing three campers' session assignments into the wrong rows of a live roster.

Writing the rows from recollection is precisely the failure compaction creates, and the tokens saved are trivial against a corrupted roster; asking the user to paste the file is unnecessary work for them, since the agent still has file access and can simply read it again; and requesting a second compaction removes information rather than restoring it, making the recollection less reliable rather than more.

Exam caveat: re-reading defends against staleness but not against a concurrent writer, so for a file several staff edit the durable answer is a read-modify-write that confirms the content has not changed since the read. Operational check: modify the roster on disk between the agent's re-read and its write, and confirm the write is refused or re-grounded rather than silently overwriting the newer rows.