internal/website/blog/27.md
June 18, 2026 • Asim Aslam
I started Go Micro in January 2015. Eleven years later I just tagged v6. In between, the project was — for a stretch — effectively dead. This is the story of how it got there and how it came back, because the second part turned out to matter more than I expected.
The first version was a project to make microservices simple in Go: registry, transport, RPC, and pub/sub behind a small set of pluggable interfaces. It found an audience. Up to v1 it was bootstrapped, then carried by corporate sponsors who ran it in production.
v2 is where it changed shape. I raised venture funding and started a company around it. The open source library and the company's ambitions became hard to separate — a common trap, and I walked into it.
v3 leaned further in: an iteration of the company as a platform-as-a-service built on top of the framework. There was real effort behind it, but it wasn't what people had come for, and it didn't find its market.
Then the quiet part. The company wound down. I stepped away. For a while Go Micro just sat there — issues piling up, commits slowing to nothing, a README describing a project no one was driving. Most open source projects that reach this point stay there.
v4 and v5 were me coming back to it and trying to remember what it was actually for. The honest answer was: a framework. Not a company, not a platform — a way to build distributed systems in Go without the boilerplate. So I started stripping it back toward that.
The thing that changed the trajectory was an open-source grant for Claude Code from Anthropic. I want to be plain about this: working on a large, aging codebase alone is slow, slow kills momentum, and lost momentum is how a project dies the second time. Building with Claude Code changed the pace enough that ideas I'd been carrying for years could finally ship. The revival is partly about vision and partly about being able to move again.
Coming back to it, the vision sharpened rather than reset. The original goal was to make building distributed systems simple. What became clear more recently is that agents are distributed systems too. An agent is a model, a prompt, and a set of tools — and the moment it has more than one of anything, it has to discover services, call them, hold state, and recover from failure. That is the exact problem Go Micro already solved for services.
So services and agents aren't two products. They're complementary. An agent manages services; a service is a tool an agent calls. Building an agent looks like building a service, because underneath it is one.
That idea is what v4 through v6 turned into:
And the interop that makes it matter beyond a single codebase: MCP, so every service is automatically a tool any AI agent can call, and A2A, so every agent can be discovered and called by agents on other frameworks. Both are generated from the registry — the same machinery that's been there since 2015.
v6 is the marker that the revival is real. It's secure by default, it leads with agents, and it moves the whole thing to a new module path. It is deliberately not a rewrite: the decade of services work is the foundation, and v6 is that foundation pointed at agents.
I don't think projects usually come back from where this one was. The ones that do come back because the original idea turns out to matter again, and because someone can move fast enough to act on it. Both happened here — agents made the distributed-systems problem urgent again, and Claude Code made it possible to ship as one person.
Thanks to Anthropic for the grant and the sponsorship, to AtlasCloud, and to everyone in the Discord who showed up while this was still finding its feet. Go Micro is back, and it's clearer about what it's for than it has ever been.