go-agent

The deciding trait is that this feels like Go rather than like a framework pretending to be one. Behaviour composes through middleware you wrap around a call, the core type is small, and nothing asks you to adopt a project structure. If you have spent an afternoon fighting a framework's idea of how your program should be laid out, that restraint is the whole pitch.

You are the wrong buyer if your team is not already writing Go, because the ecosystem around this is thin. Pick it for a Go service. Pick a Python framework for anything else.

The protocol choice is the dealbreaker to check first. Tool orchestration uses UTCP, and the catalogue of ready-made tool servers built by everyone else does not target it. That is not an argument about which protocol is better. It is an argument about how many integrations exist today, and the answer is fewer. Every tool you need becomes something you write.

What it gets right is the failure plumbing. Retry, timeout and rate limiting are composable middleware rather than options buried in a client.

1. Guardrails are applied at both ends of the call, input and output, which is the correct symmetry and one many frameworks break by validating only what the model returns. 2. Checkpoint and restore turn a long trajectory into a resumable object, so a failure at step forty does not require repeating steps one through thirty-nine.

2. Memory is split into a short-term store and a vector-backed long-term store, a separation that is conventional and correctly conventional. No evaluation is published, and the project claims none.

253 stars, an organisation name, and nothing to buy. Frameworks are the hardest thing in this category to monetise, because the value shows up in somebody else's product and the licence guarantees it never returns. That is fine as an engineering gift and hopeless as a business.

Moat: none, and the switching cost is a weekend for anyone who kept their interfaces clean. Likely path: absorbed by attrition as larger frameworks add the same features, or maintained quietly by its authors. Position: depend on it, pin it, and own the vendoring plan.

A token budget expressed as middleware is the most useful thing on this row for me. It means a ceiling lives in the service, enforced before the request leaves, rather than in a monthly reconciliation nobody reads until it hurts. That is a control I can require in review.

Everything else is not a product question. There is no console, no SSO and no audit log, because this is a dependency my engineers import into something we operate, and the governance is whatever we build around it. Approved with conditions: budgets set centrally, not per developer.

Ollama is a first-class provider defaulting to localhost:11434, which tells me the local case was designed in rather than bolted on afterwards. That single default is the difference between a framework that tolerates my hardware and one that expects it.

Instructions load from a .skills directory in the working directory, so the prompt library is files in my repository under review. Apache-2.0 on top. The whole thing is a Go module I vendor, which means the supply chain is one I already know how to audit.