Water

The deciding trait is that your existing agents go in unchanged. LangChain, CrewAI, Agno or something you wrote yourself all slot in as tasks, which matters enormously if your codebase already accumulated two or three of them and nobody wants to rewrite the one that works.

If you are starting from nothing, this is a layer you do not need yet, and adding it early means learning two abstractions to ship one feature. Pick it when heterogeneity is already your problem. Pick one framework and stay there if it is not.

Every control-flow construct here already exists in Python, and reimplementing them as chained calls means a stack trace now crosses two of them. A conditional written as a method has no breakpoint you can set in the ordinary way, a loop expressed as configuration does not appear in a profiler as a loop, and a failure inside a nested subflow reports at the boundary rather than at the line.

What it does right is capping iterations, so at least the loops it invented cannot run forever.

1. Contracts at the seams are what makes a composed pipeline analysable. Without them, the only description of what a step produces is the code inside it, and every downstream assumption is untested folklore. With them, a break is localised to the step that violated its own declaration.

2. Nested composition with explicit input and output mapping extends the same discipline to subflows rather than exempting them.

3. No evaluation accompanies the framework, and its claims concern structure, so none is required.

A compatibility layer is the most fragile position in any ecosystem. Its work grows every time one of the frameworks it wraps ships a release, and none of those projects has any reason to care whether this keeps up. One maintainer against five upstreams is a race that ends one way.

Moat: none available structurally. Likely path: a useful year, then drift, unless a sponsor with an integration problem adopts it. Position: read it for the ideas, and vendor the parts you rely on rather than depending on the package.

A pause for human authorisation is not a nice extra in a regulated pipeline, it is the control that makes automation approvable at all, and finding it in a library at this size is unexpected. It lets a flow stop at exactly the step where our change policy says a person signs.

Everything else is the standard library position: nothing to buy at sixty engineers, no console, no directory integration, and a service my team builds and carries. Approved with conditions: one team owns it and the gates map to our existing approvers.

Sandboxing appears on the feature list with no runtime behind it. I cannot tell whether that means a container, a subprocess with restrictions, or an intention, and for the one feature whose whole purpose is a boundary, an unnamed implementation is the same as no answer. That is a documentation bug rather than a design flaw, and it is doing real damage.

The licence is permissive, the package is one install, and the source is small enough that I can settle the question by reading it.