The autonomous loop that builds Go Micro is now a command. micro loop init drops a planner, builder, triage, coherence, and release pipeline into any repository — GitHub Actions as the runtime, editable prompt files as the policy. And Go Micro now runs on it.
A field guide to the agent-framework landscape — from LangChain and the first wave, through the two layers of a harness and the rise of loop engineering, to where the frameworks diverge. And why Go Micro’s answer is that an agent is a service.
Go Micro is increasingly built by an autonomous loop of two AI agents — Codex implementing scoped increments, Claude Code orchestrating, the human setting direction. Here’s how the loop actually works, including the parts that broke.
The first wave of agent frameworks put a model in a loop. The harder problem is operating that loop — and that’s what Go Micro is: the harness around the agent.
A real thing you can build with Go Micro: a support desk where a customer ticket triggers an agent that looks up the customer, sets priority, and replies — with a human-in-the-loop gate on the one action that touches a customer.
Go Micro agents already call each other over RPC. Now they speak the Agent2Agent protocol too — reachable by, and able to reach, agents built on any framework. Cards are generated from the registry, the same way the MCP gateway derives tools.
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.
An autonomous agent fails in mundane ways — it loops, it runs away, it takes an action it shouldn’t. Go Micro separates orchestration from execution safety, and gives every agent three guardrails at the point where tools actually run.
Agents that act on their own eventually need to pay on their own. Go Micro now speaks x402 — the HTTP 402 payment standard — so a tool can require a stablecoin payment and an agent can settle it, with the chain pluggable behind a facilitator.
Most agents wait for a human to type something. The useful ones don’t — they run because something happened in the system. A Flow turns an event into the prompt, and an agent acts on its own.
Go Micro made services easy by being opinionated, batteries-included, and pluggable. We’re applying the same model to agents — a model, memory, and tools that compose like a service does.
We spent two posts on agents that plan and delegate. Here’s the other half: when the path is known, you want a workflow — predictable, event-driven, deterministic. In Go Micro they’re the same building blocks, two modes.
An agent shouldn’t just react tool by tool. It should form intent — plan what it’s doing — and direct intent — delegate what it shouldn’t do itself. Go Micro now gives every agent both, as plain tools.
Agent is now a first-class abstraction in Go Micro — alongside Service and Flow. Build intelligent agents that manage your services in Go.
What if every service had an agent responsible for it? Not embedded in the service, but created to manage its lifecycle. A design for distributed AI agents on top of microservices.
micro run –prompt generates real services with business logic, compiles them, starts them, and lets you talk to them. When you need more, the agent builds new services mid-conversation.
A complete teardown of micro chat — how to build an LLM agent that discovers and orchestrates your services, with every line explained.
Exploring the concept of LLM-powered service orchestration — what happens when micro chat becomes a persistent, event-driven flow engine.
Introducing micro chat — an interactive CLI that discovers your services, turns them into tools, and lets you orchestrate them through natural language.
How existing Go Micro services become agent-accessible with zero code changes. A walkthrough using the micro/blog platform as a real-world example.
Build three microservices and let an AI agent manage them with natural language — no glue code, no API wrappers, just Go comments