Agent Maestro

The deciding trait is that the editor has to be open. Agent Maestro does not do the coding, it hands work to the extensions you already installed and hands you back a task id, so everything you liked about that setup survives and everything you disliked survives too. If your day already ends with three chat panels, this collapses them into one call.

Where it bites is that a window nobody is watching is still a window somebody has to keep alive. Pick it when you want to automate the editor you use. Pick a terminal agent when you want the editor gone.

The risk is a dependency it cannot version. Task lifecycle control is exposed over REST, but the thing executing that lifecycle is a third-party extension on its own release schedule, and nothing in the design isolates a breaking change on their side from a caller on yours. Twenty concurrent Roo Code tasks share one editor process, so a hung task is not contained.

What it does right is admit the shape. The README calls it headless AI agent control rather than an agent, which is accurate, and the boundary between control plane and worker is where a boundary belongs.

1. Publishing a machine-readable specification changes the contract from prose into something a client generator can consume, so an integrator's assumptions are checkable before runtime. 2. Streaming state over SSE rather than polling makes progress observable at the granularity the loop advances, which is the correct instrument for a long-running process.

2. Reported token usage separates prompt cache reads from writes, so cost attribution is measurable per task instead of inferred from a monthly invoice. No evaluation is published, and none is claimed; the project asserts plumbing, not capability.

There is no entity to fund and no meter to raise. Agent Maestro sits between an editor and two extensions it does not own, which is the classic adapter position: valuable while the gap exists, worthless the week either side closes it themselves. Two hundred stars is a signal of a real itch and not of a business.

Moat: none, and the switching cost is a weekend. Likely path: the upstream extensions ship their own API and this becomes a footnote, or the maintainer keeps it current because he uses it. Position: depend on it for tooling you can rewrite, not for a product you sell.

The invoice is not the problem. Nothing is charged per seat, and the model spend arrives through keys we already reconcile. The problem is that this turns a developer laptop into a server, and the published material describes no identity layer, no access log and no retention policy for what crosses that port.

It does claim a pipeline role, and REST task control would fit a build step, except that build step needs an editor running inside the runner. That is not a shape my platform team maintains. Not yet: a security review of the listening surface first, and a managed image if one ships.

This is the trick I keep wanting and nobody ships. My editor becomes the endpoint, so any client that speaks the Anthropic or OpenAI wire format talks to whatever agent I have installed, on the subscription I already pay for. The licence is MIT, so if a route annoys me I add one.

Model freedom is real but indirect: my keys live in the extensions underneath, not here, and there is no local serving path in this layer. MCP servers come along because the Roo tasks it launches already speak it. I would rather own the routing than rent it.