---
layout: blog
title: "Go Micro is Becoming a Framework for Agentic Development"
permalink: /blog/25
description: "Three months ago, with Anthropic's support, Go Micro went all in on AI. A look back at what shipped — agents, workflows, guardrails, payments, durable execution — and where it's heading."
---

# Go Micro is Becoming a Framework for Agentic Development

*June 17, 2026 &bull; 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.

## The idea

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](/blog/19) made this argument in full.)

## What shipped

The pattern to notice is how little each piece had to invent.

**The agent as a service.** [`micro.NewAgent`](/blog/16) 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](/blog/15) laid out the model.)

**Plan and delegate.** Every agent gets two built-in tools: [`plan`](/blog/17), 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](/blog/18), 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](/blog/21): 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](/blog/23) 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](/blog/24) 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](/blog/22): 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.

## The shape of it

None of this is a new framework bolted on. It is the existing one, pointed at agents:

- An agent is a **service**. A flow is a **service**. They register, they're discovered, they're called over RPC.
- A tool call is an **RPC**, so discovery, load-balancing, middleware, and codecs all apply.
- Agent memory, plans, and workflow runs are **store** records. Durability is the **store** plus an interface.
- The events that trigger agents are the **broker**.

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.

## What's next

- **Secure by default.** Defaults that were fine when a human ran `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.
- **Durable agents.** Flows are durable now; the agent's own loop is not yet. The same `Checkpoint` should let a long-running agent survive a restart and resume. The one structural change left is the agent owning its loop.
- **Staying the substrate.** The discipline is to not drift up the stack into prompt tooling or a hosted runtime, and to be the distributed-systems layer for systems of agents.

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 for the sponsorship. Join us in a new [Discord](https://discord.gg/G8Gk5j3uXr) to discuss the future of the project. 
