Eino Examples: a working catalogue of the Eino framework in Go
Examples and demonstrations for using the Eino framework
At a glance
- What is it?
- cloudwego/eino-examples collects runnable demonstrations of the Eino agent framework in Go, from a hello world agent to ADK orchestration, compose graphs, ReAct and multi-agent flows, and a complete RAG application. It is a reference shelf, not a library, and every example depends on the separate Eino module.
- Who is it for?
- Eino Examples is worth adopting as a pattern catalogue if you are building on Eino in Go and want to see how a supervisor agent, a state graph or a batch node is actually wired, since the examples are grouped by mechanism rather than by product. It is not a starting point if you want a library you can import, because the module holds no reusable API of its own.
- 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 25 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 October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the eino-examples repository actually is
The description calls it a collection of examples and demonstrations for using the Eino framework, and the README frames the purpose as helping developers understand and utilise Eino's features. That is the whole product. There is no library API here to import; the value is in reading working code that exercises one framework mechanism at a time.
The module identity is clear from go.mod, which declares the module as github.com/cloudwego/eino-examples and requires Go 1.24.7. The framework itself is a separate dependency, github.com/cloudwego/eino at v0.9.21, so the two repositories move independently and the examples are pinned against a specific framework release rather than tracking the main branch.
The extension dependencies show what the examples reach for in practice: model providers for Ark, OpenAI, DeepSeek and Ollama, a Volc VikingDB retriever, MCP tooling through the official MCP Go SDK, HTML and PDF document parsers, a Redis client, CozeLoop callbacks, and the ADK local backend. The ADK extension packages, the model components, the tool components and the DevOps helpers all come from the sibling eino-ext repository.
A newcomer therefore reads two things at once: an example directory in this repository, and the framework and extension source it depends on.
The ADK section and what an agent example looks like
The ADK, or Agent Development Kit, section is the largest group in the table of directories, and it is organised as a progression. The entry point is adk/helloworld, described as the simplest agent example showing how to create a basic conversational agent. From there adk/intro walks through ChatModelAgent with an interrupt mechanism, a custom agent implementing the ADK definition, and workflow agents covering loop, parallel and sequential patterns.
The rest of the intro group covers the mechanisms that make agent frameworks awkward in practice. Session management passes data and state across agents. Transfer handles task handoff between agents through the ChatModelAgent transfer capability. Agent summarization adds conversation summarization to long-running ChatModelAgent sessions, which is a specific answer to the context window problem rather than a general feature.
Beyond that, adk/intro/http-sse-service exposes the ADK runner as an HTTP service using Server-Sent Events, which tells you the framework is meant to sit behind a streaming endpoint. adk/agentic covers agentic model examples including a research assistant and a max-output-token retry. adk/agent/ralph-loop implements an autonomous iteration loop with filesystem-backed work state and verification gates, and adk/cancel/graceful-exit shows how to cancel and resume nested agents safely from terminal signals.
Two more groups round it out: adk/middlewares with skill middleware and dynamic tool search examples, and adk/human-in-the-loop with eight examples covering approval, review-edit, feedback loop, follow-up and supervisor patterns. adk/multiagent adds supervisor, plan-execute-replan, deep agents, a project manager and an Excel agent, and adk/common/tool/graphtool shows how to wrap a graph, chain or workflow and expose it as a tool.
Compose and Flow: two orchestration layers in one repository
The compose directory covers what the README calls orchestration, and it holds four examples. compose/chain demonstrates sequential orchestration with compose.Chain, including a prompt plus chat model pairing. compose/graph shows graph orchestration with a state graph, a single tool call, async nodes and interrupt handling. compose/workflow covers field mapping, data-only, control-only, static values and streaming. compose/batch is the BatchNode component, described as having concurrency control and interrupt and resume support.
The flow directory sits beside it with a different set of agent shapes. flow/agent/react is a ReAct agent with memory, dynamic options and an unknown tool handler. flow/agent/multiagent hosts a multi-agent journal assistant and plan-execute patterns. flow/agent/manus is a Manus agent implementation inspired by OpenManus, and flow/agent/deer-go is a Go implementation based on deer-flow, described as supporting research team collaboration.
Having both layers in one repository is a design choice worth noting. Compose is the lower-level orchestration primitive, a chain or a graph of typed components, while the flow and ADK layers build agent behaviour on top. Reading them side by side shows the same mechanisms expressed at two levels of abstraction, which is easier to learn from than two separate documents.
Components, quickstarts and the debugging tools
The components section is the catalogue of individual building blocks. components/model shows A/B test routing and HTTP transport logging with cURL-style output, which is a debugging aid rather than a feature. components/retriever covers a multi-query retriever and a router retriever. components/tool includes JSON Schema tools, MCP tools, and middlewares for error removal and JSON fixing. components/document has a custom parser, an extension parser and a text parser, and components/prompt and components/lambda cover chat prompt templates and lambda function components.
The quickstart group is where a new user should start. quickstart/chat is a basic LLM chat example with a template, generate and streaming. quickstart/todoagent is a simple todo management agent. quickstart/eino_assistant is described as a complete RAG application with knowledge indexing, an agent service and a web UI, which makes it the closest thing in the repository to a full product. quickstart/chatwitheino is an 11-chapter progressive tutorial, running from ChatModel through Runner, Session, Tool, Middleware, Callback, Interrupt, GraphTool, Skill, A2UI and TurnLoop.
The DevOps group handles inspection. devops/debug covers the debugging features for Chain and Graph, and devops/visualize renders a graph, chain or workflow as Mermaid diagrams, which is a quick way to show a colleague the shape of an orchestration you have built.
How to work through the examples, and where the details live
The repository ships no install script and no container image, and the README does not print a command to fetch and run a sample. The examples are a Go module, so the practical route is to fetch the repository, point the module at a framework version that matches the one pinned in go.mod, and run the package you are interested in with the Go toolchain. The directory layout is the map: each example lives in its own package under the section you care about.
The README also points to COOKBOOK.md for detailed documentation of each example, and the documentation itself sits at the cloudwego.io docs site under the Eino section, with the framework at github.com/cloudwego/eino and the extensions at github.com/cloudwego/eino-ext. A Chinese version of the README is provided as README.zh_CN.md.
There is no published release for the examples repository, so the working copy of the main branch is the artefact you use. The commit history, not a version number, is what tells you which framework release an example was written against.
Where the examples are the wrong thing to copy
The first limitation is versioning lag. The examples pin github.com/cloudwego/eino at v0.9.21 and several eino-ext modules at pseudo-versions or beta tags, including a model component at v0.2.0-beta.1. If you are on a different framework release, an example may fail to compile or may quietly use a different API shape, and the fix is usually to read the example against the framework source rather than to trust it as written.
The second limitation is that examples optimise for teaching. The middleware examples for error removal and JSON fixing, and the agentic retry on max output tokens, are defensive patches that make a demo behave. In production you would want to see the failure, not have it swallowed, so copying that layer wholesale can hide real errors.
The third is the dependency footprint. A single example may pull in Redis, Chromedp for browser automation, model SDKs for several providers, and PDF and HTML parsers, so a small idea arrives with a large go.sum. The go.mod also lists internal/ and quickstart/ at the top level, meaning the module is not split into separate published modules per example, so you are copying files rather than depending on a scoped package.
Finally, none of this is a production framework. For serving agents with durability, scheduling and observability you would look at the framework and its extensions directly, and treat this repository as the map to them.
Licence, security reporting and maintenance cadence
The project is licensed under the Apache-2.0 licence, with the text in a LICENSE-APACHE file at the root, and a.licenserc.yaml at the top level suggesting the licence headers are enforced across files. The repository also carries a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a.golangci.yaml for linting and a _typos.toml configuration.
Security handling is spelled out rather than left to the generic process. The README asks that potential security issues in this project be reported to Bytedance Security through the security centre link or the vulnerability reporting email, and asks explicitly that no public GitHub issue be created. That points at the fact that this repository is maintained by ByteDance, the team behind the CloudWeGo project family that includes Eino.
On maintenance, the repository is not archived and its last push was on 2026-09-29. There are no GitHub releases, so the changelog lives in commit history, and the fast-moving framework means that the pinned dependency versions in go.mod are the most useful signal of how current any given example is. The GitHub workflows directory indicates automated handling of builds and checks.
Editorial conclusion
Eino Examples is worth adopting as a pattern catalogue if you are building on Eino in Go and want to see how a supervisor agent, a state graph or a batch node is actually wired, since the examples are grouped by mechanism rather than by product. It is not a starting point if you want a library you can import, because the module holds no reusable API of its own. Check the pinned Eino version in go.mod first, at v0.9.21, since the examples track a fast-moving framework and the cookbook details live in a separate COOKBOOK.md file.
Frequently asked questions
What is the cloudwego/eino-examples repository for?
It collects examples and demonstrations for using the Eino framework in Go, grouped by mechanism, including ADK agents, compose chains and graphs, flow agents, individual components, quickstarts and debugging tools. The README says the goal is to help developers better understand and utilise Eino's features.
Which Eino version do the examples target?
The go.mod pins github.com/cloudwego/eino at v0.9.21 and requires Go 1.24.7. The module is github.com/cloudwego/eino-examples, so the examples are pinned against a specific framework release rather than tracking the framework main branch.
Which example should I start with in eino-examples?
The quickstart group is the intended entry path. quickstart/chat covers a basic LLM chat example with a template, generate and streaming, and quickstart/chatwitheino is an 11-chapter progressive tutorial running from ChatModel to Runner, Session, Tool, Middleware, Callback, Interrupt and GraphTool.
Where is the detailed documentation for each eino example?
The README points to COOKBOOK.md in the repository root for detailed documentation of each example. Longer form documentation is published at the CloudWeGo Eino documentation site, with the framework itself at github.com/cloudwego/eino and extensions at github.com/cloudwego/eino-ext.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/cloudwego-eino-examples)Was this useful?