VoltAgent

The trait that decides it is that evaluation ships in the box rather than being your homework. Agents drift when a prompt or a model changes, and most frameworks leave you to discover that in production. Having a suite you run before merging turns a vague feeling that it got worse into a number, and that changes how confidently you touch anything.

The supervisor and sub-agent structure is conventional and fine. Pick it when TypeScript is the requirement and you want the testing story solved. Pick Mastra when you would rather have the bigger community around you.

The inconsistency is worth naming. Self-hosting is offered for the observability layer, which is where a company would normally keep the hooks in, and withheld exactly where it would matter more: the model. There is no local endpoint option, so an agent you run on your own hardware still ships every prompt to one of three external providers, and the residency question you thought you solved is unsolved.

Verify the provider terms before assuming self-hosting means anything about data. What it does right: memory persisting across sessions belongs to the framework itself, not to the paid layer.

1. Control is hierarchical: a supervisor decomposes and delegates, which bounds each sub-agent's context to its assignment and makes token spend attributable per branch. 2. Tools are registered centrally with MCP integration built in, so an agent acquires capability by lookup rather than by bespoke wiring, and the same tool is described identically to every agent.

2. Verification is offered as evaluation suites, which is a test harness rather than a runtime check, and the distinction matters: it catches regressions between releases, not errors within a run. No benchmark is published.

The structure is the familiar one and it is well chosen here. The framework is free and creates the telemetry; the console reads it and is sold. Observability is the right thing to charge for, because it becomes indispensable precisely when a customer's usage is large enough to hurt, which is also when they have the least appetite to migrate.

Moat: whatever traces accumulate in the console, which is switching cost that grows monthly. Likely acquirer: an application monitoring incumbent adding agent traces to an existing product. Position: sensible model, ten thousand stars is early, needs the paid layer to convert.

Costs nothing for sixty engineers, and it runs without a person present, so agents become pipeline steps that produce reviewable artefacts rather than laptop experiments. The console being deployable on our own infrastructure is the detail that matters most, because agent traces contain prompts and prompts contain whatever an engineer pasted in.

What is missing is the support side: below any negotiated arrangement, escalation is a public repository, and no directory integration is described. Onboarding is a few days for a TypeScript team. Approved with conditions: the console self-hosted, and a support arrangement in writing before anything customer-facing.

MIT on the framework, which is the part I would have to maintain if the company lost interest, and a single create command scaffolds the project rather than making me assemble six packages by hand. That is a small courtesy and it tells me somebody used their own tool.

The registry taking MCP natively is what I actually care about: my servers register as capabilities directly, with no adapter layer translating between somebody's tool abstraction and the protocol. Ten thousand stars is enough that a fork would find company. It does not serve MCP itself, which is the direction I would add next.