Go Micro is an agent harness and service framework for Go. A harness is the runtime around an agent — the tools, memory, guardrails, workflows, state, discovery, and protocols it needs to operate a system rather than just answer a prompt. An agent is a distributed system — it discovers services, calls them, holds state, and recovers from failure — so the harness is the runtime services already have, and building an agent is building a service. The roadmap has two jobs: make agentic development excellent, and make the developer experience around it excellent.

The full, current roadmap lives at go-micro.dev/docs/roadmap (source). The highlights:

We are reviewing a direction built around a consistent execution harness and an application lifecycle: build from services and agents, then run, revise, and recover the result. Compatible provider cleanup comes first. The scope of a possible app package and the breaking changes that could justify v7 are in the v7 proposal; this is not a release commitment.

Services, agents (plan/delegate, guardrails, memory, tool middleware, checkpoint/resume, and OpenTelemetry run spans), durable flows, the MCP and A2A gateways (both directions, including A2A streaming, push notifications, and multi-turn continuation), x402 paid tools, secure by default.

The shipped durability contract is documented in Durability and Recovery: agent run checkpoints are opt-in, recovery is explicit, and external side effects are not exactly-once. The older internal design note is historical.

1. Build into what people run, never a separate product (no hosted platform, no enterprise edition, no VC).
2. CLI-first — the CLI is the experience; UI must earn its place, never bloat.
3. The getting-started flow is a contract: 0→1 (scaffold → run → call) and 0→hero (a working multi-agent system) must always work and are verified on every change.
4. Interaction matters as much as running — chatting with agents, inspecting runs and history, end to end.
5. Battle-tested: works across every provider, fails safely, observable.

The forward work is net-new capability, not more hardening. Maintenance (conformance, resilience, DX polish) continues in the background (see Ongoing below) — but it is not the roadmap. This capability work is.

• Agents that pay (x402 buyer in the runtime). The seller side ships (paid tools via the wrapper/x402 middleware) and the buyer x402.Client (a budget-capped Payer that turns a 402 into pay-and-retry) exists — but an agent can't yet autonomously pay for a paid tool. Wire the buyer into the agent tool loop: a budget-capped AgentPayer so an agent that hits a payment-required tool settles it within budget and retries, with the spend gated (like ApproveTool) and observable in RunInfo/traces. This makes go-micro a runtime for autonomous agent commerce. (flagship — decomposed into issues in the loop queue)
• AP2 mandate foundation (#3552) — verifiable payment mandates (a Checkout Mandate and a Payment Mandate), signed and attached over A2A, with the Payment Mandate naming an x402 rail. The authorization/audit layer above A2A + x402 that positions go-micro early in the emerging agent-payments standard (Google's AP2, standardized via FIDO). Additive and opt-in.

• gRPC-reflection MCP — derive MCP tools from any gRPC service via server reflection, not just go-micro-native handlers. Point the gateway at an external gRPC service and its methods become agent tools — a large jump in what an agent can operate.
• Kubernetes operator + CRDs — Agent, Service, and Flow as first-class Kubernetes resources; an operator reconciles them into Deployments wired to the registry. The production deployment story for teams already on K8s.

• Runtime-fitness loop — a persistently-running dogfood app (Mu) plus an operator/canary loop role, so the autonomous loop evolves go-micro against real runtime signal (latency, errors, cost) with canary + rollback — not just green CI. The demand signal the loop is missing today.
• HTTP/3 transport; richer A2A live-stream reconnection (tasks/resubscribe, input-required handoffs); memory management (summarization, retrieval/RAG).

Continuous but capped so it never crowds out capability: cross-provider conformance, failure/resilience (timeouts, cancellation, retry/backoff), the 0→1 and 0→hero getting-started contract, streaming/observability coherence, and a seamless CLI inner loop (scaffold → run → chat → inspect → deploy). Real, but maintenance — the loop should spend the majority of its cycles on the capability above, not here.

The framework is the product, funded by sponsorship from those who run it — not a hosted service, enterprise tier, or venture funding. See the v6 story.

Pick an item, open an issue to discuss the approach, and submit a PR. Or join the Discord. Include tests, run make test and make lint.

• v6 — active development (current).
• v5 — security fixes only.
• v4 and earlier — end of life.

Major versions (v5 → v6) carry breaking changes; minors are backward-compatible. See the v5 → v6 migration guide.