AgentsMesh

You will feel the difference when work stops living in your head. A ticket on the board binds to a pod, the pod opens its own branch, and the merge request that comes back is attached to the card it came from. The deciding trait is that traceability, from card to branch to review, without you writing it down.

This is wrong for you if you have three tickets and one repository, because you will spend more time on the board than on the code. Pick it when you are dispatching work to more agents than you can hold in mind. Pick Agent Deck when you can.

Autopilot is the risk. It watches a pod, and when the pod goes idle it sends the next instruction, which means the only thing standing between a misread ticket and a long expensive afternoon is an iteration cap. Decision history records what happened. It does not judge whether what happened was the right work.

The vendor documents the takeover path, and that is the honest part. A human can seize the pod at any point, which is the correct escape hatch to build first, and more than most tools that run unattended bother to ship.

1. The trust boundary is drawn where it should be. Orchestration travels over gRPC with mutual TLS, and terminal bytes travel through a relay that holds no state, so the component with the widest reach carries the least to steal. 2. One Rust core serves the web, desktop and iOS clients, which means three surfaces cannot drift into three behaviours.

2. Each pod holds private credentials in its own working tree, so the isolation claim is enforced by construction rather than asserted in prose. No benchmark accompanies any of this, and none is claimed, which is the correct pairing.

2,338 stars is real distribution for a control plane, which is the hardest thing to buy and the easiest thing to lose. The structural problem is that self-hosted runners leave no hosting margin, so whatever gets charged has to be charged for coordination itself, and coordination is exactly what a competitor gives away.

Moat: switching cost, once a team's tickets and branches live inside it, which is the strongest kind on this board. Likely acquirer: a CI vendor that wants agents scheduled the way builds already are. Position: promising, and I would want the business model named before a team builds its process around it.

The deployment is a docker compose file and runners installed on machines we already own, which my platform team can do in a morning. What is not in the row is the part procurement asks about: no SSO, no SCIM, no audit log, no retention policy. Capacity advertising is scheduling, not governance.

The model spend behind sixty engineers running parallel pods is a larger number than any seat licence would be, and nothing in the row caps it centrally. Onboarding a mid-level engineer is a day. Approved with conditions: an identity integration first, and a spend ceiling per runner.

BSL-1.1 with a public repository is source-available, and I will keep saying that is not the same as open. I can read it and I can patch my copy. What I cannot do is fork it into something of my own while the licence runs, and for a control plane I depend on, that matters more than it does for a library.

The credentials are mine, since it runs the agent logins I already have, and everything executes on hardware I racked. There is no MCP client and no server, so the tool servers I run stay outside.