Search "AI agent framework" and you get a Python answer: LangGraph, CrewAI, AutoGen, Pydantic AI. That's not an accident of popularity — it's an accident of language. (The Python-vs-TypeScript debate for agents never even seats Go at the table, which is exactly the blind spot.) A huge fraction of what those frameworks do is paper over things Python doesn't give you ergonomically: real concurrency, run-wide cancellation, structured timeouts, streaming, durable state. In Go, three of those are keywords. That single fact should change how you evaluate the Go options, and most comparison posts miss it entirely.
So before naming frameworks, name the thing they're actually competing against in Go: nothing.
The reason the framework question inverts#
An agent harness — the loop that calls the model, reads the tool calls it wants, runs them, feeds the results back, and repeats until done — is genuinely small. Zep, which builds a production memory service in Go, put a number on it: the core loop is about forty lines. That's believable because Go's runtime already supplies the parts Python frameworks bolt on:
- Concurrency for parallel tool calls is
goplus a channel. Goroutines start at roughly 2 KB of stack, so fanning out ten tool calls and fanning the results back in is idiomatic, not exotic. - Cancellation and timeouts are
context.Context. Onecontext.WithTimeoutat the top of a run threads through every well-behaved library — HTTP client, database driver, model SDK — and cancels the entire agent at once when the deadline blows. In Python this is precisely the plumbing a framework's runtime exists to provide. - Type-safe tool schemas are just structs. Strict typing gives you the tool-argument validation layer for free, at compile time.
In other words, in Go you are not shopping for a runtime. You're shopping for exactly two things a hand-rolled loop doesn't give you: graph/workflow orchestration for non-trivial control flow, and batteries like tracing and a dev UI. Everything below is a variation on which of those two you're buying.
The three real options#
@repo{cloudwego/eino | https://github.com/cloudwego/eino | Go LLM-app framework with graph/workflow orchestration, type-safe components, ReAct + DeepAgent | Go | 12k}
Eino is the most-starred Go framework in this space and the one that most resembles LangGraph in ambition. Built by ByteDance's CloudWeGo team, it openly draws from LangChain and Google ADK. You get typed components (ChatModel, Tool, Retriever, ChatTemplate), a graph/workflow orchestration layer where components connect into runnable graphs that can themselves be exposed as tools, a ChatModelAgent that runs the ReAct loop internally, and a DeepAgent for sub-agent coordination. It handles stream concatenation and merging across the orchestration automatically — the annoying part of streaming through a graph. Pick Eino when your control flow is a real graph (branches, loops, human-in-the-loop interrupt/resume) and you'd otherwise be reimplementing a router by hand.
@repo{tmc/langchaingo | https://github.com/tmc/langchaingo | Community Go port of LangChain: chains, loaders, retrievers, broadest provider surface | Go | 9k}
LangChainGo is the port play. It mirrors Python LangChain's chains, document loaders, and retrievers, and its main advantage is surface area — the widest set of provider and vector-store integrations in the Go ecosystem, so it's often the fastest way to talk to some obscure backend without writing the client yourself. The tradeoff is maturity: it's still pre-1.0 (latest tag v0.1.14, October 2025) and community-maintained, so the API still moves under you. Reach for it when integration breadth beats API stability for your use case.
@repo{firebase/genkit | https://github.com/firebase/genkit | Google's polyglot GenAI framework; Genkit Go hit 1.0 GA with flows, a dev UI, and built-in OpenTelemetry | Go | 6k}
Genkit Go reached 1.0 GA in September 2025 and sells the third thing: operations. It ships flows, a local Developer UI for inspecting runs, and OpenTelemetry tracing baked into the framework rather than bolted on. If you want the observability story handed to you and you value parity with a JS codebase, Genkit is the batteries-included pick — with the caveat that its orchestration is lighter than Eino's graph model, a tradeoff we've traced before in Genkit vs LangChain vs the Vercel AI SDK.
And the option nobody sells you: none#
The honest fourth choice is a for loop. If your agent is a single model, a handful of tools, and a stop condition, the forty-line harness is not a toy — it's the correct amount of code, and it leaves you owning every line of control flow with zero framework churn to track. Go's idiom of sharing memory by communicating over channels maps cleanly onto parallel tool-call fan-out, and context.Context already gives you the cancellation semantics a framework runtime would otherwise mediate.
In Python you adopt a framework to get a runtime. In Go you already have the runtime, so you only adopt a framework to get a graph. If your agent isn't a graph, you may not need one at all.
The heuristic that falls out of this is clean. Straight-line agent, a few tools? Write the loop. Genuinely branching, stateful, human-in-the-loop control flow? Eino. Need a backend integration you don't want to author? LangChainGo. Want tracing and a dev UI for free and JS parity? Genkit. The mistake — imported wholesale from the Python discourse — is assuming you need any of them before you've counted your tools and looked at how much of the framework you'd actually use. In Go, that count is often zero.
