Go Micro

The idea here is neat and the trait that decides it is the absence of glue. You write ordinary Go services, and every endpoint becomes something an agent can call, so the tool layer you would normally hand-maintain simply does not exist. Describe a system at the prompt and it will scaffold, compile and start the services, then hand you an agent that talks to them.

Generated code lands as plain Go on disk and re-running preserves your edits, so it is a starting point rather than a black box. Pick it for Go backends. Pick Microsoft Agent Framework when your team lives elsewhere.

The risk is breadth per maintainer. This project predates the category by a decade and now carries service discovery, RPC, pub/sub, a key-value store, a typed model layer, durable flows, an agent loop and a per-call payment standard. Commercial support is offered directly by the maintainer, which is honest and also tells you how many people are behind all of it.

Depend on the parts you can read. What it does right: the guardrails are concrete rather than aspirational, with a step ceiling, a repeated no-progress limit, and an approval hook for human sign-off before a tool runs.

1. Capability discovery is registry-derived. Endpoints registered by a service become callable tools automatically, and the cards published for other agents are generated from that same registry, so a single definition feeds both directions. 2. Deterministic work is separated into flows whose steps are checkpointed, so a crash resumes at the last completed step rather than at the beginning. 3. Memory is an interface with a durable store behind it by default.

Deriving the interface from the code rather than a parallel schema is the design decision that will still look correct in three years.

An unusual capital structure for this board: sponsorship from two model labs and a cloud, plus paid support, consulting, training and retainers sold directly. The maintainer states outright that those engagements are what keep the project maintained. It is a services business, and services businesses are durable and do not compound.

The asset is a decade of Go developers who already know the name, which is real distribution and difficult to buy. There is nothing here to acquire except the person. Likely path: continued sponsorship while agents stay fashionable, then back to being a service framework. Position: adopt the library, plan for the maintainer's calendar.

Nothing to buy for sixty engineers, and it only helps the ones writing Go, which narrows the audience before we start. The deployment story is a single command that copies over SSH and runs under systemd with no container involved, which is admirably direct and the opposite of every standard we have written down since 2019.

There is no administrative console and no identity story, because it is a library. Support is genuinely purchasable, which is rarer than it sounds and would satisfy the question legal always asks. Approved with conditions: Go services only, and deploy it through our own pipeline.

Apache-2.0 and the whole thing is interfaces. Registry, broker, store and transport are all swappable, so persistence is a local bbolt file on my laptop and Postgres in production without touching the agent code. Nine providers are wired up, Ollama among them, so the loop runs against the model on my own machine with no key anywhere.

The strange one I like: tools can be metered per call through the x402 payment standard with a pluggable facilitator. I have no use for it yet and I appreciate that somebody built the plumbing before the demand.