A solo developer running two or three agents

Where git alone is genuinely fine

Say this first, because a marketing page has an incentive not to: if you are one person running two agents sequentially, you start one, it finishes, you start the next, git is enough. There is no concurrent claim to lose, no file two workers might both reach for, because nothing is actually running at the same time. Adding a coordination layer to that setup is overhead with no problem underneath it.

The crossover point is concurrency, not headcount. It arrives the moment you run two agents at once against the same repository: Claude Code on one task in one terminal, a second agent on another task in a second terminal. That is the moment two processes can pick the same file without either one knowing.

What actually goes wrong at n=2

It is a smaller failure than the fleet story, but it is the same failure. You start an agent on the auth module. Ten minutes later you start a second one on what you think is an unrelated task, and it touches the same file: a shared config, a type definition both features need, a util you forgot both tasks would import. Neither agent knows the other exists. You find out at the diff.

At two agents this costs you twenty minutes of untangling, not a merge disaster. That is exactly why it is easy to shrug off. The cost is small enough to absorb every time, so it never gets fixed, and it recurs every session.

The setup, at this scale

Same commands as the fleet case, run against a much smaller tree. The gap report does not care that you are one person. It still tells you which files nothing documents and which symbols nothing calls, and on a project you wrote yourself in the last few months that list is frequently shorter and more useful than it is on an inherited codebase, because you can act on all of it in an afternoon.

Two workers, one board. Each claims the top task it can do, locks the files it declared, and the second one is refused a file the first already holds instead of silently editing it. That is the entire value at this scale, not scheduling a hundred workers, just making sure two do not collide when you are not watching both terminals at once.

What you get that git alone does not give you

• A claim before either agent starts typing. Not a diff you discover after both have already spent the tokens.
• A roadmap you didn't have to write. lac web suggest --dispatch turns your own gap report into a short queue, which on a solo project is often just a better todo list than the one in your head.
• A record of what you tried. Even at n=2, "what did agent two do while I was on a call" is a real question, and lac digest answers it without you reconstructing it from scrollback.

What you don't get, and shouldn't expect

Team mode, row-level security, escalation backoffs tuned for a person who is not at a keyboard: none of that pulls its weight for one person. It is there if you outgrow solo, and it costs you nothing unset, but running it for the security boundary at this scale is solving a problem you don't have yet. The honest framing from the project's own status notes is that this is for someone who runs several agents across different tools and wants them to stop duplicating work and start escalating when stuck, and "several" can mean two just as validly as it means twenty.

A reasonable bar for turning it on

• You run two or more agents that overlap in time, not just in the same day. Actual concurrent sessions against the same tree.
• You've already lost time to a collision once. If it hasn't happened yet, it is not urgent to prevent.
• You already have, or don't mind running, a Postgres. If standing up a database for a weekend project feels like more infrastructure than the project itself, that is a real signal to wait.