AI on Go Micro

The Loop, Shipped: Introducing micro loop

Thu, 02 Jul 2026 00:00:00 +0000

A few weeks ago we wrote How Go Micro Builds Itself: a loop of two AI agents — Codex writing scoped increments, Claude Code orchestrating and reviewing, a human setting direction — kept honest by CI. It was our own thesis, an agent operating a system, pointed at the repository that defines the thesis.

People asked the obvious question: can I run that on my repo?

Now you can. micro loop init drops the whole pipeline into any repository, and — the part that makes it real rather than aspirational — Go Micro itself now runs on it. The workflows that maintain this project are generated by the same command we’re shipping to you.

An Agent Is a Service: Where Agent Frameworks Are Going

Tue, 30 Jun 2026 00:00:00 +0000

There are now a lot of ways to build an agent. LangChain and LangGraph, LlamaIndex, CrewAI, Microsoft’s AutoGen, Google’s ADK, the model labs’ own SDKs, and — most recently in our own backyard — tRPC-Agent-Go from Tencent. They are not all solving the same problem, and the places they differ tell you a lot about where this is heading.

This is a field guide to that landscape, and an honest account of where Go Micro sits in it.

How Go Micro Builds Itself

Thu, 25 Jun 2026 00:00:00 +0000

Go Micro is an agent harness. The most honest test of that claim is to use agents to build it — so increasingly, we do. A scheduled loop of two AI agents now opens issues, writes increments, and merges its own pull requests against this repo, on a cadence, with a human setting direction rather than typing the code.

This isn’t a stunt. If a harness is good enough to operate a loop that builds itself, that’s evidence it’s good enough to operate the loop that builds your software. So we pointed the thesis at itself and wired up the loop. This post is how it actually works — including the parts that didn’t, because the failure modes are the interesting part.

Go Micro is an Agent Harness

Wed, 24 Jun 2026 00:00:00 +0000

The first wave of agent frameworks solved one problem: put a model in a loop with some tools. That’s the easy part now. The harder problem — the one that decides whether an agent makes it past a demo — is operating that loop.

Operating a loop means connecting it to real tools, scoping what it can touch, keeping state when the process restarts, routing work to specialists, recovering from provider failures, seeing what it did, and letting other agents call it. That’s harness work, and it’s most of the actual job.

Go Micro Joins OpenAI's Codex for Open Source

Tue, 23 Jun 2026 00:00:00 +0000

Go Micro has been accepted into OpenAI’s Codex for Open Source program. OpenAI is covering six months of ChatGPT Pro — and with it, access to Codex — to support the day-to-day work of maintaining the project.

What the grant is

Codex for Open Source backs maintainers directly: the constant, unglamorous work of reviewing changes, cutting releases, triaging issues, and keeping quality high. That’s most of what maintaining a framework actually is, and it’s the part that rarely gets funded. OpenAI putting Codex against it is a real, practical help.

Building a Support Agent in Go

Fri, 19 Jun 2026 00:00:00 +0000

Most agent demos are a chat box wired to one tool. Real systems aren’t that — they’re a handful of services, an agent that operates them, something that triggers the agent without a human typing, and a gate on the actions you don’t want it taking on its own. Here’s that, built end to end. The full code is in examples/support; it runs with no API key.

The scenario: a customer files a ticket. That should trigger an agent to look the customer up, set a priority, and reply — but it must not email anyone without passing an approval gate.

Agents Across Frameworks: A2A

Thu, 18 Jun 2026 00:00:00 +0000

Inside a Go Micro system, agents already talk to each other. An agent is a service with an Agent.Chat endpoint, so delegate just calls another agent over RPC. That works as long as everyone is on Go Micro. The moment an agent is built on a different framework, the conversation stops: it can’t call yours, and yours can’t call it.

A2A — the open Agent2Agent protocol — is the standard that closes that gap, and Go Micro now speaks it.

Go Micro is Becoming a Framework for Agentic Development

Wed, 17 Jun 2026 00:00:00 +0000

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.

Durable Workflows

Wed, 17 Jun 2026 00:00:00 +0000

A workflow that calls real services is rarely instant and rarely side-effect-free. It reserves inventory at step one, charges a card at step two, sends a confirmation at step three. Each of those changes the world. So when the process dies between step two and step three — a deploy, an OOM, a node going away — you can’t just run it again from the top: that reserves twice and charges twice. And if the workflow was triggered by an event with no human watching, nobody noticed it died at all.

Agent Guardrails

Tue, 16 Jun 2026 00:00:00 +0000

The interesting failures of an autonomous agent aren’t dramatic. It calls the same tool with the same arguments over and over, making no progress. It takes thirty steps on a task that needed three, quietly running up cost. It performs an action that a human, or a policy, should have stood in front of. When an agent runs on its own, there’s no one watching to catch any of it.

A useful way to think about this — which came up in a community discussion recently — is to separate orchestration from execution safety. The model decides what to do; that’s orchestration. Whether a decided action is actually allowed to run is a separate concern, and it shouldn’t be tangled into the model or the services. Go Micro keeps them apart: every tool call an agent makes passes through one choke point, and that’s where the guardrails live. They apply uniformly to service calls, custom tools, and delegate, and they touch neither the model nor your services.

Integrating x402: Payments for Agents

Mon, 15 Jun 2026 00:00:00 +0000

The last post was about agents that run on their own — triggered by an event, acting without a human prompt. Follow that one step further and you reach something agents can’t do yet in most systems: pay. An autonomous agent that calls an API, rents compute, or uses another agent’s service will, sooner or later, need to settle for it — without a person reaching for a credit card. There is now a standard for exactly that, and we’re integrating it.

When the Event Is the Prompt

Mon, 15 Jun 2026 00:00:00 +0000

Almost every agent demo starts the same way: a human types a prompt, the agent responds. That framing is a habit from chat, and it hides the more useful case. The agents worth running don’t wait for you to ask. They run because something happened — a user signed up, a payment failed, a deployment finished, a metric crossed a line. In those systems there is no prompt, because there is no human in the loop. The event is the prompt.

Doubling Down on Agents

Wed, 10 Jun 2026 00:00:00 +0000

Go Micro made microservices easy by having an opinion. You called micro.New, and it composed the pieces a service needs — service discovery, RPC, pub/sub, config, storage — behind one interface, with defaults that worked out of the box. You could test an endpoint in minutes, and when you needed to, you swapped any piece: mDNS for etcd, HTTP for gRPC, in-memory for Postgres. Opinionated, batteries-included, and pluggable. That combination is why people used it.

Not Everything Should Be an Agent

Mon, 08 Jun 2026 00:00:00 +0000

The last two posts were about agents — the abstraction, and then agents that plan and delegate, directing their own work over many turns. That’s the exciting part. It’s also, honestly, the part you should reach for least often.

An agent decides its own path at runtime. That’s powerful when the task genuinely needs it, and a liability when it doesn’t — you trade predictability, latency, and cost for flexibility you may not want. Most real work has a known shape: when this event happens, do these things. For that, you don’t want a model improvising. You want a workflow.

Agents That Plan and Delegate

Sun, 07 Jun 2026 00:00:00 +0000

When we introduced micro.NewAgent(), an agent was already a service with an LLM inside: scoped tools, persistent memory, and a micro chat router that dispatches across agents. And in Agents for Services we made the case that intelligence should be distributed — agents coordinate “not through code… through understanding.”

This post is the next beat. An agent that only reacts, one tool call at a time, isn’t really understanding anything — it’s improvising. Two things turn reaction into intent: the agent should plan what it’s doing before it does it, and delegate what it shouldn’t be doing itself. Go Micro now gives every agent both.

Introducing micro.NewAgent()

Fri, 05 Jun 2026 00:00:00 +0000

Go Micro now has three core abstractions:

service := micro.NewService("task") // capability
agent := micro.NewAgent("task-mgr") // intelligence
flow := micro.NewFlow("onboard-user") // event-driven orchestration

Service has been the foundation since 2015. Flow added event-driven LLM orchestration. Now Agent completes the picture — an intelligent layer that manages services, with scoped tools, persistent memory, and multi-agent coordination.

What an Agent Is

A Service has endpoints and handles requests. An Agent knows how to use those endpoints intelligently. The service doesn’t know about its agent. The agent knows about its services.

Agents for Services: A New Model for Microservices

Thu, 04 Jun 2026 00:00:00 +0000

Microservices solved monolithic code. Split it into small, independent units. But we centralised the intelligence — one agent, one brain, managing everything. That’s just a different kind of monolith.

What if every service had its own agent? Not embedded in the service. Created separately, assigned to manage it. The service is the capability. The agent is the intelligence.

The Problem with One Agent

Right now, micro chat is a single agent. It discovers every service in the registry, sees every endpoint, and orchestrates across all of them. You ask it a question and it figures out which service to call.

Going All In on AI

Thu, 04 Jun 2026 00:00:00 +0000

I started Go Micro in 2015 because building microservices in Go was too hard. Too much boilerplate, too many decisions before you could test a single endpoint. The idea was simple: sane defaults, pluggable architecture, get out of the developer’s way.

Eleven years later, the framework works. Service discovery, RPC, pub/sub, config, store — all pluggable, all production-tested. 23,000 stars on GitHub. But let’s be honest: the microservices ecosystem moved on. Kubernetes won infrastructure. gRPC became the default transport. Service meshes handle the network. The problems Go Micro originally solved are mostly solved.

From Prompt to Production: AI-Generated Microservices That Actually Run

Wed, 03 Jun 2026 00:00:00 +0000

Every code generator stops at the same point: here’s some files, good luck. You get a skeleton, wire it up yourself, hope it compiles. We wanted something different.

micro run --prompt "a task management system"

That’s not scaffolding. Two services start, register, and respond to requests. An AI agent can create tasks, organize categories, and orchestrate across services immediately. And when you need a capability that doesn’t exist — shipping, payments, notifications — the agent builds it mid-conversation.

Build Your Own AI Agent CLI in 150 Lines

Sat, 30 May 2026 00:00:00 +0000

We introduced micro chat — a CLI that lets you talk to your microservices through an LLM. People asked how it works under the hood. The honest answer: it’s about 150 lines, and there’s no magic. This post walks through every piece so you can build your own — for go-micro, for your own framework, or for whatever services you have.

Tools as Services: Why Go Micro Was Always Ready for AI

Sat, 30 May 2026 00:00:00 +0000

When people see micro chat or the MCP gateway, they assume we built something new. We didn’t. We exposed something that was already there.

Go Micro has always treated services as self-describing, addressable units. Every service registers its name, endpoints, and request types with the registry. Every endpoint is callable through a standardised path. The only thing that changed is who’s calling.

The Pattern

Go Micro was built on one idea: a service should be accessible the same way regardless of how you access it.

From Chat to Flows: What If Your Services Could Orchestrate Themselves?

Fri, 29 May 2026 00:00:00 +0000

We shipped micro chat recently — an interactive terminal where you talk to your services through an LLM. You say “list all users over 30 and send each a welcome email,” and the model figures out which services to call, in what order, with what arguments.

It works. But it’s interactive and ephemeral. You type a prompt, get a result, move on. What if you could save that prompt as a flow and trigger it from an event?

micro chat: Talk to Your Services

Fri, 29 May 2026 00:00:00 +0000

We built micro chat — a CLI that lets you talk to your microservices through an LLM. It discovers every service in the registry, exposes each endpoint as a tool, and lets a model decide which RPCs to call based on what you ask.

ANTHROPIC_API_KEY=sk-ant-... micro chat --provider anthropic

> list all users
 → called users_Users_List({})
There are 3 users: Alice, Bob, and Charlie.

> send a welcome email to Alice
 → called email_Email_Send({"to":"alice@example.com","template":"welcome"})
Done, welcome email sent to Alice.

> how many orders were placed this week?
 → called orders_Orders_Count({"since":"2026-05-22"})
There were 47 orders placed this week.

No glue code. No API wrappers. No tool definitions. You write normal Go services with doc comments, and micro chat turns them into things an LLM can call.

Atlas Cloud Sponsors Go Micro: 300+ AI Models, One Integration

Thu, 28 May 2026 00:00:00 +0000

We’re excited to announce that Atlas Cloud is sponsoring Go Micro as an official AI provider partner. Atlas Cloud is now a first-class provider in the ai package, giving Go Micro users access to 300+ models across text, image, and video through a single integration.

The Sponsorship

Atlas Cloud is an enterprise AI infrastructure platform that provides a unified API for LLM, image, and video generation. They partner with OpenRouter and ComfyUI, offer SOC 2 and HIPAA compliance, and run a custom inference engine (Atlas Photon) with FP4 quantization for fast, cost-effective inference.

Your Microservices Are Already an AI Platform

Thu, 05 Mar 2026 00:00:00 +0000

Here’s the pitch: you have microservices. They already have well-defined endpoints, typed request/response schemas, and service discovery. An AI agent needs the same things — a list of tools with input schemas and descriptions. The gap between “microservice endpoint” and “AI tool” is surprisingly small.

With Go Micro + MCP, that gap is zero lines of code.

Agents Meet Microservices: A Hands-On Demo

Wed, 04 Mar 2026 00:00:00 +0000

We talk a lot about AI-native microservices. Time to show it. In this post we’ll build three services — projects, tasks, and team — and then hand them to an AI agent. The agent will create projects, assign tasks, and query team skills using nothing but natural language.

No API wrappers. No tool definitions. Just Go comments.

The Setup

The full code is at examples/agent-demo. Here’s the architecture:

flowchart TD
 User[<b>User</b> <br/>natural language] --> Agent[<b>AI Agent</b> <br/>Claude, GPT, etc.]
 Agent --> Gateway[<b>MCP Gateway</b> <i>:3000</i>]

 Gateway --> Project[<b>ProjectService</b><br/>Create / Get / List]
 Gateway --> Task[<b>TaskService</b><br/>Create / List / Update]
 Gateway --> Team[<b>TeamService</b><br/>Add / List / Get]

The MCP gateway discovers all three services automatically and exposes 9 tools. The agent sees them and knows how to call them — because we wrote good comments.

Making Microservices AI-Native with MCP

Wed, 11 Feb 2026 00:00:00 +0000

We’re excited to announce MCP (Model Context Protocol) support in Go Micro v5.15.0 — making your microservices instantly accessible to AI tools like Claude.

The Vision

Imagine telling Claude: “Why is user 123’s order stuck?”

Claude responds by:

Calling your users service to check the account
Calling your orders service to inspect the order
Calling your payments service to verify the transaction
Giving you a complete diagnosis

No API wrappers. No manual integrations. Your services just work with AI.