Agentrove

The deciding trait is breadth. Seven vendor CLIs answer through one interface, so the argument about which agent is best stops being an argument and becomes a dropdown. If your team is genuinely split between Claude Code and Codex and Cursor, that alone changes the shape of the week.

It is wrong for a solo developer, because you will spend an evening on infrastructure to reach a place a single terminal already was. Pick it if several people share the work and want one door. Pick the vendor's own app if you have settled on one agent and will not change.

The orchestration loop has no described exit. A lead agent splits work, dispatches it to workers on any installed agent, polls, and returns rework. Rework implies iteration, iteration implies a condition for stopping, and the documentation names none. Every turn of that cycle is billed by whichever vendor the worker belongs to.

The second problem is breadth as maintenance. Each adapter is an upstream interface that can move, and a broken one appears as a workspace that will not start rather than as an error anybody files. What it does right is running everything on hardware you control, so the failure is yours to inspect.

1. Placing the boundary at the workspace means concurrency safety does not depend on agents behaving politely toward one another. Two workers editing the same path cannot collide, because they are not looking at the same path. 2. Worktrees are the correct primitive here: the isolation comes from the version control system rather than being reimplemented above it.

2. Verification, however, is delegated entirely: the system merges what workers return without any described check that the returned change compiles or passes a test. Structure is documented, evaluation is absent, and no benchmark is claimed, which at least keeps the two consistent.

Self-hosting is the business model's absence stated politely. No hosted instance means no recurring revenue, no usage data and no pricing power, which also means no investor and no eighteen-month clock. The risk moves from funding to attention: one maintainer against upstream vendors who each ship on their own schedule.

Moat: none, and self-distribution creates none. Likely path: absorbed as a feature by whichever agent vendor decides hosting a rival's CLI is worth the goodwill, or quietly maintained by the author for as long as he uses it himself. Position: run it, pin the release, and own the compose file yourself.

The cost is not the seats, it is the estate. This is a service we host: a compose file, a host with Docker, backups, upgrades and someone paged when it stops. Sixty engineers cost nothing to licence and the model spend still lands on whichever vendor subscriptions they already hold.

There is no single sign-on, no directory sync and no audit export in the row, so access control is whatever the host gives me. It does not run unattended, so it never becomes a pipeline step I can measure. Approved with conditions: one instance owned by the platform team, behind our own authentication, with per-vendor spend limits.

The MCP surface is the part I care about. Four tools, send_message, get_messages, list_models and list_personas, are enough to script the instance from outside without touching the UI, which means my automation is a client rather than a plugin. That is the right shape for extension.

Apache-2.0 keeps a fork viable and self-hosting means nothing phones anywhere I did not send it. What I do not get is model freedom: it runs no model itself, so my own weights reach it only if the wrapped CLI already accepts them, and that decision belongs to somebody else. Grudging respect, with the ownership stopping one layer down.