e071084ebe
govulncheck / govulncheck (push) Waiting to run
Harness (E2E) / Harnesses (mock LLM) (push) Waiting to run
Harness (E2E) / Provider harnesses (live LLM conformance) (push) Waiting to run
Lint / golangci-lint (push) Waiting to run
Run Tests / Unit Tests (push) Waiting to run
Run Tests / Etcd Integration Tests (push) Waiting to run
105 lines
5.1 KiB
Markdown
105 lines
5.1 KiB
Markdown
# Go Micro Roadmap
|
|
|
|
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](https://go-micro.dev/docs/roadmap)**
|
|
([source](internal/website/docs/roadmap.md)). The highlights:
|
|
|
|
## Where we are (v6)
|
|
|
|
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.
|
|
|
|
## Principles
|
|
|
|
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.
|
|
|
|
## Now — capability
|
|
|
|
- **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](https://github.com/micro/go-micro/issues/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.
|
|
|
|
## Next — reach & deployment
|
|
|
|
- **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.
|
|
|
|
## Later — exploratory
|
|
|
|
- **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).
|
|
|
|
## Ongoing — hardening & DX (background, not the headline)
|
|
|
|
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.
|
|
|
|
## How it's sustained
|
|
|
|
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](https://go-micro.dev/blog/27).
|
|
|
|
## Contributing & feedback
|
|
|
|
Pick an item, open an issue to discuss the approach, and submit a PR. Or join the
|
|
[Discord](https://discord.gg/G8Gk5j3uXr). Include tests, run `make test` and
|
|
`make lint`.
|
|
|
|
## Version support
|
|
|
|
- **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](https://go-micro.dev/docs/guides/migration/v5-to-v6).
|