Jido

The trait that decides this is that restarts, supervision and back-pressure are not features you configure, they are the platform you are already standing on. An agent that misbehaves gets handled the way every other process in your system gets handled, which means the operational knowledge your team has is the operational knowledge this needs.

That is also the whole story: outside Elixir there is nothing here for you. Pick it if agents are joining an existing application. Pick LangGraph if you are starting from a blank Python file.

The dealbreaker is reach. Everything good here follows from being ordinary software on a single virtual machine, and so does everything limiting. There is no documented way for a client written elsewhere to call these agents, so integration means writing the transport yourself, and a polyglot shop ends up maintaining a bridge in perpetuity.

What it does right is the interface. One command function per agent means there is exactly one place where a decision gets made, which is a discipline most frameworks abandon by their second abstraction.

1. The separation is unusual and principled. Signals carry events inward, actions transform state, and directives describe what should happen without doing it, so the part that decides can be exercised in a test without a network. 2. That property survives a model change, because the model sits outside the decision boundary rather than inside it.

2. No evaluation is published and there is no benchmark to audit, which is consistent with a library that makes no capability claim. The design is the claim, and it holds.

The market is the problem, not the code. This targets a language with devoted users and a small commercial footprint, which caps how much revenue any tooling around it can carry, and the project publishes no hosted tier, no support offer and no price. That is fine for a library and fatal for a company.

Moat: the maintainer's taste, which does not transfer. Likely path: it stays a well-kept community package, or it stops when its author's attention moves. Position: depend on it the way you depend on any small package, with the pin recorded and the fork budget accepted.

Budget impact is zero, which is where my interest in the budget ends. The real number is people. Of sixty developers, the count who can maintain a supervision tree is small, and the market I hire from is smaller still, so this is a bet on a skill concentration rather than on a tool.

It also does not touch anything I already run: no unattended execution, nothing that plugs into a build, and support is a public package registry. Onboarding for an engineer new to the language is weeks, not days. Not yet, unless the platform team is already fluent.

Dependency-wise this is as clean as it gets: {:jido, "~> 1.0"} and the source is on a licence that keeps my fork mine. The extension points are behaviours, which means changing what an agent does is implementing a module rather than fighting a config schema, and I can read the whole thing in an evening.

The gap is protocols. No MCP client, so the servers on my machine are invisible to it and I write the adapter myself. Annoying, not disqualifying, and the adapter would be mine too.