Asim Aslam
fdc422c16e
Add a fair, honest positioning piece on the architectural fork with tRPC-Agent-Go (an agent SDK alongside your services / graph DSL) vs Go Micro (one runtime where an agent is a service, every endpoint a tool, durable flows not a graph DSL). New blog post /blog/32 + a parallel section in the existing comparison guide; honest about where tRPC-Agent-Go is ahead (eval, self-evolution, RAG) and that they interoperate over MCP/A2A. Co-authored-by: Claude <noreply@anthropic.com>
4.6 KiB
layout, title, permalink, description
| layout | title | permalink | description |
|---|---|---|---|
| blog | An Agent Is a Service: Go Micro and tRPC-Agent-Go | /blog/32 | Two Go frameworks for building agents, two genuinely different bets. tRPC-Agent-Go is an agent SDK you run alongside your services; Go Micro is one runtime where an agent is a service. Here's the fork in the road. |
An Agent Is a Service: Go Micro and tRPC-Agent-Go
June 30, 2026 • By the Go Micro Team
tRPC-Agent-Go is a strong, production-grade Go framework for building agents — maintained by tRPC-Group and validated inside Tencent. It's broad and serious: LLM, Chain, Parallel, Cycle, and Graph agents; function tools; MCP and A2A; AG-UI streaming; Redis memory and RAG; an evaluation framework; agent self-evolution; and OpenTelemetry. If you're on Tencent's tRPC stack, or you want graph-style orchestration with a large team behind it, it's a good choice.
It's also the clearest example yet of a question worth answering directly: there are now several capable Go agent frameworks. What actually makes them different? With tRPC-Agent-Go the difference isn't a feature — it's a bet about where agents live.
Two bets
Most agent frameworks, tRPC-Agent-Go included, are an agent SDK you run alongside your services. You compose agents and tools into graphs and conditional workflows. Your microservices live somewhere else — in tRPC's case, the tRPC stack — and the agents call into them. Agents are a layer you add on top of a service tier you already have.
Go Micro makes the opposite bet: an agent is a service. There's no separate orchestration substrate bolted onto a service tier, because they're the same runtime.
- Every service endpoint is automatically an AI-callable tool, from registry metadata. You don't wire tools into a graph — you write a service, and it's already a tool.
- An agent is a service — it registers, is discovered, load-balances, exposes
Agent.Chat, and is reachable over MCP and A2A like anything else. - Workflows are durable code paths, not a graph DSL — deterministic
flowsteps where the path is known, dispatch to an agent where it isn't.
The premise is that the line between "your services" and "your agents" is accidental complexity. When they're the same primitives on one runtime, there's less to wire, less to keep in sync, and the path from a service to an agent that uses it is short.
That's also why Go Micro deliberately isn't a graph DSL. Graphs are expressive, and for some teams that's exactly the model they want. But a graph is another thing to learn and maintain next to your services; "it's just services and durable flows" is a smaller surface to hold in your head.
How to choose
| If you want… | Lean |
|---|---|
| A graph/workflow DSL for composing agents and tools | tRPC-Agent-Go |
| To add agents alongside an existing tRPC / service stack | tRPC-Agent-Go |
| First-class evaluation and self-evolution today, with a big team behind it | tRPC-Agent-Go |
| One runtime where services, agents, and flows are the same primitives | Go Micro |
| Existing services to become tools with zero glue, and agents that are services | Go Micro |
| A small, independent framework you can hold in your head | Go Micro |
Honest gaps
tRPC-Agent-Go ships things Go Micro is still building: a first-class evaluation framework, agent self-evolution, AG-UI, and RAG out of the box. Go Micro has the trace foundation (OpenTelemetry run timelines, micro runs) and has the verification/grader loop and richer memory on the roadmap — but if you need those today, they're further along there. We'd rather say that plainly than pretend the checklists match.
They interoperate
This isn't winner-take-all at the protocol layer. Both speak MCP (tools) and A2A (agents), so a Go Micro agent and a tRPC-Agent-Go agent can call each other, and either can consume the other's tools. A natural pattern: run Go Micro as the service-and-agent runtime, and reach an agent built on tRPC-Agent-Go over A2A — or the reverse.
Different frameworks, open protocols. The bet we're making is that when an agent has to operate inside a real system — discover services, call them, hold state, recover, be called by others — it is a distributed system, and the simplest place to build it is the runtime where services already live.
Go Micro is an open source agent harness and service framework for Go. Star us on GitHub.