Cohorts: What Changes When More Than One Team Is Working With Agents

Last week I wrote about one human and one agent, and the rule I use to decide how we work together: pick the collaboration model by who can detect the failure, and how late. The same week that piece went out, my engine’s session log recorded this, written by an agent at the end of its shift:

A PARALLEL CLAUDE SESSION IS COMMITTING TO THIS REPO. It touched CLAUDE.md and SESSION_LOG.md mid-session. Nothing was lost, but only because it was CHECKED.

Two agent sessions had been working in the same checkout for most of a day. One of them had written into the shared memory file that both branches were “CI green, polled to conclusion.” That was false. One build had failed on a cache race. The other session caught it because it went and looked at the CI run instead of trusting the note.

That is the subject of this piece. The single human-plus-agent pair is a solved enough problem that people are now running several of them at once, on the same codebase, sometimes on the same afternoon. The interesting failures have moved up a level. They are no longer about whether an agent can do a task. They are about what happens at the seam between two teams that each have agents in them.

What I mean by a cohort

A cohort is one human, plus the agents working under that human’s contract, on one repository. The contract is the set of documents the agents read before they touch anything: what is locked, what is in scope, what “done” means. I have written elsewhere about the mechanics of that, and a research paper on nine months of it is in preparation, so I will not repeat the protocol here. The point for this piece is that a cohort is the unit that can be given a task and trusted to report back on it.

My own record over the last month has at least five kinds of cohort touching a single game engine:

The engine cohort: me, a planning conversation in one window, and implementing agents in the engine repository. This is the one with more than 580 recorded sessions behind it.

The game cohorts: me and an agent in a separate game repository, using the engine as a customer would. Eight jam prototypes in thirteen days in August. A free-roam action game called The Reclaimer. A three-lane brawler built in one filmed take. Each of those is its own cohort, with its own memory and its own ledger.

The second-human cohort: a compliance platform for a regulated industry, where the company’s owner supplies the domain expertise and requirements, I supply the technical planning, and agents implement. Same operating system, different gates.

The publishing cohort: the one that wrote this article, running the same session protocol as the engine, with a log that records its own process failures.

And, unintentionally, two engine cohorts at once. That is the incident above.

The industry is heading here whether it has a name for it or not

I do not want to over-claim what is happening outside my own record. The one external data point I trust is Google’s DORA team, whose 2026 ROI report on AI-assisted development put it this way, as InfoQ summarised it: AI “creates localized pockets of productivity that are often lost in downstream chaos” when the organisational system around it is weak. The report’s list of what actually determines return is not a list of AI features. It is platforms, version control practice, automated testing, continuous integration, and small batches.

That matches what I see at small scale. Every one of my cohorts is a localized pocket of productivity. The question of whether the pockets add up to a project is decided entirely at the seams.

The seam is a ledger, not a conversation

Here is the thing I got wrong for the first several months, and only fixed because it kept hurting. I assumed that when the game cohort found a problem in the engine, the fix was to bring that knowledge across: paste the finding, share the context, let the engine cohort see what the game cohort saw.

That does not work, and the reason is the same rule as last week, scaled up. The game cohort can detect that the engine is wrong. It cannot say why. It feels the camera lag, sees the walk animation not play, notices the enemies teleport to the origin. The engine cohort can measure exactly why. It cannot feel any of it. Two cohorts, failing in different directions, exactly as one human and one agent do.

So the interface between them has to carry claims with measurements attached, and the receiving side has to re-verify every one before acting. In practice that is a file. Each game repository keeps a gap ledger: an append-only list where every entry has the same four parts. What the game wanted. What the engine offers today. The workaround the game shipped. The engine-side shape that would have made the workaround unnecessary.

Then the engine cohort does something I now consider the most important step in the whole system. Before a single gap becomes a sprint, it measures the claim against the engine source. The record calls this verify-before-charter, and the numbers on what it finds are not flattering to anyone.

The Reclaimer produced fifteen gaps. Verification found three were cheaper than claimed, two were worse than claimed, and one was simply wrong. The wrong one is instructive: the game had written a workaround for “scripts cannot destroy entities,” parking dead objects sixty units below the floor, because the engine’s own documentation advertised a binding that had never been written. The command existed. The doc caused the workaround, not the engine. Five of the seven projects on disk had the same workaround.

The brawler’s ledger went into triage as nineteen findings and came out as five sprints, and measuring moved four of them. One finding said the engine’s knowledge artifact did not carry field types. It did, and had all along. The agent that filed the claim had piped its own build output through a filter that kept the last eight lines, and the evidence it needed was above the cut. Two of the nineteen findings traced back to an agent hiding its own evidence that way. And triage found a fifth bug in the same family as the four the game had reported, one the game session never saw, sitting in the same function with a comment above it complaining about the third.

That last one is the whole argument in a sentence. The game cohort could not have found it, because nothing in the game misbehaved. The engine cohort would not have looked, without the ledger pointing at the function. Neither side’s claim survived contact with the other side’s instrument, and the project is better for it.

Closing the loop the other way

Verification runs in both directions, and the return trip is the one people skip.

When the engine cohort closes a sprint, the last artifact it writes is a walk-through for the originating game cohort to perform. Not a test report. A script of things to do in the running game, with a pass and a fail description for each step. The one for the brawler’s script-surface fixes opens with a line I keep coming back to:

The gates prove the parsers; only you can prove the FEEL.

The engine can assert that a ninety-degree yaw reaches the renderer. It cannot tell you the spark spray now points the way your effect wanted. So the sprint is not closed when the tests pass. It is closed when the game cohort walks the path and says so. In my record that is a named state, “pending operator ship-gate,” and sprints sit in it for days.

The full loop, then: the game cohort files measured claims; the engine cohort re-measures them before committing effort; the engine cohort ships a walk-through; the game cohort performs it. Four hand-offs, every one of them an artifact rather than a conversation, every one of them checked by the side that is capable of checking it.

Everything above is about cohorts that share a ledger. The failures in my record are almost all about cohorts that accidentally shared something else.

The two-sessions-one-checkout incident is the obvious one. Pushes interleaved. A false “CI green” landed in the memory file. A stale lock file from one session’s timed-out commit blocked the other. Nothing was lost, but the session log’s own conclusion is that “with two sessions live, git diff --cached before committing is not a formality.” That is a classic shared-mutable-state failure that any engineer would recognise. What is new is that neither agent noticed it was happening until one of them checked.

The one that bothered me more was quieter. During a long test sweep, an agent held the build directory lock for fifty-seven minutes while I sat waiting to launch the editor. The agent’s own note afterwards: “nothing in how I was checking would have surfaced it. I only found it because they asked.” Agents do not notice they have blocked you. Contention between a human cohort and an agent cohort is visible to exactly one party, and it is not the fast one.

And a small one: three abandoned working trees from earlier sessions sat inside the repository long enough that a repo-wide search for a function returned nothing but stale copies. Every cohort leaves residue. Somebody has to own clearing it, and it will not be the cohort that left it.

The second human

The compliance platform is the case I get asked about most, because it is the one where a second person is in the loop. What changed, honestly, was less than I expected. The operating system transferred with no structural change: an append-only decision log, a session log in the same wrap format, a handoff protocol, and a committed evaluation history that gates phase closure. Twenty-two recorded decisions in its first two days. The only substitution was in the gates: evaluations over regulatory documents, where the engine has runtime checks.

What a second human adds is that the contract becomes the place where two people agree, before any agent reads it. The domain expert does not need to read the code. She needs to read the decision log and the evaluation results, and she can say “that is not what the regulation means” in the same register that I say “that is not what the engine does.” The seam between us is the same shape as the seam between the game cohort and the engine cohort. A ledger of claims, checked by the side that can check them.

Five things I would tell someone standing up a second cohort

Give every cohort its own checkout. Its own working tree, its own memory file, its own log. Two cohorts in one directory is not parallelism, it is a race condition with a friendly interface.

Fix the shape of the ledger between them. Wanted, offered, workaround, suggested shape. Four fields. An entry that skips the workaround field is usually an opinion, not a gap.

Re-verify before you act, and expect a third of the claims to move. Not because the filing cohort was careless. Because it was measuring with the wrong instrument for the question, and so are you, in the other direction.

Close with a walk-through the filing cohort performs. Green tests close the engine side. Only the side that felt the problem can close the problem.

Budget for being the only one who notices contention. Locks, stale trees, interleaved pushes, a false green in a shared file. The agents will report these faithfully once they are found. They will not find them. That is your job, and it is a bigger job with every cohort you add.

Where this leaves the human, again

Last week’s close was that the agent operates and measures, and the human perceives and decides. At cohort scale I would add one line. Between cohorts, the human is also the only party that can see the whole board: who holds which lock, which ledger is stale, which “green” was polled to conclusion and which was written down from hope.

The unit of collaboration between teams that have agents in them is not a conversation, and it is not shared context. It is a claim with a measurement attached, handed to a side that is expected to check it. A cohort that reports green without looking is the same failure as a green test suite. Nobody has looked yet, only now there are two of you not looking.

This is the second piece on collaboration models, following “Collaboration Models: Navigating Productivity with AI.” The gap ledgers, the sprint records, and the session logs it draws on are part of an ongoing series on building an AI-native game engine, and of a longitudinal case study now in preparation.