internal/website/blog/25.md
June 17, 2026 • Asim Aslam
When Anthropic began sponsoring Go Micro, we committed to building in the open and reporting progress as it happened. It has been three months. Each post so far covered one change; this one is about what they add up to. Go Micro is becoming a framework for agentic development, the same way it has been a framework for services for the last decade. It's an extension of the existing framework, not a rewrite, because an agent is a distributed system and Go Micro is how you build one.
Ten years ago Go Micro put the hard parts of distributed systems (discovery, transport, encoding, pub/sub, storage) behind a small set of pluggable interfaces with working defaults, so you could build a system of services quickly. The premise this quarter was that an agent is not a special case. An agent is a model, a prompt, and a set of tools, and once it has more than one of anything it is a distributed system again: it has to discover services, call them, persist state, and recover from failure. Building that is what Go Micro is for.
So the work has been to make agents a first-class part of the same framework, and to be clear about the boundary. Go Micro is the substrate, not the brain. It won't out-engineer a prompt library. What it offers is the way you build a system of agents and services together. (The Evolution of Microservices made this argument in full.)
The pattern to notice is how little each piece had to invent.
The agent as a service. micro.NewAgent creates an agent that is a service: it discovers its assigned services as tools, runs the model's tool loop, and registers a Chat RPC endpoint like anything else. There is no separate runtime and no graph DSL; a tool call is an RPC, and the LLM drives it. (Agents for Services laid out the model.)
Plan and delegate. Every agent gets two built-in tools: plan, an ordered plan persisted to its memory and shown back to it on later turns, and delegate, which hands a subtask to another registered agent over RPC, or to a focused ephemeral sub-agent when there is no specialist. Multi-agent systems built from tools rather than a coordinator engine.
Workflows. Not every task should be model-driven. Following Anthropic's taxonomy, Go Micro grew a deterministic counterpart: a Flow is a predefined path triggered by an event. It can run a step itself or hand the event to an agent: the workflow triggers, the agent reasons.
Guardrails. Autonomous agents fail in ordinary ways: they loop, they run away, they take an action they shouldn't. Three guardrails sit at the one point every tool call passes through: MaxSteps, LoopLimit (on by default), and ApproveTool for human-in-the-loop or policy. Orchestration stays in the agent; execution safety is a separate, replaceable concern.
Tool-execution middleware. Because a tool call is an RPC, the middleware Go Micro has always had for clients and servers now applies to tools. AgentWrapTool wraps execution for logging, metrics, or retries, with the same func(next) next shape as client.CallWrapper. The guardrails are themselves wrappers underneath.
Durable workflows. A workflow that calls real services has side effects partway through, and a crash mid-run shouldn't repeat them. Flows became ordered, checkpointed steps that resume where they stopped, backed by a pluggable Checkpoint (store-backed by default, or delegated to Temporal or Restate). It is durable execution as a store plus an interface, with no separate engine to run.
Payments. An agent acting on its own eventually needs to pay for something. Go Micro speaks x402: a tool can require a stablecoin payment and an agent can settle it, with the chain pluggable behind a facilitator.
A consistent state model. Most recently the plumbing got consistent. Services, agents, and flows each keep their state in their own store table (service/{name}, agent/{name}, flow/{name}) through a new store.Scope handle, instead of mutating a global one. Flows register in the registry like agents, so micro flow list and micro agent list are the same command filtered by type, while micro flow runs and micro agent history read durable state. Live state comes from the registry, history from the store.
None of this is a new framework bolted on. It is the existing one, pointed at agents:
There is no graph to learn and no engine to run beside your services. The abstraction is still the service; agents are what you build with it now.
micro call on a laptop are not fine when an autonomous agent can reach an endpoint. v6's theme is flipping those defaults (TLS, identity, bounded execution) without losing the zero-config dev loop.Checkpoint should let a long-running agent survive a restart and resume. The one structural change left is the agent owning its loop.A small end-to-end harness now boots a real world (services, a durable flow that crashes and resumes, and a guardrailed agent), asserts the outcome, and shuts down. It runs on every change against a mock model, and against a live model on a schedule.
The upshot is that building an agent in Go Micro looks like building a service, because underneath it is one. The infrastructure for a system of agents is, for the most part, the infrastructure for a system of services, and that is the decade of work already in the framework. Services remain the foundation; agents are what we are building on top of them.
Thanks to Anthropic, and to everyone in the Discord who has been building and arguing through this with us.