Tessera

The deciding trait is that a task has a lifecycle rather than a scrollback. Work moves from a conversation into a queue, into progress, into review and out, and each stage is a place you can leave something without losing it. For anyone who has abandoned three half-finished agent sessions in three terminal tabs, that structure is the point.

The structure only helps if you keep it current, and it is another thing to keep current. Pick it when several tasks are genuinely in flight. Pick one session when only one ever is.

Handing an agent the controls hands it the budget. A lead that decides how to divide work will decide how many workers it needs, each of those is a separate session on a separate meter, and the documentation describes the mechanism without describing a limit, a depth ceiling or a detector for a lead that keeps spawning. The failure shows up as a quiet afternoon and a loud invoice.

What it does right is give every session its own worktree, so at least the parallel work cannot collide on disk.

1. Reflexivity of this kind is economical: one interface serves both the operator and the model, so there is no second protocol to specify, document or keep in step, and every action an agent can take is one a human could have taken and audited. 2. It also means the orchestration logic lives in a prompt rather than in code, which is flexible and unverifiable in equal measure.

2. Nothing is published on how reliably a lead agent uses that surface, so the design is documented and its behaviour is not characterised.

Everything a user pays for here belongs to somebody else. The agents doing the work are other companies' products on other companies' meters, and what this owns is the arrangement between them, which is the layer with the shortest defensive life in the whole category because the wrapped vendors are shipping their own versions of it.

Moat: none against the vendors. Likely acquirer: none obvious; a small team's good taste is not an asset that transfers. Position: use it while it is ahead, and keep the underlying agents installed independently of it.

Having a server deployment option changes what this can be. One managed instance behind our infrastructure is something my group already knows how to operate, back up and upgrade, and it moves the tool from a personal habit into something with an owner and a change process.

Identity is still missing. No single sign-on, no provisioning and no audit trail, so the board records the work without recording who authorised it, and phone pairing extends that gap to devices I do not manage. Approved with conditions: hosted centrally, behind our authenticating proxy, with device pairing disabled.

A copyleft licence on a tool like this is a guarantee rather than a restriction: whatever happens to the people maintaining it, the code stays open and a fork stays legal, which is the only longevity promise anybody in this category can actually make.

Custom model identifiers per backend mean I am not limited to whatever the vendor's default picker offers, and running the whole thing in a container keeps it off my base system. There is no protocol client, so tool servers stay configured inside each agent rather than centrally.