Nanocodex

The deciding trait is that this is a library, not a server. You link it, you own the process, and what it hands you is a stream of events rather than a UI you have to accept. If you are building a product with an agent inside it, that is the difference between decorating somebody else's app and writing your own.

What it is wrong for is using an agent. There is no application here to launch, only something to depend on, and the audience is people who already know which events they want. Pick it to build. Pick something finished to work.

The risk is stated in the README, which is the candid version of a lock-in problem. One provider is supported on purpose. Every type, every event and every retry path is shaped by that decision, so a second vendor is not a configuration change, it is a parallel implementation with your name on it. Products outlive model contracts. That is where this bites.

What it does right is refusing to pretend otherwise. A narrow contract documented as narrow is easier to plan around than a wide one that leaks its assumptions at the edges.

1. The interesting claim is not the agent loop but the bookkeeping around it: response identifiers and tool results threaded across turns, prompt ordering held apart from delivery, and replay after a dropped connection. These are the parts rewritten badly in most integrations. 2. Events are ordered and typed, so a consumer reconstructs state from the stream rather than by inference.

2. No evaluation is offered and no capability is claimed, which is the correct pairing for a component whose entire contribution is an interface.

Single-author infrastructure has a recognisable shape. The design is coherent because one taste made every call, and the bus factor is one. There is nothing here to fund and nothing to acquire. If this matters commercially it will be because a company adopts it as a dependency and quietly employs the author, which is the usual ending for a well-made component.

Moat: none, and none was attempted. Likely path: the pattern gets absorbed by a larger runtime while this stays the reference implementation. Position: depend on it, pin the version, and read the source before you commit.

Nothing about this is procurable, which means the cost is staffing rather than licensing. Whatever we embed it in becomes an internal system: our deployment, our logging, our incident rota and our invoice for the calls it makes. The finance question takes a minute and the staffing question takes a quarter.

It runs unattended, so it can sit behind a pipeline once somebody has wrapped it, and that wrapper is the thing I would actually fund. Onboarding a mid-level engineer means teaching a dependency, not a product. Not yet, and revisit when a team owns the wrapper.

Dual licensing is the polite form of ownership: whichever of the two the lawyers prefer, a fork stays legal. Installation is one line in a manifest from either registry, and the wasm target means the loop runs in a page instead of shelling out to a daemon, which opens a genuinely different set of things to build.

The friction is the Python binding, which builds from a checkout rather than arriving from an index. That is a Sunday afternoon rather than a blocker, and I would rather have the binding than have it missing.