Version 6 puts agents and services on the same Go runtime
Go Micro v6 treats an agent as another service. A Go method can become an RPC endpoint and an MCP tool, while an agent gets a model, memory, tool access, registry discovery, and an Agent.Chat endpoint. A2A exposes agents to other frameworks. Flows handle steps whose order is known.
The breadth is real. Our checkout contained 1,100 files, about 128,354 source lines, and 10.4 MB of repository data. The framework includes gRPC transport, service discovery, NATS and RabbitMQ brokers, several stores, a typed data layer, model providers, MCP, A2A, agent memory, payments, and deployment commands.
The provider-free path proves plumbing, not model quality
Go Micro v6 documents a provider-free start: micro new helloworld followed by micro run starts a service with no API key. Actual language-model work needs a provider configuration. The README lists hosted providers plus Ollama for local and cloud use, while the prompt-generation example uses an Anthropic, OpenAI, or Gemini key.
Our install obtained 227 Go packages in 34 seconds, so the local dependency fetch was straightforward in a fresh Debian container. Production adds decisions the quick start deliberately avoids: which registry discovers services, which broker carries events, where agent memory and flow checkpoints live, and how model credentials reach each process. File and memory defaults suit a laptop. Postgres, NATS KV, or another shared backend fits restart recovery and multiple instances better.
What happened when we ran it
In our lab, we measured a 34-second install for go-micro commit 24529f1, followed by a successful 102-second build. The environment used golang:1.24-bookworm with 3 CPUs, 8 GB of RAM, no secrets, and no elevated container privileges. The repository had 12 CI workflow files and a Dockerfile. There was no root tests directory, which is normal for Go packages that keep tests beside source files.
The test command completed successfully in 97 seconds. Go reported 162 tests passed and 0 failed out of 162. That is the strongest setup evidence among these three reviews, though it does not measure request throughput, model accuracy, crash recovery, or a live multi-node deployment. We did not attach Postgres, NATS, an LLM provider, MCP clients, or A2A peers, so those paths still need workload-specific verification.
Prompt generation writes and starts Go handlers after confirmation
Go Micro v6's headline micro run --prompt flow asks a model to design services, shows the proposed system, waits for a Generate confirmation, writes Go handlers, compiles them, and starts the result. The README also says an agent can create a missing service during a conversation. That is useful in a disposable development workspace. Before production, review the generated files, restrict tool permissions, run the normal checks, and deploy a known artifact rather than allowing an unattended prompt to alter a live service tree.
Go Micro supplies execution controls for that boundary. MaxSteps limits calls, LoopLimit stops repeated calls with identical inputs, and ApproveTool can block an action before it runs. Wrappers can record results and retries, while MCP adds token scopes, rate limits, circuit breaking, and audit hooks. These controls sit beside the 162-test passing codebase, but policy still belongs to the application: a permissive approval callback is permission, not protection.
SSH and systemd are the stable deployment path
Go Micro's v6 production guide builds Linux binaries, copies them over SSH, and installs systemd services. It documents environment files, a dedicated service user, remote status and logs, and an optional authenticated dashboard. The same guide publishes a default dashboard login of admin and micro, which must be changed before exposure. The MCP security guide separately says micro run disables authentication for development, while micro server enables JWT-based user management.
Kubernetes is earlier. Open issue #4842 describes its CRDs and reconciler as alpha, while the README's one-command production story is micro deploy user@server. Version 6.12.0 adds another operational wrinkle: libraries that choose external broker, registry, store, transport, or profile implementations through flags must blank-import cmd/defaults. Our measured commit still built in 102 seconds, but upgrades need release-note review even within major version 6.
Checkpoints prevent known replays, but storage decides recovery
Go Micro v6's durable-agent example checkpoints a completed tool call before simulating failure, then resumes without running that side effect again. The flow example does the same at named steps such as reserve, charge, and confirm. Both use a shared checkpoint interface. The examples keep state in memory for predictable local runs and tell production users to point recovery at a service store such as Postgres or NATS KV.
That distinction matters more than the word durable. Our 97-second test run passed all 162 tests, but it did not kill a process against a remote checkpoint store or race multiple replicas. Put fixed money movement, inventory changes, and compensations in flows with idempotency at the service boundary. Let an agent choose among tools only where the choice is genuinely open-ended, and test restart behavior on the same database and deployment shape you will operate.
September work is active, with five issues and one pull request open
GitHub recorded 23,050 stars and a last push on September 2, 2026. The open queue contained 5 issues and 1 pull request, and that pull request was updated the same day. Release 6.12.0 shipped on August 25. Those dates show current maintenance, while the small issue count should not be read as a complete defect count.
Go Micro asks a large architectural question: should model calls, service RPC, workflows, MCP, and deployment share one framework? The clean 34-second install, 102-second build, and 162 passing tests justify answering that question with a prototype. For an all-Go system starting fresh, the integration can remove glue. For a company with Kubernetes, Temporal, an existing gateway, and provider policy already settled, the same integration may duplicate systems that are working.