# Eino: A Go Framework for Building LLM Applications and Agents

> Eino is an Apache-2.0 Go framework from CloudWeGo that provides component abstractions, a graph-based composition system, and an Agent Development Kit for building LLM-powered applications, drawing from LangChain and Google ADK while following Go conventions.

**cloudwego/eino** — The ultimate LLM/AI application development framework in Go.

- Repository: https://github.com/cloudwego/eino
- Website: https://www.cloudwego.io/docs/eino/
- Stars: 13,215 · Forks: 1,117
- Language: Go
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/cloudwego-eino

## Go-First LLM Orchestration for Service Teams

Eino targets Go developers who build backend services and want LLM capabilities without switching languages or wrapping a Python service in an RPC layer. The framework is maintained by CloudWeGo, the open-source group behind several ByteDance infrastructure projects.

The design draws from LangChain and Google ADK. Unlike those Python-first frameworks, Eino is designed to follow Go conventions: typed interfaces, composition over inheritance, and explicit error handling. The repository name `eino` is pronounced 'aino'.

The framework is organized into four GitHub repositories that together form the full system: the core Eino module (type definitions, streaming, orchestration, agents), EinoExt (component implementations for specific providers), Eino Devops (visual development and debugging tools), and EinoExamples (working code for common patterns).

The minimum Go version is 1.18, which means the framework is usable without upgrading to the most recent toolchain. The go.mod uses only a small set of direct dependencies: `bytedance/sonic` for JSON, `google/uuid`, `gonja` for template rendering, and the testing framework. The lean dependency surface is intentional and keeps the compile time low for teams integrating Eino into existing services.

## Three Building Blocks: Components, Composition, and Agents

Eino organizes LLM application construction around three layers.

Components are reusable abstractions: `ChatModel`, `Tool`, `Retriever`, `Embedding`, and `ChatTemplate`. Each abstraction has a typed Go interface. Official implementations are provided in EinoExt for OpenAI, Claude, Gemini, Ark, Ollama, and Elasticsearch. Writing a new component means implementing the relevant interface.

Composition connects components into graphs and workflows. The `compose` package lets developers define directed graphs where nodes are components or lambda functions and edges define data flow. Graphs compile to a `Runnable` that can be invoked, batched, or streamed. A compiled graph can also be exposed as a `Tool` for an agent, which bridges deterministic pipelines with autonomous agent behavior.

Agents use components and compositions. The Agent Development Kit (ADK) provides two ready-made agent patterns: `ChatModelAgent` and `DeepAgent`.

## ChatModelAgent and DeepAgent

ChatModelAgent wraps a ChatModel and optional tools into an agent that handles the ReAct loop internally:

```Go
chatModel, _ := openai.NewChatModel(ctx, &openai.ChatModelConfig{
    Model:  "gpt-4o",
    APIKey: os.Getenv("OPENAI_API_KEY"),
})

agent, _ := adk.NewChatModelAgent(ctx, &adk.ChatModelAgentConfig{
    Model: chatModel,
})

runner := adk.NewRunner(ctx, adk.RunnerConfig{Agent: agent})
iter := runner.Query(ctx, "Hello, who are you?")
```

The runner returns an iterator over response events. Adding tools to the agent requires passing a `ToolsConfig` with the tool list; the agent then decides when to call tools and when to respond.

DeepAgent is for multi-step tasks. It breaks problems into steps, delegates to sub-agents, and tracks progress. A DeepAgent can coordinate multiple specialized agents, run shell commands, execute Python code, and perform web searches, depending on what tools and sub-agents are configured:

```Go
deepAgent, _ := deep.New(ctx, &deep.Config{
    ChatModel: chatModel,
    SubAgents: []adk.Agent{researchAgent, codeAgent},
    ToolsConfig: adk.ToolsConfig{
        ToolsNodeConfig: compose.ToolsNodeConfig{
            Tools: []tool.BaseTool{shellTool, pythonTool, webSearchTool},
        },
    },
})
```

## Graph Composition for Deterministic Workflows

When autonomous agent behavior is the wrong model and precise control over execution order matters, the `compose` package provides graph-based workflow orchestration:

```Go
graph := compose.NewGraph[*Input, *Output]()
graph.AddLambdaNode("validate", validateFn)
graph.AddChatModelNode("generate", chatModel)
graph.AddLambdaNode("format", formatFn)

graph.AddEdge(compose.START, "validate")
graph.AddEdge("validate", "generate")
graph.AddEdge("generate", "format")
graph.AddEdge("format", compose.END)

runnable, _ := graph.Compile(ctx)
result, _ := runnable.Invoke(ctx, input)
```

Graphs are typed: the input and output types are specified as type parameters. Nodes are connected by edges, and the graph is compiled before execution. A compiled graph exposed as a tool using `graphtool.NewInvokableGraphTool` can be passed to an agent's tools list, so agents can invoke deterministic pipelines as needed.

This pattern is useful for pipelines like document preprocessing, data validation, or multi-step retrieval where the sequence of operations is fixed but the pipeline should be callable from an agent context.

## Streaming, Callbacks, and Interrupt/Resume

Eino handles streaming automatically throughout the orchestration layer. Components implement the streaming paradigms relevant to them; the framework handles concatenation, boxing, merging, and copying streams as data flows between nodes. This means a component that produces a stream does not need to know whether the next node in the graph expects a stream or a single value.

Callbacks inject cross-cutting concerns without modifying component code. Callback handlers implement fixed lifecycle methods: `OnStart`, `OnEnd`, `OnError`, `OnStartWithStreamInput`, and `OnEndWithStreamOutput`. These attach at the component, graph, or agent level, covering logging, distributed tracing, and metrics without modifying the component implementations themselves.

The interrupt/resume mechanism allows any agent or tool to pause execution and wait for human input. The framework handles state persistence and routing. This is the human-in-the-loop pattern documented in the ADK section of the documentation, and it is relevant for workflows where automatic execution should pause for review before continuing.

The code style requirements for contributors are enforced through golangci-lint:

```bash
golangci-lint run ./...
```

Enforced rules include GoDoc comments on all exported symbols, `gofmt -s` formatting, and `goimports` ordering (standard library imports first, then third-party, then local). Teams extending Eino with custom components need to follow these conventions to pass CI.

## Eino Against LangChain

LangChain is a Python framework for LLM application development with a large ecosystem of integrations, chains, agents, and tools. Its Go port (langchaingo) exists but has a smaller set of integrations than the Python version.

Eino's difference is that it is built from the start in Go, following Go idioms. LangChain's Python version has more component integrations documented in its ecosystem than EinoExt. Teams that need a specific provider integration that EinoExt does not yet include would need to implement the component interface themselves or wait for a contributed implementation.

Eino requires Go 1.18 or later. The stable release series is 0.9.x (current: 0.9.21). A 0.10.0 alpha series is available for testing. The Apache-2.0 license permits use in commercial products without copyleft obligations.

## Conclusion

Eino is a strong choice for Go teams building LLM-powered applications who want typed component abstractions, deterministic workflow graphs, and a clear separation between agent behavior and tool definitions, without adopting a Python-first framework. Teams working primarily in Python will find LangChain's ecosystem and documentation broader. Before adopting Eino in production, note that the stable release series is 0.9.x while 0.10.0 is in alpha, and confirm which component implementations you need are available in eino-ext.

## FAQ

### What is Eino?

Eino is a Go framework for building LLM applications and agents, maintained by CloudWeGo. It provides typed component abstractions (ChatModel, Tool, Retriever), graph-based workflow composition, and an Agent Development Kit with ChatModelAgent and DeepAgent. It supports providers including OpenAI, Claude, Gemini, and Ollama.

### How does Eino compare to LangChain for Go projects?

Eino is built natively in Go with Go conventions, while LangChain's primary version is Python. Eino's EinoExt provides implementations for OpenAI, Claude, Gemini, Ark, Ollama, and Elasticsearch. LangChain's Python ecosystem is broader in total integrations, while Eino provides a more idiomatic Go experience without wrapping a Python library.

### What LLM providers does Eino support?

According to the README, official component implementations in EinoExt cover OpenAI, Claude, Gemini, Ark, Ollama, and Elasticsearch. Additional providers can be added by implementing the relevant component interface (ChatModel, Retriever, etc.) from the Eino core module.

## Sources

- [cloudwego/eino on GitHub](https://github.com/cloudwego/eino)
- [License: Apache-2.0](https://github.com/cloudwego/eino/blob/main/LICENSE)
- [Project website](https://www.cloudwego.io/docs/eino/)
- [README](https://github.com/cloudwego/eino/blob/main/README.md)
- [Releases](https://github.com/cloudwego/eino/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cloudwego-eino