Older documentation. Start with the current guides.

Roadmap

Go Micro is a framework for building agents and services in Go. An agent is a distributed system — it discovers services, calls them, holds state, and recovers from failure — so building an agent is building a service. The roadmap has two jobs: make agentic development excellent, and make the developer experience around it excellent. Nothing else.

Towards v7 — proposal

A v7 proposal explores a consistent model/agent execution contract and an application lifecycle built on services. Work starts with compatible provider cleanup; an app package will be shaped by a complete build, use, revise, and recover path in Mu and the CLI. This is a design review, not a release commitment.

Where we are (v6)

The foundation is in place:

• Services — register, discover, RPC, events; every endpoint is automatically an MCP tool.
• Agents — a model with memory and tools that manages services, with plan, delegate, guardrails (MaxSteps, LoopLimit, ApproveTool), tool-execution middleware (WrapTool), run metadata, checkpoint/resume, and OpenTelemetry run spans built in.
• Flows — durable, event-driven workflows: ordered steps that checkpoint and resume after a crash.
• Interop — the MCP gateway (services as tools) and the A2A gateway (agents as agents, both directions, including A2A streaming, push notifications, and multi-turn continuation), both generated from the registry; x402 for paid tools.
• Secure by default — TLS verification on, state scoped per component.

See Durability and Recovery for the exact shipped boundaries: opt-in agent checkpoints, explicit recovery, and no exactly-once external side-effect or multi-replica lease guarantee.

Principles

These constrain everything below:

1. Build into what people run, never a separate product. No hosted platform, no enterprise edition. Improvements go deeper into the framework, not beside it.
2. CLI-first. The CLI is the experience. Any UI must be genuinely good and earn its place; bloat gets trimmed, not maintained.
3. The getting-started flow is a contract. 0→1 (scaffold → run → call) and 0→hero (the ~10 steps to a working multi-agent system) must always work, and every change is checked against them.
4. Interaction is as important as running. Talking to an agent, inspecting runs and history — end to end, not just “it starts.”
5. Battle-tested. Works across every provider, fails safely, and is observable.

Now — hardening (“functional on every level”)

The priority is that what exists works everywhere, under real conditions.

• Cross-provider conformance. Each of the seven providers implements its own tool-call loop; today only the mock and one live provider are exercised. A suite that runs the same agent scenario (tool-calling, multi-step, plan/delegate, guardrails) across every provider, gated on keys, on a schedule.
• Failure & resilience. Provider timeouts, rate limits, and cancellation mid-run; deadline/context propagation through the agent loop; retry and backoff at the model call.
• The getting-started contract. Define and CI-verify the 0→1 and 0→hero flows so they can’t silently break.

Shipped agent depth

• Durable agent loop. Opt-in Checkpoint support now lets agent Ask and streaming runs persist, list pending work, and resume without replaying completed tool calls. Human-input pauses resume through explicit input helpers.
• Agent observability. RunInfo now feeds OpenTelemetry spans and events for agent runs, model turns, tool calls, retries, delegation lineage, and resume checkpoints so production runs are traceable.

Next — agentic depth

• Streaming. Broaden provider-backed model.Stream coverage and keep chat plus A2A message/stream working end to end for real chat and long-task UX.
• Resume operations polish. Keep improving CLI/docs breadcrumbs for finding pending agent runs and deciding whether to call resume, resume-input, or stream resume in production.
• Observability hardening. Keep span attributes and run inspection coherent across agents, flows, and gateways as more providers and workflow paths are exercised.

Later

• Memory management — summarization and retrieval (RAG) beyond a fixed buffer.
• Human-in-the-loop — broaden pause/resume UX around input-required runs and approvals.
• A2A — richer live-stream reconnection (tasks/resubscribe) and input-required handoffs.

Developer experience (ongoing)

• The CLI inner loop — scaffold → run → chat → inspect (runs/history) → deploy, made seamless. This is the main lever for “dramatically improve the experience.”
• UI discipline — keep only high-value, well-built surfaces; trim or cut the rest. The web UI should never be a worse version of the CLI.
• Examples & a real-world build — a maintained example that builds something real with the framework, doubling as the 0→hero reference and continuous battle-testing.
• Docs in lockstep — the getting-started guide tracks the code on every change.

How it’s sustained

The framework is the product. It’s funded by sponsorship from the people and companies who run it — not a hosted service, not an enterprise tier, not venture funding. The model is deliberate: keep refining the framework, aligned users adopt and depend on it, and that dependence funds the work. (See Bringing an OSS project back from the dead for why.)

Feedback

Open an issue or start a discussion on GitHub, or join the Discord.