Langroid

The deciding trait in daily use is size. This is compact enough that when something behaves oddly you go and look, and you find the answer, rather than tracing through four abstraction layers belonging to three projects. For anyone who has debugged a tall framework at midnight, that is worth more than a longer feature list.

What you trade away is the tutorial economy: fewer blog posts, fewer copyable examples, more reading. Pick it if you like owning your stack. Pick CrewAI when you would rather start from somebody else's template.

The risk is unbounded delegation. Tasks hand work to sub-tasks, which may hand it back, and the documentation describes the mechanism without describing a limit: no default depth ceiling, no spend guard, no documented detection for two agents that keep addressing each other. The cost of that loop is a provider invoice discovered later.

What it does right is optionality. The retrieval component is attached when needed rather than assumed, so a simple agent stays simple and does not drag a vector database into a script that never needed one.

1. Choosing an established formalism means the failure modes are already catalogued in forty years of literature, which is a better foundation than an invented control flow. 2. Composition is declared through task assignment rather than through prompt convention, so the structure of a system is visible in code instead of inferred from behaviour.

2. No benchmark accompanies any of this, and the authors make no capability claim that would need one. That is the correct pairing: an architectural argument, published as an architectural argument.

University-origin tooling has a distinctive risk curve: quality is often high because the authors have taste rather than a deadline, and continuity is poor because grants and graduations move people. Four thousand stars proves interest and finances nothing, and there is no commercial entity here to acquire or to fail.

Moat: none, and none intended. Likely path: continued volunteer maintenance, or absorption of the ideas by a larger framework while this one slows. Position: use it, pin the version, and accept that you are the support contract.

There is no invoice and no console, which resolves finance and creates the governance problem in the same sentence. Whatever gets built with this becomes an internal service my team owns end to end, including the model spend, the logging and the incident rota, so the true cost is engineering time rather than licensing.

No unattended runner ships with it, so scheduling and monitoring are ours to build. Onboarding a Python developer takes days. Approved with conditions: it may be a dependency inside a service we operate, never a tool handed to sixty people directly.

This checks the boxes in the order I care about. Permissive licence, so a fork is mine outright. MCP is a client capability on the agent itself rather than a plugin bolted to the side, so servers I already run become tools without a wrapper. Model routing accepts a local endpoint, so nothing has to leave the machine.

The install is a single package with no transitive framework dragging its own opinions along. That combination, readable source plus my own inference, is what ownership actually looks like.