motleycrew

The deciding trait is that you do not have to throw anything away. An agent you wrote last year against one library and a tool you wrote against another can sit in the same crew here, which turns a rewrite into an adapter. For a team carrying two half-finished experiments in different frameworks, that is a genuinely useful escape.

Starting fresh, the argument disappears, because you would be adopting a compatibility layer before you had anything to be compatible with. Pick it to consolidate. Pick whichever framework you like best if there is nothing to consolidate yet.

The failure mode is transitive. Pulling agents and tools from several large libraries into one process means their pinned versions have to coexist, and those projects move independently and quickly. A breaking change anywhere in that set arrives as a failure in this one, and the maintainer here cannot fix it upstream. Nothing documented describes a supported version matrix for the frameworks it bridges.

What it does right is commit to a single component interface, so at least the seams inside this project are uniform rather than adapter-shaped.

1. Expressing dependencies as edges in a queryable store is a meaningfully stronger position than encoding them in instructions, because the order in which work happens can be examined, validated and changed without touching a single prompt. 2. Using the same structure as a general data store means intermediate results live beside the tasks that produced them.

2. The graph is offered rather than imposed, which weakens the guarantee: a user may control flow with it or ignore it entirely. No evaluation accompanies either path.

Compatibility layers occupy the worst structural position in any ecosystem. The upstream projects own the users, the documentation and the mindshare, while the layer between them absorbs every incompatibility either side introduces and can charge for none of it. Four hundred stars is a respectable audience for that role and it is not a company.

Moat: none available in this position. Likely path: the frameworks converge on a common interface and the bridge becomes unnecessary, or it quietly stops keeping up. Position: use it for a specific migration, not as a foundation.

The bundled monitoring is the part procurement will stop at. Sending traces of agent runs to an external observability provider means prompts, inputs and possibly customer data leave my estate, which is a data processing agreement and a security questionnaire, not a configuration flag. That review costs more than this library saves.

Otherwise it is an import: no seats, no console, and whatever gets built becomes a service my team runs and pages for. Approved with conditions: the external monitoring stays off, and anything built with it emits to the telemetry stack we already operate.

This is the part that irritates me. There is no model layer of its own; what I can call depends on what the underlying library supports, and which underlying library I get depends on which agent type I picked. Changing providers therefore means reading two projects' documentation instead of one configuration file.

The permissive licence is real and the code is small enough to fork, which is the consolation. There is no protocol client here either, so tool servers I already run stay outside unless the framework beneath happens to reach them.