# 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 b

---

LLMS index: [llms.txt](/llms.txt)

---

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.

## 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`, and guardrails (`MaxSteps`, `LoopLimit`, `ApproveTool`) built in, plus tool-execution middleware (`WrapTool`) and run metadata.
- **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.

## 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.

## Next — agentic depth

- **Streaming.** Broaden provider-backed `ai.Stream` coverage and keep chat plus A2A `message/stream` working end to end for real chat and long-task UX.
- **Agent observability.** Wire the new `RunInfo` into OpenTelemetry spans so a run — steps, tool calls, delegation — is traceable. This is also what anyone running it in production will need.

## 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 Open Source Project Back from the Dead
](/blog/2026/06/18/bringing-an-open-source-project-back-from-the-dead/) for why.)