My agents kept overwriting each other, so I gave them claims

In a bid to manage parallel agent sessions running on a single machine, a system was implemented to handle potential conflicts. Initially, it was believed that each session's separate repository would provide adequate protection. However, it soon became apparent that sessions often accessed resources beyond their designated directories.

Five instances of such conflicts were identified, all sharing a common pattern. The second session, upon launching, was already aware of the first session's progress - a fresh claim in the status file, a partially completed directory, and so forth. The issue stemmed from the fact that each project assigned claims in its own manner, recorded independently in its respective status files, without any method for another project to read these claims.

This problem was not a result of carelessness on the part of the model. Instead, under high contextual pressures, the agent treated other agents' presence as mere background noise. To address this, a protocol was introduced: before any session writes outside its own directory, it takes a claim - a small JSON file containing the target, the session's identifier, the purpose, the time the claim was taken, and the time of the last heartbeat. The file has five fields: target, holder, purpose, taken_at, and heartbeat_at.

The protocol includes four commands: take to acquire a claim before writing, renew the heartbeat during each writing turn, release at the end of the session, and refuse if another session already holds the claim and its heartbeat is recent. The refused session then queues a handover note, and the task is executed later, in order. The refusal is not an obstacle but rather an informative message: REFUSED: shared-config is claimed by session-a41 (heartbeat 41 seconds ago).

The most critical aspect of this system was verifying the guard itself. Early on, it was discovered that a flaw in the claim script would print 'claimed' even if the file creation process failed silently. This oversight could lead to sessions proceeding under the false belief that they held a lock that didn't exist. The fix was straightforward: using slugified names and ensuring the write operation was successful.

However, the lesson learned was more profound. When establishing safety mechanisms for agents, it's essential to test these mechanisms with the same level of scrutiny that one applies to the agents themselves. A healthy system, when at rest, should have an empty claims directory. Any claims that outlive their session should be the first indicators of potential issues.

The entire mechanism, which is less than sixty lines of shell code, serves not just as a tool but as a means to make the wrong move loud instead of silent.