ccteam

The deciding trait is the chat console. The whole thing runs from a Telegram or Lark thread with approve and deny buttons: the agent asks, your phone buzzes, you tap, it continues. For anyone whose day is meetings, that is the difference between a run finishing and a run waiting.

It is also how you end up approving things you have not read, which is a habit worth watching in yourself. Pick it if you are away from the desk more than you are at it. Pick a terminal orchestrator if you would rather read the diff before you agree to it.

The topology is the risk. Delegation is peer to peer rather than hierarchical: any session may create another, on any machine attached to the project, and that one may do the same. No depth ceiling is documented, no cycle detection is described, and two sessions that keep handing work to each other are indistinguishable from progress.

Crossing machines widens it further, since a runaway chain consumes several vendor subscriptions at once rather than one. What it does right is naming guardrails and delivery guarantees as first-class concerns rather than assuming them, which is more than most orchestrators on this board bother to claim.

1. Multi-agent systems usually lose attribution at the first hand-off: work arrives with no record of who asked for it. Representing each delegation as an explicit edge preserves that record, so the question of which session produced a change has an answer that does not require reading transcripts.

2. The topology is presented live, which makes it an operational display rather than an audit artefact; nothing documents whether the graph is retained after a run ends. 3. No evaluation accompanies the routing or the identity layer, and none is claimed. The provenance design is the strongest idea in the row and the least measured.

Connective tissue is a hard place to build a business. The value depends entirely on the vendors it spawns continuing to allow it, and every one of them ships its own orchestration eventually. There is no company structure visible, no revenue line and no funding, so this competes with roadmaps rather than with products. Moat: none.

Likely path: it stays a well-made personal project until one vendor's terms change, and then it stops working for the lineup that made it interesting. There is no acquirer, because what an acquirer would want is the idea rather than the code. Position: use it for a quarter, not for a year.

The ledger is the reason I am still reading. A running record of what the agents spend is the number I have been asking every vendor for, and here it exists. Set against that, Windows support only through WSL means a third of my engineers get a support burden rather than a tool.

The rest is unchanged: no single sign-on, no directory sync, no audit export, nothing that runs in a pipeline. Sixty seats cost nothing and the spend still belongs to whichever subscriptions the engineers hold. Approved with conditions: Linux and macOS desks only, and the ledger reviewed monthly by someone who is not the person spending.

Formations are the part I like: a playbook prefills an entire lineup of vendor agents, so the shape of a team is a file rather than a sequence of clicks. That is configuration as an artefact, and it means the setup I tuned on one project moves to the next one intact.

MIT and a Rust daemon means one process I can read and replace, and it brings no model of its own, so the CLIs keep their own logins. It speaks no MCP in either direction, which is the gap: my servers reach it only through whatever agent it spawns. Grudging respect, held back by that one omission.