uAgents

The deciding trait is how small the code is. An interval decorator and a message handler are the whole of a working agent, and if what you need is something that runs every minute and reacts to what arrives, you will have it running before the coffee cools. That economy is genuine and rarer than it should be.

Where it disappoints is expectations. This is a messaging and lifecycle library, not an agent that writes code. Pick it for scheduled services with identities. Pick something else if you wanted work done.

Discovery is coupled to a public ledger, and that coupling is at the worst possible moment. Startup is when you want the fewest external dependencies, because a failure there is total rather than partial, and this design adds a network and a contract to a path that could have been a config file listing peers.

What it does right is making the mechanism explicit. The dependency is documented, not hidden behind a service call that only reveals itself when the network is slow.

1. Authenticated messaging is the right primitive for a network of independent processes, and it is one most agent frameworks omit entirely, leaving identity as a string somebody types. Here it is a keypair, and impersonation requires the key rather than the name. 2. Deriving that key from a seed makes an agent's identity reproducible across restarts and machines, which is what makes discovery meaningful at all.

2. No evaluation accompanies the library, and its claims are architectural, so none is owed.

The library is the on-ramp and the marketplace is the product, which is a coherent strategy and a dependency worth naming out loud. Adoption of the framework only pays the sponsor if agents end up on the network, so the incentive runs toward tighter coupling over time rather than looser.

Moat: the network, if it ever reaches critical mass, and nothing otherwise. Likely path: continued publication as ecosystem marketing for as long as the parent's own thesis holds. Position: acceptable for experiments, and I would not build a commercial product on a network I do not control.

This is a dependency, not a product, so there is no seat price and no console and no vendor to call. Whatever we build with it becomes a service my team runs, and the version window is the part I plan around: a supported range with an upper bound means our runtime upgrades are gated by somebody else's release cadence.

There is no unattended execution surface of its own, no identity integration and nothing to audit. Approved with conditions: it may sit inside a service we operate, and never on developer workstations as a tool.

Being unopinionated about models is the right kind of small. The library takes no view on inference, so my local endpoint, a hosted API or no model at all are equally valid inside a handler, and nothing has to be configured for a case the authors did not anticipate.

The gap is protocol support. There is no MCP at either end, so the tools I already run do not attach and the messaging here talks only to other agents built the same way. Permissive licence, readable source, small enough to fork.