FleetCode

The deciding trait is one worktree per session, cut from a parent branch you choose. Two agents editing the same tree is the failure everyone discovers the hard way, and this makes it structurally impossible rather than a matter of discipline. You get a clean diff per session and a merge you can do when you are ready.

If you run one agent at a time, this is scaffolding around a problem you do not have. Pick it when three sessions at once is your normal Tuesday. Pick a single branch and a terminal when it is not.

The word multi-agent is carrying more than it should. Sessions run at the same time in separate trees and, per the row's own note, they do not talk. Nothing routes work between them, nothing reconciles two solutions to the same problem, and nothing notices when two sessions are told to do the same thing.

The cost lands at merge time, on you, and grows with the number of sessions you were pleased to be running. What it does right is not pretending otherwise: the note is in the documentation, not in a support thread, which is a lower bar than it should be and one most projects miss.

1. The choice is economical and correct: rather than storing its own transcript, the app records the upstream session id and asks the CLI to resume. Continuity is therefore exactly as durable as the vendor's own persistence, no more and no less, and the app cannot silently diverge from it. 2. That is a real architectural virtue.

2. It also inherits the vendor's failures. Nothing documents what happens when an id is expired or rejected, and the two supported CLIs need not agree on retention. No evaluation is published and none is needed here; the design is a delegation, and delegations are judged by what they delegate to.

The position is borrowed on both sides. It rests on two vendors' CLIs and adds a capability those vendors are visibly moving toward, which means the roadmap risk is not slow decay but a single release note. There is no entity, no revenue and no funding to absorb that.

Moat: none, and the value is a convention anyone can copy in a weekend. Likely path: it stays useful until one of the two ships an equivalent, and becomes a curiosity the week after. Position: use it now, and keep your worktree habits reproducible with plain git.

There is no build here, let alone a package. The row's only install is a clone, a dependency fetch and a development server command, which means every engineer runs an unbuilt application from a working copy of somebody else's repository. There is no version, so there is nothing to approve and nothing to pin.

Everything else is moot until that changes: no single sign-on, no directory sync, no audit export, and nothing that runs unattended. Sixty seats cost nothing, which is the only line finance will enjoy. Not yet: package it, version it, and I will read the rest of the row.

The setup command is the hook I want. A shell command that runs before the agent starts means the environment is mine to prepare: virtualenv activated, secrets exported, whatever this project needs, without the app having to know about any of it. Small feature, and it removes a whole category of complaint.

MCP servers register over stdio or SSE for the sessions it launches, so the tools I already run come along without editing two config files. ISC is as permissive as licences get, which keeps the fork uncomplicated. Grudging respect, and I would like a headless mode I could call from a script.