Automation & Agents
Letting Two AI Tools Safely Share the Same Files: The Three-File Write-Lease Protocol
It is not about who is smarter, it is about only one party writing at a time. Put the rule in a file everyone reads before starting work; that beats finding a smarter referee.
The one idea that matters
When several AIs (or people) share the same files, the biggest danger is not “who is dumber” but “two parties writing at the same time with no idea what the other is doing”. The fix is not a smarter referee. Turn “who may write now and who may only look” into a file everyone reads first. The rule lives on paper, not in assumptions.
Steps
Step 1: Create a shared handoff folder
In your project or cloud drive, create a folder such as handoff and put three plain-text or Markdown files in it:
CURRENT-HANDOFF.mdWRITE-LEASE.mdCHANGE-LOG.md
Step 2: WRITE-LEASE.md holds one table only
| Field | Current value |
|---|---|
| State | One of four: A is writing / B is writing / both read-only / idle |
| Current writer | |
| Current read-only party | |
| Files allowed to change this round | List explicitly; anything not listed must not be touched |
Before acting, either party reads this file first to confirm it is their turn to write and that the file they want to change is on the allowed list.
Step 3: CURRENT-HANDOFF.md is updated with four things at each handoff
- What this round’s goal is
- What was actually changed
- What was explicitly not touched (the most important one, so the other side does not have to guess)
- What you ask the other party to verify, and what counts as passing
Step 4: Set one iron rule and put it at the top of all three files
At any one time, only one party may write to the same set of files. The other may only inspect read-only and reply “pass” or list specific problems. It must not fix anything itself.
The point is not technically locking the files (plain text cannot be locked). It is that both sides agree to follow it, so each side reads the file before acting, like signing in before work.
Step 5: The read-only party compares old and new sentence by sentence
If this round changed an existing rules document, the read-only party cannot just check that the new additions are correct. Compare the new version against the old one line by line, paying special attention to sentences that were in the old version and are gone from the new one. A rule that got silently deleted is the easiest to miss and the most likely to cause trouble, such as a safety baseline or a disclaimer.
Step 6: Log every change in CHANGE-LOG.md first
The format is simple: date | action | old path | new path | who changed it | how to roll back. When something goes wrong (a file vanishes, behavior differs from expectations) you can quickly trace which round did it.
Step 7: When handling sensitive data, add one more rule
If either party finds that the thing to be checked may be sensitive data, report only a boolean “exists or not” result. Never print the value or paste it into a shared file.
Traps you will hit
-
Using a command that lists everything to check existence. To confirm an environment variable or setting is still there, the instinct is to list all settings. If that container mixes in sensitive data, you print things you should not see, and once printed it cannot be taken back. Fix: always query “does this one name exist” only. When asking an AI, say explicitly: “Only confirm whether this name exists. Do not list anything else.”
I want to confirm whether a certain setting (for example an environment variable or registry entry) currently exists, but I do not want to see any actual content, only whether the name is there. Which command should I use so I do not accidentally print the whole list or other sensitive content?
-
The verifying party fixes the problem on the spot. The other side then has no idea what changed and the handoff information breaks. Even if it feels small, hold back, report the problem only, and let the writing side decide how to fix it.
-
Looking only at what was added, not at what is missing. When trimming or restructuring a rules document, it is easy to delete a whole rule while simplifying wording. Compare old and new line by line before and after the change instead of looking only at the added lines in a diff.
-
Accidentally printing sensitive data and choosing to play it down or stay quiet. The right move is to say immediately and completely what kind of thing was printed and where, so the other party can decide whether to revoke or rotate it at the source. Delay only keeps the risk window open longer.
Takeaway
When several AIs or people share the same files, do not count on them developing an understanding on their own. Write a file that says “who may write now, who may only look” and make everyone read it before starting. That beats a smarter tool.
Universal rescue: how to ask an AI when you are stuck
I am setting up a protocol for several AI tools to share files, and I am stuck at [the exact step]. The error or behavior is: [paste the actual error or describe it]. My tool is [tool name and version, or “version unknown”]. Walk me through the troubleshooting step by step, and before acting, confirm with me whether each step could modify files I do not want touched.
This is part of an ongoing series of field notes and AI tool tests. To get the full SOPs and future posts, subscribe to the newsletter.
Support this work:Support on Ko-fi