Agently

The trait that decides it is what comes back. Runs emit structured, observable records instead of free text, so the thing your code consumes is data rather than a paragraph you then have to parse. Anyone who has written a regular expression against a model's answer will recognise why that matters more than a feature list.

It is a young project with documentation that assumes you will read source. Pick it when observability of the run matters. Pick PydanticAI when you want the same discipline with a larger community around it.

The confinement is opt-in twice over. Three isolation candidates exist, none is enabled by default, and each only checks whether its underlying mechanism is present at the moment it is chosen. A developer following the quick start therefore runs shell, Python and Node actions with the privileges of the process that started them, and will not learn otherwise from the tutorial.

What it does right is unification. Local functions, built-in helpers and remote servers all execute through one action runtime, so behaviour and logging are consistent across very different kinds of work.

1. Scoping configuration to a single execution rather than to a long-lived agent object makes reproducibility tractable: the inputs to a run are enumerable, so a run can be described completely. 2. Resource providers own the lifecycle of external processes and language runtimes, which puts cleanup somewhere principled instead of in a finally block.

2. No evaluation accompanies any of it, and the documentation describes structure rather than outcomes, so the architecture is inspectable and its effect on task success is unstated.

There is no commercial layer at all here, which is honest and leaves nothing to fund the work. In a category where funded competitors ship weekly, an unfunded framework competes on taste alone, and taste does not compound the way distribution does.

Moat: none. Likely path: continued maintenance while it remains interesting to its authors, or absorption of the better ideas by a project with a budget. Position: use it where the run structure earns its place, keep the agent logic in ordinary functions, and treat the framework as replaceable.

No licence, no seats, no negotiation, and no console either. Whatever gets built with this becomes an internal service my platform team writes around a library, so the real cost is the engineering time to make it operable and the ongoing obligation to keep it that way.

Nothing runs without a person present, so it produces no scheduled work and no records I can put in a report. Onboarding a Python engineer is a couple of days. Approved with conditions: it may be a dependency inside a service we own, and never a tool handed directly to developers.

Treating remote servers as just another action type is the right call: my existing tooling does not become a special case with its own configuration dialect, it becomes something the runtime already knows how to call. The local endpoint is documented by address rather than implied, which saves an evening of guessing.

Permissive licence, small dependency footprint, and providers configured per name so I can route a cheap task and an expensive one differently. This is a library I would keep in my own projects.