---
title: "Going All In on AI"
linkTitle: "Going All In on AI"
date: 2026-06-04
description: "Go Micro started as a microservices framework. It's becoming the way you build software that AI agents can use. Here's why we're making that bet."
category:
- opinion
tags:
- AI
- strategy
aliases:
  - /blog/14
---
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.

So what's left?

## The next step

Every few years, something shifts the entire stack. Containers changed deployment. Kubernetes changed orchestration. LLMs are changing how software gets built and used.

Here's what we noticed: Go Micro services were already self-describing. 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* — instead of another service or an API gateway, it's an AI agent.

We added MCP support. Every Go Micro endpoint became an AI-callable tool automatically. No annotations, no wrapper code, no new framework. Just the same service registration that was always there, exposed through a different protocol.

Then we added `micro chat`. An LLM discovers your services, sees every endpoint, and orchestrates across them. No service-to-service calls. No distributed transactions. No saga patterns. The agent reads the result of one call and decides what to do next.

Then we added `micro run --prompt`. Describe a system in plain English, and the AI designs services, writes handlers with real business logic, compiles them, and starts them. Ask for something that doesn't exist mid-conversation, and the agent builds a new service on the fly.

Each step was small. Together, they changed what Go Micro is.

## What It Is Now

Go Micro is a framework for building microservices that AI agents can use.

That's not a pivot. It's an evolution. The same service discovery, RPC, and store abstractions that powered the framework since 2015 are what make the AI integration work. Services register — agents discover them. Endpoints are typed — agents know how to call them. Doc comments describe what things do — agents read them.

The difference is the entry point. Before:

```bash
micro new helloworld
# write handler code
# define proto
# compile proto
# go mod tidy
micro run
```

Now:

```bash
micro run --prompt "a task management system"
micro chat --provider anthropic
> Create a task called 'Ship order 123'
```

The services that come out are the same Go code. You can edit them, version them, deploy them the same way. The framework underneath hasn't changed. But the developer experience is fundamentally different — you go from idea to running services in under a minute.

## Why Now

Three things came together:

**LLM tool calling works.** A year ago, getting an LLM to reliably call the right function with the right arguments was unreliable. Now Claude, GPT-4, and even open models handle multi-step tool orchestration consistently. The technology caught up to the architecture.

**MCP is a real standard.** The Model Context Protocol gives us a wire format that every AI company is adopting. We're not building on a proprietary API — we're implementing an open protocol. Services exposed via MCP work with Claude, with ChatGPT, with any MCP-compatible agent.

**Sponsorship aligns with direction.** Anthropic and Atlas Cloud are sponsoring Go Micro because they see the same thing we do: developers need frameworks that make their code accessible to AI. This isn't a side project within the framework — it's the direction the sponsors are investing in.

## What We're Not Doing

We're not abandoning the framework. You can still `micro new helloworld`, write a handler by hand, and deploy it. The pluggable architecture isn't going anywhere. gRPC, NATS, Consul, Postgres — all still there, all still swappable.

We're also not building another agent framework. There's no LangChain-style chain abstraction, no workflow DSL, no agent graph. Services are the only abstraction. The LLM calls them as tools. That's it. The simplicity is the point.

What we are doing is making AI the primary way people interact with Go Micro. The README leads with `micro run --prompt`. The website leads with "Microservices That AI Agents Can Use." The CLI leads with generation and chat. If you're evaluating Go Micro today, the AI experience is the reason to choose it.

## What's Next

**Better generation.** Services currently use in-memory or file-backed storage. We're moving to persistent store by default, with the full store interface (Postgres, NATS KV) available from day one.

**Smarter agents.** The chat agent currently generates services when capabilities are missing. Next: it should be able to modify existing services, add endpoints, update business logic — all from the conversation.

**Production hardening.** Auth on generated services, rate limiting on the MCP gateway, observability built in. The generation gets you to 80%. The framework gets you to production.

**More providers, more models.** Seven providers today. The `ai.Model` interface makes adding more trivial. As open models get better at tool calling, the barrier to entry drops further.

## The Opportunity

Most microservices frameworks are fighting over the same developers with the same features. Better gRPC support, better Kubernetes integration, better observability hooks. Important work, but incremental.

The AI shift is not incremental. It changes who builds services (anyone who can describe what they need), how services get composed (agents, not code), and how fast systems evolve (minutes, not sprints).

Go Micro is ten years old. It's survived containers, Kubernetes, service meshes, and serverless. Each time, the framework adapted because the core abstraction — small, self-describing, independently deployable services — turned out to be what the next wave needed.

AI agents need exactly that. Small services with typed interfaces that can be discovered, called, and composed. That's what Go Micro has always been. We're just leaning into it.

```bash
curl -fsSL https://go-micro.dev/install.sh | sh
micro run --prompt "your idea here" --provider anthropic
micro chat --provider anthropic
```

---

*Go Micro is open source. Star us on [GitHub](https://github.com/micro/go-micro), join the [Discord](https://discord.gg/G8Gk5j3uXr), or read the [docs](https://go-micro.dev/docs).*
