Blades

The deciding trait is that it looks like the code around it. If your team already builds services in this project's style, the agent stops being a foreign object bolted onto a Go binary and starts being another package with the same shape as the rest. That familiarity is worth more day to day than any feature list.

Outside that context the argument thins out fast, because the tutorials, the examples and the integrations all live in another language. Pick it when the surrounding code decides for you. Pick something Python-shaped when it does not.

The gap is everything above a single agent. Tools have to be implemented in Go rather than attached from a server somebody else maintains, and there is no orchestration primitive for more than one agent, so coordination is application code. That is a defensible scope, and it means the library does less than its category name implies to anyone shopping by checklist.

What it does right is keep the pieces separate. Model provider, tool, memory and middleware are distinct seams, so replacing one does not mean rewriting the others.

1. Borrowing the middleware chain from web service design is a sound transfer: retries, logging, rate limiting and token accounting all belong at the same seam, and putting them there keeps them out of the agent body. 2. Structured output as a first-class concern is likewise a real architectural commitment rather than a prompt convention.

2. The capability list also names a reasoning style, which no library can supply and no library can withhold. One understated observation: a framework can only arrange the call, not the thinking inside it. No evaluation is published, and none is claimed.

Governance is the whole investment case here, and it is a good one for buyers: there is no cap table, no runway and nobody who needs an exit, because this is a sibling package inside a community framework with its own existing contributor base. That converts the survival question into a question about the parent project's health.

Moat: none of its own; it borrows the parent's distribution entirely. Likely path: steady, unhurried releases tied to the framework's cadence. Position: the risk here is neglect rather than acquisition, which is the cheaper failure to survive.

There is no invoice, no console and nothing for procurement to review, which resolves the purchase and creates the ownership problem in the same breath. Anything built with this becomes an internal service my team runs, including its model spend, its logging and its on-call, so the true cost is engineering headcount rather than seats.

It also narrows hiring: the code lives in one language, and a mid-level engineer outside that stack starts from zero. Approved with conditions: it may sit inside a service my platform team already operates, and it is never handed to sixty developers as a tool.

The model layer is an interface, not a registry of blessed vendors, and the documentation says so. That means I do not wait for anybody to add support for the thing I want to call; I write the implementation and register it. Permissive licence, single module dependency, no build step beyond the compiler.

What I do not get is a shortcut. Nothing here discovers tools for me, so extending it is real code every time rather than a config file. I can live with that in a compiled language where I wanted the types anyway.