Anyone running more than one coding agent on the same repo knows how this usually goes. One agent makes a bad change, and you find out after it’s already part of the codebase.
By then the damage has spread. The other agent has read the broken file and built on it. Your tests are failing for reasons that have nothing to do with the thing you were actually working on. You spend the next twenty minutes doing forensics on a codebase that two machines edited concurrently while you were in a meeting.
Researchers from Northeastern University and Stanford University built something called Shepherd to fix exactly that. It’s basically git, but for agent state.
Why plain git doesn’t cover it
The reason you can’t just solve this with git is that git versions files, and files are only part of what an agent accumulates.
Think about where a coding agent is at step ten of a long task. It has edited files, yes. It also has a dev server running, packages it installed along the way, stuff sitting in /tmp, open file handles, and a warm prompt cache worth real money. The trajectory log records what the agent said and which tools it called. It records none of the live state underneath.
So checking out step eight gets your files back and leaves everything else where it was. The process is still sitting in step-ten memory. The cache is cold. The dev server is running against a schema that no longer matches. You haven’t gone back to step eight. You’ve gone somewhere new and worse.
The two options people actually have are both bad. Patch forward, and you’re stacking corrections on top of a mistake while the context grows and the bill grows with it. Restart from scratch, and you re-pay for every model call and tool call you already bought. And because runs are non-deterministic, restarting doesn’t even reproduce the early steps that were fine. You’re buying the same eight steps again and getting different ones.
Every step as a reversible commit
Every step an agent takes becomes a reversible commit. Shepherd tracks the agent’s execution, environment, filesystem and tool interactions, so if something goes wrong you roll back to any earlier point and continue from there, instead of cleaning up by hand.
The mechanism is copy-on-write forking over an overlay filesystem, rather than container snapshots. A fork captures the worker’s filesystem, processes and bindings in one atomic step, and discarding a child leaves the parent byte-identical to the moment of the fork. That’s the property that makes it usable. Not “roughly restored”. Identical.
The performance follows from that. Forking runs about five times faster than Docker and keeps over 95% prompt-cache reuse on replay, which is the number that decides whether rollback is affordable enough to do routinely rather than as a last resort.
Not everything reverses, and the paper is honest about it. Filesystem and sandbox changes undo themselves. A database write doesn’t, so it needs a matching undo step set up ahead of time. A sent email or a real charge can’t be undone at all, so for those Shepherd refuses at the syscall level instead of pretending it can roll them back. Which is the right call. You can’t build recovery for actions that have already left the building.
Supervision is the actual point
The part that matters most for teams: a supervisor can watch multiple agents at once and catch conflicts before they land, not after.
That inverts the whole workflow. Right now review happens after the fact, on a diff, by a human, once the agents have finished making a mess. With reversible traces, a meta-agent can sit above the workers, observe what each one is about to do, and discard a branch before it touches the shared state. The bad change never becomes part of the codebase, so there’s nothing to clean up.
The benchmark backs this up. On CooperBench, where two agents work on the same codebase, adding a live supervisor took pair-coding pass rates from 28.8% to 54.7%. Nearly double, from the same underlying agents. The gain isn’t better models. It’s catching the failure at the point where it’s still cheap.
It’s early alpha, pip installable, MIT licensed, Python 3.11 and up. I wouldn’t put it near anything critical yet. But the idea underneath it is the right idea, and the value shows up exactly where you’d expect: heavy sandbox state, lots of branching, and a restart that costs you real money.