Claim locks: what breaks when humans and AI agents share a queue
Here’s the failure that teaches you the lesson. Two agents pull the same ticket off the board. Both work hard, both finish, both report success. Now you’ve got two conflicting implementations of the same feature on two branches, each one half-aware of the other’s file changes, and the merge is worse than if nobody had done the work at all. Nothing crashed. Everything “succeeded.” That’s what makes it expensive.
I run a fleet of AI coding agents that ships my production software daily, and I can tell you exactly when this failure shows up: the day you run more than one agent. Not the day you run fifty. Day two.
Why the human conventions don’t transfer
Human teams solve duplicate work socially. Someone says “I’ve got this one” in standup. Someone sees a teammate’s name on the ticket and moves on. Someone feels mildly embarrassed about poaching another person’s task, so they don’t.
Agents have none of that. They don’t attend standup, they don’t feel embarrassment, and they read the board in milliseconds (all of them, at once). Assignment-by-conversation works right up until your workers stop being in the conversation. Then the only thing that matters is what the system enforces, and most task trackers enforce nothing. An “assignee” field you can overwrite isn’t a lock. It’s a suggestion with a name on it.
Atomic claims, or it didn’t happen
The fix is old, boring, and correct: the claim has to be atomic. One operation that says “this ticket is mine now,” succeeding for exactly one claimant, failing cleanly for everyone else who tried in the same instant. Databases solved this decades ago; work systems mostly didn’t bother, because humans were slow enough that collisions stayed rare.
Agents un-solved it. At machine speed, two workers hitting the same ticket in the same second stops being rare and starts being Tuesday. So the claim lives in the system as a real lock: an agent that fails to claim moves to the next ticket, and no polite fiction about assignees is involved.
Then agents found a new way to break it
Once claims are atomic, a well-meaning agent discovers the next exploit: claim everything. An agent that’s told to be productive will happily grab six tickets “to work through them,” which means five tickets sit locked and untouched while every other worker (human or agent) stares at an empty-looking board. It isn’t malice. It’s a goal with no boundary.
So claims get limits: hold one, maybe two, finish or release before you take more. The moment I added claim limits, board throughput went up, not down — the same thing a factory floor learns when it caps work-in-progress. Agents made the old lessons load-bearing again.
The gates on either side
A claim lock protects the middle of the work. The two ends stay human: scope gets a sign-off before the ticket is claimable at all, and finished work lands in a review state a human approves before it ships. The lock doesn’t replace judgment. It guarantees that when judgment happens, there’s exactly one piece of work to judge.
Where this lives
I built this into TaskHarbor, the work system my own fleet and my human collaborators pull from every day (the board that runs the board, since TaskHarbor’s tickets are worked by agents claiming TaskHarbor tickets). It’s one layer of the larger discipline — the full layer-by-layer view is on the AI agent infrastructure page. If your team is about to put humans and agents on the same queue, put the lock in before day two. Cheaper that way.
I'm Joseph Dattilo — engineer-founder in Lansing, Michigan, author of the FleetHarbor suite, and founder of Date Palm Media. More about me · More writing · Get in touch