Go Micro: an agent harness that treats agents as services
A Go agent harness and service framework
At a glance
- What is it?
- Go Micro v6 wraps model, memory, tools, planning and guardrails around Go services, so an agent registers, discovers and load-balances like any other endpoint. The design is coherent, but the README is a sales pitch, and the operational details live in guides you have to go find.
- Who is it for?
- Adopt Go Micro if you are already running Go microservices and want agents to call the same endpoints without a second runtime, or if you want MCP and A2A reachability from a single binary. Do not adopt it if you need a stable API across releases, since v4.11.1 and v6.13.0 are both being published, or if you want a Python-native agent library.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Go Micro targets: the runtime around the model loop
Most agent libraries stop at putting a model in a loop. The README names the next set of problems directly: connecting the loop to real tools, scoping what it can touch, preserving state, routing work to specialists, recovering from failures, observing what happened, and letting other agents call it. Go Micro calls that work the harness, and its bet is that the harness should be the same artifact you already deploy.
The intended user is a Go engineer who already runs services. The README states that every endpoint becomes an AI-callable tool, that an agent registers and discovers like a service and exposes Agent.Chat, and that agents, services and flows share one runtime. That last claim is the whole argument: an agent is a distributed system, and building one is building a service. If you accept that framing, you get service discovery, load balancing and RPC for free instead of rebuilding them.
If you do not already run Go services, the framing is less useful. Someone building a single-process script that calls one model and one HTTP API gains nothing from service registration, and would be paying for a framework they do not need.
How services become tools and agents become services
The mechanism is metadata translation. According to the README, endpoint metadata becomes tool schema and RPC executes the call. So a service handler you write in ordinary Go is exposed to the model as a callable tool whose arguments come from the endpoint's request type. The transcript in the README shows the resulting call shape: the agent emits something like project_Project_Create with a JSON body, then task_Task_Create for each item, then summarises.
Agents sit on the same substrate. They register, are discoverable, are load balanced, and expose Agent.Chat. That means an agent is addressable by other agents through the same discovery path as any service, which is what makes the A2A and MCP sections of the README plausible rather than bolted on. Workflows, called flows, are the deterministic counterpart: the README says to use flows when the path is known and dispatch to agents when it is not.
Safety is placed at execution rather than at configuration. The README names MaxSteps, LoopLimit, ApproveTool and tool wrappers, and says they run where actions happen. That is a defensible choice: a step cap enforced in the executor cannot be bypassed by a planner that decides to take a different route. What the README does not give is the default values for MaxSteps or LoopLimit, or what ApproveTool does when no approval channel is attached. Those are the questions I would ask before trusting the guardrail in production.
Getting it running: install, scaffold, curl, and the prompt path
Two install paths are documented. The binary path needs no Go toolchain: curl -fsSL https://go-micro.dev/install.sh | sh. The Go path is go install go-micro.dev/v6/cmd/micro@latest. Note the version in the module path: the install command targets v6 even though v4.11.1 was published on the same day as this material.
The no-key path is the one to try first, because it removes the provider variable from the equation. micro new helloworld, then cd helloworld, then micro run. The README then calls the service with curl -X POST http://localhost:8080/api/helloworld/Helloworld.Call with a JSON body and a Content-Type header. That tells you the HTTP gateway maps service and method names onto a path under /api, and that the default port is 8080.
For the LLM-driven generation path, you export a provider key such as ANTHROPIC_API_KEY and run micro run --prompt "a task management system with categories" --provider anthropic. The README states the AI designs the architecture, you review it, it generates handlers with business logic, compiles them, and starts them, then drops you into a conversation with the running system. The generated code is plain Go on disk and the README says re-running preserves your hand edits.
There is a substantial CLI surface beyond those commands: micro agent demo, micro agent quickcheck, micro agent preflight, micro agent doctor, micro inspect agent <name>, micro chat, micro examples, micro zero-to-hero, and a make docs-wayfinding target. The README presents preflight as something to run before micro run and doctor as something to run after.
Where the harness gets thin: defaults, docs, and two live major versions
The README is a landing page, not a reference. It repeatedly defers to files under internal/website/docs/guides/ such as no-secret-first-agent.md, your-first-agent.md, debugging-agents.md and zero-to-hero.md. That is a lot of the operational story living outside the README, and the install troubleshooting guide is filed under internal/website/docs/guides/install-troubleshooting.md, which is an odd place for a document the quick start tells you to consult when installation fails.
The version situation is the clearest warning sign. The install command pins go-micro.dev/v6, the README links to pkg.go.dev/go-micro.dev/v6, and yet v4.11.1 and v6.13.0 were both published within the same week according to the release list. Two maintained major lines means you need to confirm which one the guides and examples in front of you were written against. Nothing in the supplied material explains the split.
Finally, the guardrail story is stated as a list of names without semantics. MaxSteps and LoopLimit are described as living at execution, but no defaults, units or failure behaviour are given. If your threat model includes a model that loops on a paid tool, you need to know what happens when the limit is hit: does the run abort, return partial state, or retry. The README does not say, and I would not assume.
The honest alternative: LangGraph, or just net/http
The nearest comparison the README itself invites is a Python agent framework in the LangChain family, such as LangGraph. The difference in approach is not language, it is where the graph lives. LangGraph makes the control flow an explicit graph object you construct and run in-process, with checkpointing as a library concern. Go Micro makes the control flow a set of registered services plus durable flows, with discovery and RPC as the transport. If your agent's steps are function calls in one process, the graph model is a better fit and you avoid running a registry and a gateway. If your agent's steps are calls to services that already exist, Go Micro's model means you write no adapter layer.
The second alternative is doing nothing: a Go program using net/http, a database for memory, and hand-written tool dispatch. That is genuinely competitive for one agent with a handful of tools, and it is what Go Micro is trying to save you from once the tool count and the number of agents grow. The README's own framing supports this reading. The harness earns its keep when you have services to expose, agents to route between, and a need for other agents to reach yours over MCP or A2A. Below that threshold it is overhead.
Maintenance cost, the Apache-2.0 licence, and what to check first
Go Micro is Apache-2.0, a permissive licence that permits commercial use and modification provided the licence and notices are retained. That is the standard reading, not legal advice; if you are embedding it in a distributed product, have counsel confirm the notice requirements rather than taking a review's word for it. The README also lists commercial support and a Discord, and names a sponsor, Atlas Cloud, alongside a blog post about 300 AI models behind one integration. Sponsorship and support channels are worth knowing about because they hint at where maintenance effort is directed, but they are not evidence of code quality.
Upgrade cost is the real line item. With v4 and v6 both receiving releases, an upgrade is a migration between major versions of a framework that owns your service registration, your agent runtime and your generated code. The README's claim that re-running generation preserves hand edits matters here: if you have edited generated handlers, you need to verify that behaviour yourself on a branch rather than trusting the sentence.
The concrete first checks are cheap. Scaffold with micro new helloworld, run micro agent preflight before micro run and micro agent doctor after, and read the install troubleshooting guide if PATH or micro --version fails. Then decide whether the version your examples came from is the version you intend to ship. If those two are not the same, stop and resolve that before writing handlers.
Editorial conclusion
Adopt Go Micro if you are already running Go microservices and want agents to call the same endpoints without a second runtime, or if you want MCP and A2A reachability from a single binary. Do not adopt it if you need a stable API across releases, since v4.11.1 and v6.13.0 are both being published, or if you want a Python-native agent library. Before committing, run micro agent preflight and micro agent doctor against a scaffolded project, and confirm which major version the docs and examples actually target.
Community notes