ConnectOnion

The trait that decides it is where you begin. One command scaffolds a project that already has files, shell, browser, planning and sub-agent tools attached, so your first hour is spent changing an agent's behaviour rather than assembling its capabilities. For learning what you actually want, that ordering is much better.

What follows is a project you did not design, with choices you will eventually want to undo. Pick it to find your requirements. Pick Griptape once you know them and want the architecture to match.

The discovery feature is the exposure. An agent made reachable through a relay is callable by parties who were never introduced to it, and the same agent ships with shell, filesystem and browser tools from the scaffold. Nothing published describes authentication, authorisation or rate limiting on that path, which makes the default posture optimistic.

What it does right is bounding the loop. A maximum iteration count is an explicit safety control rather than a hidden default, so a confused agent stops rather than continuing until the invoice does.

1. Refusing to introduce a schema language means the definition of a capability is the function signature, so there is exactly one artefact to keep correct instead of two that drift apart. That is a real reduction in the failure surface.

2. An interactive debugging mode makes the loop observable while it runs rather than afterwards.

3. No evaluation accompanies any of it, and the documentation demonstrates usage rather than outcomes, so the minimalism is defensible on taste and unmeasured in effect.

A framework that works with no account is a smart acquisition funnel, because the frictionless first run routes inference through the maintainer's infrastructure and creates a relationship before anyone has evaluated one. That is where the eventual revenue lives, alongside the hosted deployment target.

Nothing is priced yet, so nobody has tested willingness to pay, and the permissive licence means users can leave for their own keys at any time. Moat: convenience. Likely path: managed keys and hosting become a paid tier. Position: adopt the library, configure your own provider on day one.

The default is my problem. A developer following the quick start is routing our code through a third party's infrastructure without an account, a contract or a processing agreement, and nothing in the flow prompts them to notice. That is not a hypothetical, it is the advertised experience.

Beyond that it is a library with no unattended execution, so it produces no scheduled work and nothing my reporting can see. Licensing costs nothing. Not yet: I would need our own provider configuration mandatory before anyone installs it.

Functions as tools is the right minimalism and I would keep it. Six providers are configurable, so routing between them is mine to decide, and the command-line surface covers scaffolding, running and diagnosing without a web console in the way.

Two things stop it scoring higher. It speaks no protocol, so the servers I already run cannot be attached, and the row records no local endpoint, meaning inference leaves the machine whichever provider I pick. Permissive licence, so both are patches rather than dead ends.