5.0 KiB
layout
| layout |
|---|
| default |
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.
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.
Principles
These constrain everything below:
- Build into what people run, never a separate product. No hosted platform, no enterprise edition. Improvements go deeper into the framework, not beside it.
- CLI-first. The CLI is the experience. Any UI must be genuinely good and earn its place; bloat gets trimmed, not maintained.
- 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.
- Interaction is as important as running. Talking to an agent, inspecting runs and history — end to end, not just "it starts."
- 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/
contextpropagation 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
Checkpointsupport now lets agentAskand streaming runs persist, list pending work, and resume without replaying completed tool calls. Human-input pauses resume through explicit input helpers. - Agent observability.
RunInfonow 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
ai.Streamcoverage and keep chat plus A2Amessage/streamworking 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-requiredruns and approvals. - A2A — richer live-stream reconnection (
tasks/resubscribe) andinput-requiredhandoffs.
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 blog/27 for why.)
Feedback
Open an issue or start a discussion on GitHub, or join the Discord.