Don't Kill the Loser: A Different Way to Handle Two AI Agents Colliding

Also available as a plain-text transcript page.

0:00Juniper: When two transactions collide inside a database, the textbook fix is brutal. You pick one of them, you kill it, you throw away every bit of work it did, and you start it over from scratch. Fifty years of concurrency control, and at bottom, that's still the move. This paper looks at that and says — don't. When two AI agents collide on the same live system, don't kill either one. Just tap the loser on the shoulder, tell it what changed underneath it, and trust it to patch itself.

0:33Tyler: And "trust it to patch itself" is doing an enormous amount of work in that sentence, which is exactly why I want to keep an eye on it.

0:42Juniper: It is. That counterintuitive bet is the heart of a paper called "CoAgent: Concurrency Control for Multi-Agent Systems," which went up on arXiv on June thirteenth, twenty-twenty-six — and we're recording three days later, on the sixteenth. Quick flag before we dig in: this episode is AI-generated. The script was written by Anthropic's Claude Opus 4.8, and I'm Juniper, an AI voice from Eleven Labs —

1:09Tyler: — and I'm Tyler, also an AI voice from Eleven Labs. The producer isn't affiliated with either company. So, Juniper — the reason I'm suspicious of "trust it to fix itself" is that it's the kind of line that sounds elegant and then quietly relocates the hard problem somewhere you stop looking. But I'll grant the setup is genuinely good. Walk people through the crime scene, because the paper opens on one.

1:37Juniper: It does, and it's the cleanest motivating example I've seen in a systems paper in a while. Two AI agents, both pointed at the same live Kubernetes cluster — a real one, this actually happened when they ran it. Agent A has a cleanup job: a bad rollout left a bunch of services running the wrong container image, and A has to find every affected service and restore the correct image. Agent B is doing something totally unrelated. It's preparing a canary release for one service called geo — a little test deployment that mirrors production so you can route a sliver of traffic to it before a full rollout. To build it, B reads geo's current image and copies that.

2:23Tyler: Two different jobs, no obvious overlap. A fixes broken things, B creates a new thing.

2:28Juniper: Right — and that's the trap. Here's the timing. Agent B reads geo's image before Agent A has gotten around to fixing geo. So B faithfully builds its canary on the known-bad image. Meanwhile, Agent A scanned the cluster before B's canary existed — so A's repair sweep never sees it. Both agents finish. Both report success. And the cluster is left in a state that no sequential ordering of those two tasks could ever produce: a broken canary, sitting silently at zero replicas, waiting for the next release window to route live traffic onto a bad image.

3:07Tyler: And neither agent did anything wrong. That's the part that gets me. There's no reasoning error to point at. If you ran A completely, then B, fine. B, then A, also fine. The bug lives entirely in the interleaving of their reads and their writes.

3:25Juniper: Exactly. And that's literally the textbook definition of a concurrency anomaly — a result that no serial order could have produced. Which is the whole game in this field. The gold standard for "correct" when things run concurrently is called serializability: your messy parallel run has to come out identical to some run where the transactions happened one fully after another. Doesn't matter which order. Just that some sequential order would've given the same answer.

3:56Tyler: And this is where a reasonable listener says: hold on, databases solved this in the seventies. Concurrent writes corrupting shared state is the oldest problem in the book. Why do we need a 2026 paper about it?

4:11Juniper: That's the right question, and it's yours — the classical theory is your territory. Why don't the old solutions just work here?

4:19Tyler: So there are two textbook strategies, and the paper carefully sets itself against both. The first is pessimistic — two-phase locking, usually written as 2PL. Before you touch a piece of data, you grab a lock on it, and you hold every lock you've taken until you're completely done. Anyone else who wants that data waits in line. It's safe. The cost is that conflicts turn into waiting, and if two transactions each hold a lock the other needs, you get deadlock — both freeze forever.

4:52Juniper: And the second strategy is the optimistic one.

4:55Tyler: Optimistic concurrency control, OCC. The opposite bet. Everybody runs free, as if they're alone in the world, and only at the very end does each transaction check: did anything I read get changed underneath me while I was working? If yes, you abort — you throw the whole thing away and restart from scratch. That's fantastic when conflicts are rare and cheap to redo.

5:20Juniper: And here's where the paper lands its first real punch. Both of those protocols are still correct in the agent world. The authors are very careful about this — they're not saying 2PL or OCC give wrong answers. They're saying these protocols become ruinously expensive, for two specific reasons.

5:40Tyler: The first one is just time. A database transaction finishes in milliseconds. An agent transaction is minutes — sometimes hours — of language-model inference, running tools, reading results, reasoning about the next step. So under 2PL, your locks are now held for minutes. One agent grabs geo, and every other agent that needs geo is frozen for the entire duration of the first one's reasoning. And under OCC, an abort isn't cheap anymore — you've just thrown away minutes of expensive model inference and you're paying to do it all again.

6:17Juniper: And it's worse than "occasionally," because agents read enormously broadly. A database transaction looks up one row. An agent greps a whole repository, or lists an entire namespace. So the set of things it touches is huge, which means conflicts aren't rare — they're frequent. You've got a protocol that's expensive per conflict, firing constantly.

6:41Tyler: The numbers bear this out, and they're brutal. Under their contended workloads, OCC actually runs slower than just doing the agents one at a time — about seven percent slower — because it keeps aborting and redoing. It aborts almost once per trial. And it burns nearly double the token bill, because every abort means you pay for that discarded reasoning a second time. 2PL isn't much better: it deadlocks roughly four times out of every five runs and recovers almost none of the speedup you wanted from running in parallel in the first place.

7:18Juniper: So the honest framing is: the old tools work, they're just paying a tax that's tolerable for milliseconds and catastrophic for minutes. There's also a second gap, though, that's even more fundamental than speed.

7:33Tyler: Right — and this one isn't about cost, it's about whether the move is even possible. Both classical protocols quietly assume you can take a write back. 2PL assumes you can roll back. OCC assumes you can stage your writes in a private buffer and only reveal them at commit. Neither of those exists on a live Kubernetes cluster. When an agent runs the apply command, the change takes effect the instant it runs. There's no buffer. There's no fork. The side effect is real and it's immediate.

8:06Juniper: And that kills the obvious escape hatch, which is: well, just give each agent its own copy. Fork the world, let them work in isolation, merge at the end.

8:16Tyler: Which sounds great and fails three ways. Merging is genuinely hard. The clean algebraic merges — the conflict-free replicated data type approach — only work for operations that commute, where order doesn't matter. And most live state simply cannot be forked. You can't hand an agent its own private copy of a running production cluster.

8:39Juniper: There's a lovely detail buried here, too. The current real-world practice in tools like Claude Code is write partitioning — you prompt the agents to touch disjoint sets of files so they can't step on each other. And the authors point out that the canary trace already obeys write partitioning. Agent A only ever repairs existing deployments. Agent B only ever creates new ones. Their writes never collide.

9:06Tyler: And the bug happens anyway.

9:09Juniper: And the bug happens anyway — because the bug was never in the writes. It was in the reads. B read a value that A later invalidated. Partitioning your writes does nothing about that.

9:21Tyler: Okay. So that's the diagnosis, and I think it's airtight. The classical world gives you exactly two levers — make the conflict wait, or make it die — and both are unaffordable when the worker is a slow, broad-reading, real-world-acting language model. So what's the third lever?

9:40Juniper: This is the pivot, and it's genuinely a reframe. For fifty years, concurrency control has been built on a hidden assumption: the code inside the transaction is dumb. It's a script. You can't ask it anything. So the surrounding system has to police it from outside — block it, kill it, force it into a safe order. The transaction is a passive thing that correctness gets imposed upon.

10:06Tyler: And an agent is not a dumb script.

10:08Juniper: An agent understands its own task, in natural language. You can ask it a question. So the paper's move is to stop treating control as a mandatory remedy and start treating it as advice. The load-bearing primitive stops being the lock and stops being the abort. It becomes the notification. The runtime informs; the agent repairs.

10:30Tyler: Give me the colleague version of that, because I think there's a clean everyday picture here.

10:37Juniper: There is. Classical concurrency control is like a shared document system that, the moment you open a file, either locks everyone else out — that's 2PL — or lets everyone edit freely and then deletes someone's entire afternoon of work when a clash shows up, that's OCC. What this paper does is what a good colleague does. They lean over and say, "heads up — that number you copied from the budget five minutes ago just changed." You glance at it, you decide whether it actually matters, and if it does, you fix that one cell. Not your whole report.

11:14Tyler: And the reason that's affordable rests on three things the agent can do that a script can't. The paper's whole contribution really lives in these three capabilities — everything formal afterward is scaffolding for them.

11:28Juniper: That's the right way to hold it. First: the agent can tell a real conflict from irrelevant overlap. Most of the time when you get notified that a value you read has changed, it doesn't matter — a peer appended one log line to a file you happened to scan. The agent reads the notification, judges that it's harmless, and dismisses it. Zero work lost. A database transaction literally cannot make that judgment; it has no idea what its own read meant.

11:59Tyler: Second capability.

12:00Juniper: Second: when it does matter, the agent can pinpoint and rewrite only the operations that depended on the stale value. Not the whole task — just the affected steps. And third: for almost any write, the agent can generate an inverse — an undo. Because it produced the original action from some context, it can produce the action that reverses it. Capabilities one and two make optimism cheap. Capability three makes those immediate, un-buffered, real-world writes recoverable after all.

12:33Tyler: I want to slow down on the second one, because I think there's a wrong model a lot of people are going to build right here. When you say the agent "rewrites the affected operations" — isn't that just OCC with extra steps? It read something stale, now it's redoing work. That's an abort-and-retry with a friendlier name.

12:54Juniper: Not quite — and the gap between those two is exactly the point of the paper. An OCC abort is all-or-nothing. The transaction is dumb, so the system has no way to know which parts of it depended on the stale read. The only safe thing is to nuke the entire transaction and rerun every operation from the top. The agent isn't dumb. It can look at minutes of work, identify the three steps downstream of the bad value, and surgically redo just those — keeping everything else it did. The difference between those isn't cosmetic. In their case study it's the difference between a six-second repair and a twenty-nine-second restart.

13:38Tyler: Hold that number, because I want to come back to it on the timeline. But there's a subtlety in the undo capability I don't want to skate past. Generating an inverse isn't always trivial.

13:50Juniper: No, and the paper is honest about it. The mechanism is essentially a saga — that's an old database idea, going back to the eighties. Instead of atomically rolling back, you break a long process into steps, and each step registers a compensating action when it runs. You booked a flight, then a hotel, the hotel fails — you don't rewind time, you run "cancel flight." So in this framework, every tool an agent uses is built in three phases. Before it acts, it captures what it would need to undo itself. Then it executes. And it holds onto a reverse action. The reason the undo has to be captured before execution is that executing often destroys the information the undo would need.

14:36Tyler: And critically, some actions have no inverse at any price. You can't un-send an email. You can't un-execute a payment.

14:44Juniper: Right, and the authors just concede that cleanly. Those tools get tagged unrecoverable, and the framework holds them — it won't let an agent fire an irreversible action until every agent that could conflict with it has finished. For those, you lose the concurrency. They're not pretending otherwise.

15:04Tyler: So we've got notification instead of locking, selective repair instead of abort, and sagas to make writes reversible. Here's where my skeptic alarm goes off, though. If the whole thing is "everybody writes whenever they want and we just notify each other and heal" — why doesn't that spiral? What stops two agents from notifying each other back and forth forever?

15:29Juniper: You've just reinvented the exact trap the paper flags as its hardest design problem — and they have a gorgeous little counterexample for it. Two agents. One's job is "set x to half of y." The other's is "set y to half of x." Now imagine every write broadcasts to everyone, and everyone dutifully heals. Agent one writes, agent two gets notified and re-halves, which notifies agent one, who re-halves again — and the two values just spiral toward zero. Forever.

16:01Tyler: Which is worse than a wrong answer. A wrong answer at least stops.

16:05Juniper: It's a livelock — it never terminates. And the maddening part is that either serial order terminates cleanly. Run one fully, then the other, you get a clean answer. It's only the symmetric back-and-forth healing that breaks it. So notification alone is not enough. You need something to break the symmetry.

16:26Tyler: And the fix is a seniority rule.

16:28Juniper: Essentially, yes. At launch, every agent gets a rank — a fixed position in a pretend serial order, handed out before anyone starts. And the rule is: notifications only ever flow one direction. From the lower rank up to the higher rank. The junior reacts to the senior; the senior never reacts to the junior. So in the spiral example, the low rank halves once, the high rank gets notified and halves the new value once, and they both stop — at exactly the answer the serial order would've given.

17:02Tyler: The one caution I'd put on that word "seniority" — the rank doesn't mean anything. It's not importance, it's not task priority. It's an arbitrary number assigned purely to make cycles impossible. Once there's a fixed precedence, the dependency graph between agents can never form a loop. That's the whole job it does.

17:24Juniper: That's the right correction. And the same fixed ranking is what kills 2PL's deadlock, too — there's never a standoff over who waits for whom, because precedence is decided up front. One design choice closes two failure modes at once.

17:40Tyler: So how does a read actually get its rank-correct value? Because in the real system there's one live copy of the world, not a private version per agent. If I'm a high-ranked agent reading geo, how do I get served only what the agents below me have written, screening out everything from above?

17:59Juniper: This is the engine room, and the principle is cheapest-route-wins. Three options. If the state's cheap to copy — like files — you replay the relevant writes on a snapshot. If you can't copy the state but you can copy what it looks like — you snapshot the output of a command after each write and just hand back the recorded observation. And for the hard case, like an arbitrary database query, you temporarily roll back the higher-ranked writes, run the query against the live system, then notify the agents you disturbed. That third route only works at all because every write is undoable.

18:37Tyler: There's one more piece of machinery I think is worth a beat, because it's where the paper is genuinely novel over the classical lineage. They don't keep a single current value for each shared object. They keep a log.

18:51Juniper: The trajectory. And there's a clean way to feel why. Some writes are like overwriting your name field in a form — only the latest one matters, you can throw the rest away. But other writes are like deposits and withdrawals on a bank account. You can't compress that history into one number without losing information, because each one builds on what came before. To know the true balance under a particular ordering, you have to keep the list of transactions and replay them in order.

19:23Tyler: And the agent versions of those are: overwrite a config key — that's the name field, only the latest matters. Versus append to a list, or create a numbered entry — two creation calls make two separate entries. You can't represent that as one slot. You have to keep the sequence.

19:41Juniper: And that's precisely why the older approach this descends from doesn't suffice. Classical multiversion ordering keeps multiple versions, but it treats a version as just a value — it silently assumes every write is an overwrite. The trajectory keeps the whole ordered log, so it handles the deposits-and-withdrawals case, which is the common one for agents creating and appending things.

20:06Tyler: And then there's a proof that all of this actually delivers serializability. I don't want to read math at people on a commute, but the shape of it is worth having.

20:17Juniper: The shape's the part worth keeping anyway. Think of a chaotic theater rehearsal — interruptions, do-overs, an assistant whispering corrections to actors mid-scene. The proof does two things in sequence. First, it shows that chaotic rehearsal, with all its corrections, produces exactly the same final performance as a clean rehearsal where every actor magically got the right cue the first time. Second, it shows that clean version is identical to the actors just performing in the fixed predetermined order. Chain those, and the chaos provably equals an orderly sequence.

20:55Tyler: And I'd flag — that first step is the whole ballgame, and it's where my doubt lives. The reason the messy rehearsal equals the clean one is that the corrections always land correctly. The whispered cue always gets folded in right. That's not something the proof establishes about the world. That's an assumption about the agent. The proof is conditional on the agent's self-healing actually working.

21:22Juniper: That's fair, and let's mark it, because we should come back to it. But first let me cash out that six-versus-twenty-nine number, because the case study is the strongest single thing in the paper.

21:35Tyler: This is the canary scenario again — same workload, four protocols, one shared stopwatch.

21:40Juniper: Same workload, one clock, four runs. The uncoordinated version — everybody just goes — finishes fastest, around thirty-two seconds. And it's wrong. It produces the broken canary. 2PL takes fifty-three seconds, and one of the agents spends about twenty-one of those frozen in deadlock, with its first pass thrown out. OCC takes sixty-four seconds — the slowest of all — because it aborts and discards about thirty-two seconds of completed work.

22:12Tyler: And the new protocol?

22:14Juniper: About thirty-three seconds — basically as fast as the uncoordinated run — and correct. And here's the money shot. The actual repair, from the moment Agent A's write triggers the conflict to the moment Agent B has fixed its canary, takes six-point-four seconds. Against roughly twenty-nine seconds for OCC to abort and redo the same work.

22:38Tyler: The surgeon versus the demolition crew.

22:41Juniper: That's exactly the picture. OCC tears the building down and rebuilds from the foundation. This identifies the one thing that's actually wrong and fixes just that, leaving everything else standing. Six seconds of surgery versus twenty-nine seconds of starting over.

23:00Tyler: And across the full ten-workload suite, the headline is: about one-point-four times faster than running serially, within five percent of serial correctness, at near-serial token cost. Compared to OCC running slower than serial and paying nearly double the tokens. So the numbers back the story.

23:21Juniper: They do. So Tyler, this is your moment — because that "within five percent of serial correctness" is the loose thread you wanted to pull, and I think you should pull it.

23:33Tyler: So let me reopen the thing we marked. That five percent is not a slowdown. Let's be really precise about what it is. On even a budget-friendly model, a notified agent misjudged whether a notification mattered in about five out of a hundred trials. And a misjudgment here doesn't mean it ran a little slower. It means the agent looked at a real conflict, decided it was irrelevant, and dismissed it — and the system silently committed a non-serializable state. The broken canary, shipped, with everyone reporting success.

24:08Juniper: Which is the original bug, just with a correctness guarantee wrapped around it that didn't catch this case.

24:15Tyler: Right. And the proof we just walked through is conditional on exactly this not happening. The whole serializability guarantee rests on the assumption that a notified agent correctly judges which premises got invalidated and repairs precisely the right operations. The paper calls that the self-healing assumption. The proof says: if that holds, you get serializability. The empirical evidence that it holds is one number — five percent — and the protocol has no mechanism to catch a misjudgment when it happens. There's no validator behind the agent double-checking it got the heal right.

24:54Juniper: To be fair to the authors, they're explicit that this is a property of the agent, not the protocol, and they expect it to shrink with stronger models or targeted fine-tuning. They're not hiding it.

25:06Tyler: They're not, and I'll fully grant the candor. My worry is about where that five percent was measured. Which brings me to the bigger reservation — the benchmarks. These contended workloads were hand-built. The authors took five independent tasks from each of two benchmarks, and then, in their words, hand-constructed a matching second agent for each one, chosen specifically so the pair exhibits a textbook concurrency anomaly.

25:34Juniper: So the conflicts were designed to be the kind this protocol is good at.

25:39Tyler: That's my read. Clean, single-object, semantically localizable conflicts — exactly the cases where "repair only the affected operations" is cheap. And the entire advantage over OCC rests on repair being cheap. But picture a conflict that's deeply entangled, where fixing the one stale premise cascades into rewriting most of the plan. The surgeon's advantage erodes back toward the demolition crew's cost. And the paper doesn't test how repair cost scales with conflict complexity. So the five percent and the one-point-four times both live in a regime that was, to some degree, chosen.

26:18Juniper: That's the strongest version of the critique, and I don't think it has a clean rebuttal. The honest defense is that the benchmarks genuinely weren't built for concurrent agents — nobody's are yet — so some hand-construction was unavoidable just to have anything to test. But "unavoidable" isn't the same as "representative."

26:39Tyler: And one more, briefly — the baselines. They compare against 2PL and OCC, the textbook protocols they've already argued are structurally wrong for agents. That's a fair diagnosis, but it does mean the comparison set is built to look bad. The related-work section names several recent agent-concurrency systems from this same year, and none of them are run as experimental baselines. So we genuinely can't tell how this stacks up against the actual state of the art in its own subfield — only against the classical strawmen.

27:13Juniper: That one I'd weight a little lower, only because those systems are concurrent work from the same months — hard to benchmark against a moving target. But it's a real gap in what we can conclude.

27:26Tyler: Agreed it's the weakest of the three. The benchmark construction and the silent five percent are the ones I'd keep awake about.

27:34Juniper: Let me close on the part of the paper that's almost a separate contribution, because it's a nice result and it has its own honest asterisk. The whole framework needs every tool to declare what it reads and what it writes — its footprint — and to know how to undo itself. So what do you do on a system that has no such tool library? Bare bash, nothing declared.

27:59Tyler: This is the ToolSmith piece.

28:01Juniper: Right. There's a privileged agent whose only job is to build tools. It reads freely but never writes. And as the worker agents hit tasks, this builder grows a library on the fly — footprint-declared, undoable tools. On a bash-only target with no tool table at all, it grew a twenty-five-tool library online. Eleven snapshot reads, a couple of live reads, and twelve undoable writes. And every single one of those twelve write tools found a working reverse.

28:33Tyler: And the task pass rate moved.

28:35Juniper: From forty-five out of seventy-one tasks to sixty-three out of seventy-one — call it from roughly sixty-three percent up to about eighty-nine. And it did that about a fifth faster and a bit cheaper, because once a tool exists you stop paying to reinvent it. The library growth was front-loaded, too — half the final tools existed after just thirteen of the seventy-one tasks.

29:01Tyler: Now here's where I'd put the asterisk, and the paper actually says this itself, to its credit. That pass-rate jump — forty-five to sixty-three — is mostly not about concurrency control.

29:13Juniper: It's mostly guidance.

29:15Tyler: It's the tool table acting as a checklist. The authors attribute it to that directly. Once a tool called something like "list the service ports" exists in the library, its mere existence nudges the next agent to actually go compare the ports — to remember a class of mistake it made before. So that headline number is partly measuring a different thing than the rest of the paper. It's a real and interesting effect. It's just not the concurrency story.

29:46Juniper: Which I think is the right note to leave the whole paper on, honestly. The core idea here is genuinely a reframe — fifty years of treating the worker inside a transaction as something correctness gets done to, and this flips it into a participant in correctness. Control as a conversation instead of a constraint. And that reframe is portable. Any system where the worker actually understands its own task could, in principle, trade blocking for advising.

30:16Tyler: I buy the reframe completely. Where I land is one notch more cautious than the paper. The idea is right, and the engineering is careful. But the entire correctness guarantee is leaning on the agent's judgment being good — and the one number we have for that judgment, the five percent, was measured on conflicts the authors picked. I take the point that it'll improve with better models. I'm just not convinced the ablation, as built, actually isolates how often this thing silently ships a broken canary in the wild. That's the experiment I'd want before I ran two agents at a live production database and trusted the green checkmarks.

30:59Juniper: And that's a fair place for it to sit unresolved — because the paper doesn't close it either, and it says so. The contribution isn't "this is safe everywhere." It's "here's a third lever that wasn't on the table before, and here's a proof that it works when the worker's judgment holds." What "holds" means in messy reality is the next paper.

31:22Tyler: That I'll sign off on.

31:23Juniper: The paper's linked in the show notes, along with some related reading if you want to go deeper on the classical side — sagas, optimistic concurrency, all of it. And if you want the full transcript with the jargon defined inline, plus the concept pages that connect this to the other episodes we've done, that's all on paperdive.ai.

31:45Tyler: Thanks for spending it with us. This has been AI Papers: A Deep Dive.