Architecture on Go Micro

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.

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.

The Evolution of Microservices

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

Every era of distributed systems has solved the problem the previous era created. Microservices solved the coordination cost of the monolith and created a distributed-systems problem. Containers and orchestration solved the deployment problem and created an operational one. The service mesh solved the cross-cutting problem and pushed complexity into the platform. Each step was a response to a concrete engineering constraint, not a trend.

Follow that chain to the end, and the interface the industry converged on — a named, typed, discoverable, independently deployable unit — turns out to be almost exactly the interface a language model needs to call a tool. That convergence is the technical reason agents are the next era.

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.

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.