# micro/go-micro: a Go agent harness and service framework > Go Micro turns an agent's runtime into the same Go services you already deploy. This review covers the harness model, the CLI workflow, the durable flow layer, and where the framework is the wrong choice. **micro/go-micro** — A Go agent harness and service framework - Repository: https://github.com/micro/go-micro - Website: https://go-micro.dev - Stars: 23,069 · Forks: 2,424 - Language: Go - License: Apache-2.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/micro-go-micro ## What problem the harness model solves, and for whom Most agent frameworks stop at putting a model in a loop. The README frames the next problem as operating that loop: connecting it to real tools, scoping what it can touch, preserving state, routing work to specialists, recovering from failures, and letting other agents call it. Go Micro's answer is to make the harness the thing you already deploy. The intended reader is a Go engineer building a service-oriented system who now needs an agent inside it, or an agent that needs to reach existing services. The README states the core claim plainly: "Tools are services", "Agents are services", "Workflows are durable code paths". Endpoint metadata becomes tool schema and RPC executes the call, so an existing handler is reachable by an agent without writing a separate tool adapter. That is a real reduction in glue code if your handlers are already Go Micro services. It is much less useful if your services are not, because then the framework is asking you to move them. The framing also sets an expectation the documentation mostly meets: an agent is treated as a distributed system, so registration, discovery, load balancing and transport are inherited rather than reinvented. The cost of that inheritance is a large dependency graph, which I cover below. ## How the runtime is assembled: services, agents and flows Three layers share one runtime. Services are the base unit: you write handlers, and each endpoint's metadata is exposed as a tool schema that an agent can call over RPC. Agents are services too, which is why the README says they "register, discover, load-balance, and expose Agent.Chat". That means an agent is addressable like any other service, and other agents can reach it over the two interop protocols the project supports, MCP and A2A. Flows are the third layer and the one that carries the clearest design opinion. The README's rule is to "use flows when the path is known; dispatch to agents when it is not". A flow is durable code, so a deterministic sequence of steps survives restarts instead of being re-derived by a model on every run. This split is the most defensible part of the architecture: it keeps the non-deterministic surface as small as the problem allows. Safety sits at execution rather than at definition. The README names MaxSteps, LoopLimit, ApproveTool and tool wrappers as the controls that "run where actions happen". Placing limits on the call path rather than on the agent's configuration is the right call, because a wrapper can be applied to a tool you did not write. The README does not document how these interact when several are set at once, so treat the combination as something to test rather than assume. The generation path is a separate mechanism. `micro run --prompt` asks a model to design services, you review the plan, and it then writes handlers, compiles them and starts them. The README claims the generated code is "plain Go on disk" that you can edit by hand, and that re-running preserves your changes. That is a strong claim about merge behaviour and the README does not explain how preservation is decided, so it is the first thing I would probe on a throwaway project. ## Installing the micro CLI and calling your first service Two install paths are documented. The binary route needs no Go toolchain, and the Go route pins the module path. Both are shown in the README's Quick Start. ```bash # Binary (no Go required) curl -fsSL https://go-micro.dev/install.sh | sh # Or with Go go install go-micro.dev/v6/cmd/micro@latest ``` The README points at an install troubleshooting guide for PATH failures and says `micro --version` is part of the first-run check. If the binary is not on your PATH, that guide is the documented place to look rather than the issue tracker. The fastest path needs no API key at all. You scaffold a service, run it, and call it over HTTP. ```bash micro new helloworld cd helloworld micro run ``` In a second terminal, the README's example posts JSON to the generated endpoint and expects the handler to echo the name back. ```bash curl -X POST http://localhost:8080/api/helloworld/Helloworld.Call \ -H 'Content-Type: application/json' -d '{"name":"World"}' ``` If you prefer containers, the README documents a `micro` image on Docker Hub as `micro/micro` and on GHCR as `ghcr.io/micro/go-micro`. The scaffolding command runs without a network namespace, while the run command uses host networking and mounts the working directory. ```bash docker run --rm -it micro/micro new helloworld docker run --rm -it --network host -v "$(pwd)":/micro/helloworld micro/micro run ``` The repository's Dockerfile also shows the container's default behaviour: it exposes port 8080 and its CMD is `gateway`, so an image started without arguments runs the gateway rather than your service. ## The provider-free on-ramp and the diagnostic commands The README spends unusual effort on the case where you have no model provider configured, and that is a deliberate choice worth noting. The documented order is: verify the install, run the built-in demo, build your own with a mock model, then reach for diagnostics when something stalls. ```bash micro agent demo micro agent quickcheck micro examples micro zero-to-hero ``` The README describes `micro agent demo` as a provider-free first-agent walkthrough and `micro agent quickcheck` as a short recovery map. The diagnostic commands are split by timing: `micro agent preflight` runs before `micro run`, and `micro agent doctor` runs after. There is also `micro inspect agent `, which the README says recovers run history, memory and provider checks. Having both a preflight and a post-run doctor is a sensible split, because the failure modes differ. A preflight can catch a missing key or a bad PATH before you spend a generation cycle; a doctor can only tell you what went wrong after the run. The README does not enumerate what each check inspects, so the output is the documentation. For the generated-code path you need a key. The README lists ANTHROPIC_API_KEY, OPENAI_API_KEY and GEMINI_API_KEY as examples and passes the provider explicitly. ```bash export ANTHROPIC_API_KEY=sk-ant-... micro run --prompt "a task management system with categories" --provider anthropic ``` The README's transcript shows the console reviewing the architecture, generating handlers, compiling them, and then dropping you into a conversation with the running system. ## Where the framework is the wrong tool The dependency graph is the first honest objection. The module's go.mod requires clients for Consul, etcd, NATS, RabbitMQ, Redis, Postgres, MySQL and SQLite, plus gRPC, OpenTelemetry and Zap. Some are indirect, but the direct list is long. If you wanted a minimal microservices toolkit, this is not one. A team that only needs request routing and a registry will spend time deciding which of these to configure and which to ignore. The second limitation is that the framework's value is conditional on adoption depth. "Tools are services" only pays off when the services are already Go Micro services. If you have a Go codebase built on net/http and a separate registry, the tool-schema-from-endpoint-metadata trick does not apply to you, and you are looking at a migration rather than an integration. The third is the generation path itself. The README says re-running preserves hand edits, but it does not document the merge rule, and it does not document rollback for a generated service that compiles but does wrong things. Reviewing the plan before generation is the only documented checkpoint. Treat generated handlers the way you would treat a patch from a contributor you have not worked with: read them before they reach production. Finally, the module path is `go-micro.dev/v6` while the Makefile still references `go-micro.dev/v5/cmd/micro` in its GIT_IMPORT variable, and the release list carries both a v4.11.1 and a v6.13.0 line. That does not mean anything is broken, but it does mean you should read the release notes for the major line you pick rather than assuming the README describes every supported version. ## How it differs from go-kit, Gin and Kratos The comparison that matters is with a service toolkit rather than with another agent framework. go-kit gives you transport, endpoint and service abstractions and leaves the runtime to you; there is no agent, no tool schema and no flow engine. Gin is an HTTP router with middleware, and the README's own framing puts it in a different category: it does not address discovery, RPC or agent tooling at all. Kratos is the closest in scope, since it is also a Go microservices framework with generated code from protobuf definitions and its own transport and registry layers. The difference in approach is where the agent sits. In Kratos-style frameworks, an agent would be an additional component you add and wire to your services. In Go Micro, the agent is a service in the same registry, and your existing endpoints are already its tools. That is the whole bet: less wiring, more inherited runtime. The price is the dependency list and the coupling of your agent's capabilities to the framework's service model. There is also a difference in what gets generated. Kratos-style tooling generates service scaffolding from your protobuf definitions, so the source of truth is a schema you wrote. Go Micro's `micro run --prompt` can generate the services themselves from a natural-language description, with the schema as an output rather than an input. That is a genuinely different workflow, and it is the one with the least documentation about what happens on the second run. ## Licence, maintenance and the cost of upgrading The repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. It does not impose copyleft obligations on your own code. That is a permissive choice consistent with a framework meant to be embedded in proprietary services, but the usual caveat applies: your organisation's policy on dependency licences is the authority, not this article. Maintenance signals are mixed in a way worth stating precisely. The repository is not archived, and its last push was on 2026-09-10. Recent releases include v6.13.0 on 2026-09-03 and v6.12.0 on 2026-08-25, alongside a v4.11.1 on 2026-09-10. The presence of a v4 line receiving a release on the same day as the latest v6 push suggests two supported branches, which is good for stability and bad for anyone hoping the older line will converge with the new one. Upgrade cost is where the module path bites. The Makefile's GIT_IMPORT still points at `go-micro.dev/v5/cmd/micro` while go.mod declares `go-micro.dev/v6`, so build metadata injected through LDFLAGS may not land where you expect if you build the CLI from the Makefile rather than with `go install`. The go.mod also declares `go 1.25.0` with a `toolchain go1.25.12` directive, and the Dockerfile copies a Go 1.26.0 toolchain into the image. Those are three different Go versions in one repository, and only one of them is the minimum your project must satisfy. Pin your own toolchain before you upgrade. ## Conclusion Adopt micro/go-micro if you already run Go services and want the agent runtime to be those services rather than a separate Python stack, and if you are willing to read the repository's guides before trusting a generated service. Skip it if you need a mature, narrowly scoped microservices toolkit with a small dependency surface, or if you cannot accept a go.mod that pulls in Consul, etcd, NATS, RabbitMQ, Redis, Postgres, MySQL and SQLite client libraries. Verify first that the CLI installs cleanly on your platform, that `micro agent preflight` passes, and that the provider you intend to use is one the repository actually lists. ## FAQ ### What is micro/go-micro used for? It is an agent harness and service framework for Go. According to the README, you write services whose endpoints become AI-callable tools, build agents that register and are reachable over MCP and A2A, and use durable flows for the deterministic parts of a workflow. ### Is there a Go framework specifically for microservices development? Yes. Go Micro is one: the module is go-micro.dev/v6, the repository ships registry, broker, transport, selector and server packages, and the README describes services, agents and flows sharing a single runtime. Its distinguishing feature is that agents are services in the same registry rather than a separate layer. ### How does micro/go-micro compare with Gin? They operate at different levels. Gin is an HTTP router, while Go Micro addresses discovery, RPC, agent tooling and durable flows. The README's own framing is that an agent is a distributed system, so the framework inherits registration, load balancing and transport instead of leaving them to you. ### How does micro/go-micro compare with Kratos? Both are Go microservices frameworks with generated code, but the agent sits differently. In Go Micro an agent is a service in the same registry and existing endpoints are already its tools, whereas a Kratos-style setup would add an agent as a separate component. Go Micro can also generate the services themselves from a prompt. ### How does micro/go-micro compare with go-kit? go-kit provides transport, endpoint and service abstractions and leaves the runtime to you. Go Micro supplies the runtime as well: tool schema derived from endpoint metadata, agents registered as services, MCP and A2A interop, and a durable flow layer for known execution paths. ## Sources - [License: Apache-2.0](https://github.com/micro/go-micro/blob/master/LICENSE) - [micro/go-micro on GitHub](https://github.com/micro/go-micro) - [Project website](https://go-micro.dev) - [README](https://github.com/micro/go-micro/blob/master/README.md) - [Releases](https://github.com/micro/go-micro/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/micro-go-micro