tRPC-Agent-Go: A Go-Native Agent Framework That Skips the Python Detour
A Go framework for building production agent systems with graph workflows, tools, memory, A2A, AG-UI, MCP, evaluation, and observability.
At a glance
- What is it?
- tRPC-Agent-Go bundles LLM agents, graph workflows, tools, memory, and evaluation into a single Go stack. It targets teams that want agent systems without leaving the Go ecosystem, but it carries real complexity in skills and evolution.
- Who is it for?
- Adopt tRPC-Agent-Go if your team is committed to Go and needs a single runtime for agents, workflows, tools, and evaluation. Skip it if you need a mature Python ecosystem or if your agent logic is trivial enough for a direct LLM API call.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What tRPC-Agent-Go Actually Solves
Most agent frameworks are Python-first. tRPC-Agent-Go is a deliberate counter: a Go-native runtime for building agent systems that fit into Go services. The README frames it as a stack for "concurrent, observable, easy to deploy" agent applications. That means you get streaming runners, context cancellation, and service-friendly APIs without bridging to a Python process. The target user is a Go backend team that wants to add LLM capabilities to an existing service, not a data science group prototyping in notebooks. It covers the full agent lifecycle: LLM agents, graph workflows, tool calling, session and memory state, knowledge retrieval, self-evolution, evaluation, and OpenTelemetry observability. If you are already running Go microservices, this removes a language boundary that many teams treat as inevitable.
The GraphAgent Core: Type-Safe Workflows Without LangGraph
The central mechanism is GraphAgent, which the README describes as "type-safe graph workflows with multi-conditional routing, functionally equivalent to LangGraph for Go." That is a strong claim. In practice, it means you define nodes and edges as Go types, so the compiler checks your graph structure before you run it. The framework also offers chainagent and parallelagent for simpler orchestrations. The README shows a chain of sub-agents and a parallel group in a few lines. The point of view here: LangGraph compatibility is a marketing phrase, but the type safety is real. You get compile-time validation that a Python graph library cannot give you. The trade-off is that you must think in Go's type system, which is more rigid than Python's dynamic dicts. If your workflow is highly dynamic, that rigidity will fight you.
Getting It Running: Commands and Config from the README
The README's Quick Start section is truncated in the material, but the code snippets show the core setup. You create an agent with llmagent.New, pass it a model, and attach tools. Memory is added at the runner level with runner.WithMemoryService. A runner is the execution context: it takes a user ID and session ID, and it emits events. For observability, you call langfuse.Start(ctx) and pass span attributes to runner.Run. For skills, you create a skill.NewFSRepository pointing at a directory of SKILL.md folders. The repository accepts HTTP URLs for zipped archives, and you can override the cache with SKILLS_CACHE_DIR. There is a Refresh() method to pick up skill changes in long-lived processes. The code examples are concrete enough to copy, but the README does not show the full main function or the model initialization. You will need the pkg.go.dev docs for that.
The Memory and Session Model: Runner-Level State
Memory is not a bolt-on; it is managed at the runner level. The README shows memorysvc.NewInMemoryService() and then passing it to the runner with runner.WithMemoryService(memory). The agent gets memory tools via llmagent.WithTools(memory.Tools()). That design means the runner owns state across sessions, which is a clean separation. The agent does not know where memory lives. The README says "agents remember context across sessions," but it does not specify a persistence backend. The in-memory service is ephemeral, so for production you likely need to implement your own service or find a database-backed one. The material does not list one. That is a gap you should verify before adopting. If your sessions must survive a restart, the default is not enough.
Agent Skills and Self-Evolution: The Boldest, Riskiest Part
The skills system is a folder of SKILL.md files that the agent can load and run on demand. You wire it with skilltool.NewLoadTool and skilltool.NewRunTool, and you can execute code via localexec.New(). The self-evolution service reviews completed sessions, extracts reusable workflows, gates them for quality, and publishes them as managed skills. That is a feedback loop: your agent gets better over time by codifying what worked. The README warns about a real failure mode: if you enable code execution through llmagent.WithCodeExecutor, you should also set llmagent.WithEnableCodeExecutionResponseProcessor(false). Otherwise, Markdown fenced code blocks in assistant text will auto-execute. That is a security footgun. The material does not describe any sandboxing for localexec beyond the name. Running arbitrary code from an LLM is dangerous. You must assume the default executor is not a sandbox and plan your own isolation.
Evaluation and Observability: Built-In, Not Bolted On
The evaluation package is a first-class citizen. The README shows evaluation.New("app", runner, evaluation.WithNumRuns(3)) and then evaluator.Evaluate(ctx, "math-basic"). That gives you an OverallStatus after multiple runs. This is not a separate tool you integrate; it is part of the framework. Observability is similarly direct: langfuse.Start(ctx) and span attributes on the runner. The README also mentions OpenTelemetry tracing and metrics. For a production framework, this is a strong point. You can measure quality over time and trace each run without stitching together three libraries. The trade-off is that Langfuse is a specific vendor; if you use a different tracing backend, you will need to adapt. The OpenTelemetry support is broader, but the README only shows Langfuse in the code.
Protocol Support: A2A, AG-UI, and MCP as Integration Levers
The framework deliberately supports three interop protocols: AG-UI for frontends, A2A for agent-to-agent communication, and MCP for tools. The README lists these as core features, but the truncated material does not show code for them. What is clear is that tRPC-Agent-Go is not a closed silo. You can expose your agent to a web frontend via AG-UI, let other agents talk to it via A2A, and pull in external tools via MCP. The mcptool.New(serverConn) snippet shows MCP tool integration. That is a meaningful differentiator: most Go agent frameworks do not cover all three. The cost is that you must learn each protocol's conventions. The README does not explain how to configure the servers or clients. You will need the docs.
Limitations and the Wrong Tool Cases
The most obvious limitation is the in-memory memory service. For any multi-instance deployment, you need a shared store, and the README does not provide one. The skills execution safety is another boundary: localexec.New() without a sandbox is a liability if your agent processes untrusted input. The self-evolution feature is powerful but unproven in the material; the quality gates are not described in detail, so you cannot know if they are reliable. Also, the framework is Go-only. If your team is not already in Go, or if you need Python's rich ML ecosystem, this is the wrong tool. A simple chatbot that just calls an LLM API does not need this framework; it adds complexity without benefit. The README's own use cases are complex: customer support bots, data analysis assistants, DevOps automation. If your use case is a single-turn Q&A, skip it.
Alternatives: LangGraph and Direct LLM Calls
The README explicitly positions GraphAgent as "functionally equivalent to LangGraph for Go." LangGraph is the real alternative, but it is Python-centric. The difference is not just language: LangGraph has a larger ecosystem of prebuilt components, community examples, and deployment tooling. tRPC-Agent-Go trades that ecosystem for Go's deployment simplicity and type safety. Another alternative is to skip a framework entirely and call an LLM API directly with the official Go SDK. That works for trivial agents, but you lose graph routing, memory, evaluation, and protocol integration. You would have to build all of that yourself. For a serious multi-agent system, that is more work than adopting this framework. The choice is between Python's maturity and Go's operational fit.
Maintenance and Upgrade Cost
The project is under active development, with releases v1.11.2, v1.11.1, and v1.11.0 in August 2026. That cadence suggests a responsive maintainer, but it also means API churn is possible. The README uses v1.x versioning, which implies some stability, but the framework is young. The license is Apache-2.0, which is permissive and safe for commercial use, but you should read the full terms for any patent clauses. The maintenance cost is real: you will need to track releases for security fixes, especially around code execution and skill handling. The README does not mention a migration guide or a deprecation policy. Before adopting, check the CHANGELOG in the repository for breaking changes between minor versions. The evaluation suite helps, but it only measures your tasks, not the framework's stability.
Editorial conclusion
Adopt tRPC-Agent-Go if your team is committed to Go and needs a single runtime for agents, workflows, tools, and evaluation. Skip it if you need a mature Python ecosystem or if your agent logic is trivial enough for a direct LLM API call. Before committing, verify that the GraphAgent API matches your routing needs, that the skill execution sandbox fits your security posture, and that the self-evolution quality gates produce skills you actually trust. The project is Apache-2.0 and actively released, but it is young; run the evaluation suite on your own tasks before production.
Community notes