On Ownership TokensHolder Is Not a Lock · It Is an Ownership Token

Once, two AIs edited the same task record at the same time. I only understood what had gone wrong after going back through the logs.

The file traced the course of a problem: what the symptoms were, how far the search for the root cause had gone, what had changed, and whether it had been verified. Claude decided the work had passed verification and wrote down its conclusion. Almost at the same time, Codex was still working from the old state it had read, believing the problem remained unresolved. There was no conflict at the git level—the edits touched different paragraphs and merged cleanly. But the resulting record contradicted itself: one paragraph said the work was finished, while another said the investigation was still underway. When we reviewed it a few weeks later, no one could tell which statement was fact, which was a guess at the time, and which was merely a task someone had not yet crossed off.

That incident changed how I understood “locks.” When people hear the word, they think, “No one else can touch this.” But that is not what collaboration between AIs is really missing. What is missing is an answer to this: who owns this task right now? So I stopped calling it a lock and started calling it an ownership token.

Locking the Authority to Update the Record, Not the File

A repository contains many files, and it can have many agents running in it. In theory, they can work at the same time as long as they do not change the same line. For most ordinary source files, that is indeed true.

But some files are different. A status file tracking how far a task has progressed, for instance, or handoff notes, or a spreadsheet being updated with results. Their contents alone are not the point. They carry an account of the work: what stage it has reached, who has finished what, which evidence holds up, and who should take over next.

When two agents touch these files at the same time, git is often not where things go wrong. The conflicts git can merge are small ones. The costly conflicts are between accounts of the work: one agent believes the task has been verified, while another thinks it is still blocked; one has written up the result, while another is still working from an old state. That is what went wrong in the incident at the beginning.

What the ownership token locks is this authority over the account of the work: at any given moment, only one party is entitled to revise its current version.

Uncommitted Changes Are an Incident Scene, Not Rubbish

When I used to see a pile of uncommitted changes in the working directory, my first instinct was to clear them away. They looked messy. Later, when working across agents, I began treating them as an incident scene.

An uncommitted file might contain the user’s own edits, unfinished work Claude left from an earlier stage, something Codex has just generated but has not verified, or changes made by an automated script. It is not noise. It is a signal of ownership: behind every change is the question, “Whose is this?”

So when taking over from another agent, the first step is to establish ownership before tidying anything up:

Do these uncommitted changes belong to the task I am about to do?
Are they included in the “changed files” listed in the handoff notes?
Do they fall within another agent’s area of responsibility?
Are they merely temporary local noise?
Should they go into separate commits, or be left out altogether?

This step is slow, slow enough to make you want to skip it. But it prevents a larger mistake: carrying on with someone else’s unfinished work as though it were your own context, or mixing your changes into theirs and committing the lot. The former leaves you making decisions based on unfinished work that is not yours. The latter makes it impossible to say who was responsible for that commit.

One Task Needs One Owner Throughout

We established a rule I firmly believe in: from opening a record to passing the final verification, the same agent holds ownership of the task throughout.

On the surface, this limits parallel work. What it preserves is traceability. An incident record contains the symptoms, root cause, fix, verification, corresponding commits, and final outcome. It is not a whiteboard for people to take turns scribbling on. It is a case file.

If A writes up the root cause, B documents the fix, and C records the verification, with no clear handoff between them, the record becomes a collage. Each passage reads well on its own, but no single person is responsible for the whole account. During a review, you cannot tell whether one sentence is a verified fact, another is an inference made at the time, or a third is simply a task that was never deleted. Three authors, zero owners.

The value of an ownership token is that it gives this case file a clearly identified author. The purpose is to keep the chain of responsibility intact, rather than to assign credit.

A Handoff Starts with a Commit and a Status Note

Handing work from one agent to another takes more than “Can you carry on with this?”

People need handoff notes when passing work to other people. AIs need them even more. The incoming agent has no feel for the previous conversation: it does not know which lines of discussion have already been rejected, which tests were only half run, or which conclusions the previous agent had confidently drawn while the context was still fresh, without actually verifying them. That illusion of confidence is the worst trap, because it reads exactly like a real conclusion.

A reliable handoff therefore needs at least three things.

First, a commit. It gives the code a fixed point that can be pulled, so the incoming agent has a definite starting point rather than a working directory that is still changing.

Second, a status note. State clearly what is done, what remains, where the work is blocked, how to reconstruct the working state, and what the incoming agent should do first.

Third, the transfer of the ownership token itself. Make it explicit that the token passes from one agent to the other: the outgoing agent lets go, the incoming agent takes it, with no gap in responsibility and no moment when both believe they hold it.

Leave out any one of these, and the next agent can only guess. The cost of a wrong guess is usually much higher than the cost of a proper handoff in the first place.

For Changing Information, “Needs Verification” Is More Honest Than False Precision

I also learned something subtle about status notes, taught by a real incident: do not pretend that information which can change is precise.

What kinds of information can change? The commit hash, how many uncommitted files remain in the working directory, how many rows in a spreadsheet still need processing, whether something has been deployed. These may be true when the handoff notes are written. But some time passes before the next agent actually takes over. The old session may have committed again, another batch of files may have been processed, and the details have probably changed.

I saw a real failure happen this way. The handoff notes said, “Four rows remain to be processed.” The incoming agent trusted that number and got to work, though there were already more than four. The session that wrote the notes had made further changes afterward, and the number had gone stale right away.

The most honest approach is to mark the value “needs verification” and include a command that checks the latest state, rather than insisting on filling in the value at the time. The message is: I know this number can change, so do not trust what I wrote; check the actual state again yourself. That sounds weaker than giving an exact number, but it is more reliable. Some uncertainty in engineering cannot be removed. It can only be marked honestly. Pretending it is settled leaves decisions resting on information that will go stale.

The incoming agent should therefore follow this discipline: pull the latest code, use that command to check whether the state described in the handoff notes still holds, and only then begin work. Any metadata that can change must be checked against the actual state. The snapshot in the handoff notes should not be taken as fact.

An Ownership Token Is an On-Duty Sign

Think of the whole project as a ship. The ownership token is like the on-duty sign hanging beside the control console.

It does not mean only that person may touch the buttons. It means that when an alarm sounds, everyone knows whom to find first. Before changing shifts, you must finish the ship’s log, explain the instrument readings, and then pass the sign over. You cannot simply call out, “I’m off.”

The real fear in a multi-agent system has never been that no one is working. It is that every agent is doing a little, while no one is explicitly responsible for knowing the current state of the work. Everyone thinks someone else is watching, and in the end no one is.

The ownership token brings this risk into view. It turns “Who owns this now?” from an unspoken understanding in a conversation into a written fact every agent can read. An unspoken understanding can break when a different agent takes over. A written fact does not.

This Friction Slows Collaboration but Reduces Rework

Ownership tokens, mandatory commits, status notes, establishing ownership before taking over: all of these slow collaboration down. Every step feels like adding grit to the process. I have found it irritating too, and wanted to get around it.

But I am increasingly willing to accept that grit. Frictionless collaboration between agents still has a cost. It simply pushes the bill further down the line, where it becomes more expensive: no one can find who made a change, the current state is unclear, the same problem gets fixed repeatedly, lessons are recorded in the wrong place, someone else’s uncommitted changes get swept into a commit. The contradictory record at the beginning was the price of saving that little bit of friction.

The point of all this is to make incidents traceable, rather than to make the process look good. Only when we can trace what happened does collaboration really work. Otherwise, it is merely several agents going about their own work in one repository, overwriting one another.

Translation log: translated from the Chinese original by Codex on 2026-11-03, 17:43–17:46 (US Eastern). Main thread GPT-6 Astra (gpt-6-astra), reasoning effort ultra; it spawned 1 sub-thread: 1 on GPT-6 Astra (effort ultra). Together they read 410,809 tokens (381,440 of them from cache) and wrote 7,138 (939 of them reasoning).