go-kratos/blades: a Go agent framework built around one Run method
Blades is a Go-based multimodal AI Agent framework.
At a glance
- What is it?
- Blades is an MIT-licensed Go framework for multimodal AI agents, with Agent, ModelProvider, Tool, Memory and Middleware as the named components. The README describes the design intent clearly and the interfaces are visible in the code samples, but the material supplied here stops before installation, configuration and failure behaviour, so several adoption questions stay open.
- Who is it for?
- Adopt blades if your team writes Go, already structures services around interfaces and middleware, and wants agents to be one more such component rather than a separate runtime. Do not adopt it if you need a documented install and configuration path today, or if your agents depend on a memory backend the project already maintains.
- Can I use it commercially?
- Yes. MIT 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 33 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 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What blades is trying to solve for Go teams
Most agent frameworks arrive as Python libraries or as hosted services with an HTTP surface. A Go service that wants an agent inside it therefore has two options: run a second process and talk to it over the network, or write the tool-calling loop by hand against a vendor SDK. Blades is aimed at the second option. The README states that it is a multimodal AI Agent framework for Go, and that it supports custom models, tools, memory and middleware, with multi-turn conversations, chain-of-thought reasoning and structured output given as the intended uses. The audience is Go developers who want the agent to be a library inside an existing binary rather than a separate deployment. The project's own framing is explicit about this: the first bullet under Architecture Design says it is built according to Go's philosophy, with a code style and user experience familiar to Go developers. The name comes from God of War, which tells you something about the tone of the project but nothing about its behaviour.
One interface, several kinds of component
The design decision that shapes everything else is that Agent is an interface with a single execution method. The README gives it as Name, Description and Run, where Run takes a context and an Invocation and returns a Generator of Message values with an error. The documentation states that Agent, Chain and ModelProvider all implement this interface, which is what lets them be composed. That is the mechanism: a Chain is not a special construct with its own execution model, it is something that satisfies the same contract as a leaf agent, so nesting a chain inside a chain is a type-level question rather than a framework-level one. The Generator return type is the second half of the design. Run returns a generator rather than a slice, so streaming is the default shape of execution and a caller that wants a complete result has to drain it. The README does not spell out how errors surface partway through a generator, which is the kind of detail that decides whether a long tool-calling run is debuggable.
ModelProvider splits generation into two paths
ModelProvider is the adapter between the framework's internal request format and a vendor API. The README shows it with two methods. Generate takes a context, a ModelRequest and variadic ModelOptions, and returns a ModelResponse and an error, described as executing a complete request and returning the result all at once, for cases that do not need real-time feedback. NewStreaming takes the same arguments and immediately returns a Generator of ModelResponse, described as suited to typewriter-effect conversation. Keeping both on one interface rather than making streaming a wrapper around a blocking call means an implementer has to support both, and the documentation lists OpenAI, DeepSeek and Gemini as examples of what the abstraction is meant to cover. The README does not enumerate which providers ship in the repository, so the number of ready-made implementations is something to check in the source tree rather than assume from the prose.
Tools, memory and middleware as separate seams
Three components sit around the agent rather than inside it. Tool represents an external function or service, with an InputSchema that the README says guides the LLM to produce correct invocation parameters and a Handle function that executes the logic. Putting the schema in the tool rather than in a central registry means adding a capability is a local change. Memory is described as a universal interface for storing and retrieving conversation data, giving short-term or long-term context, and the README's text is cut off mid-sentence at exactly the point where it would describe retrieval semantics. That is the thinnest part of the supplied material. Middleware is the component with the clearest lineage: the README says it draws on Kratos's middleware design and names observability and guardrails as things that can be attached to an agent. For anyone who has used Kratos, the shape of this will be familiar, and the claim that cross-cutting concerns belong in middleware rather than in the agent is a reasonable one. Whether guardrails as middleware can actually block a tool call before it executes, or only observe it afterwards, is not answered here.
Getting it running is not described in this material
The README shows interfaces, not usage. There is no go get line, no constructor call, no configuration example, and no sample of wiring a ModelProvider into an Agent with options. The text says the top-level agent integrates ModelProvider, Tool, Memory and Middleware and that it is configured through Option functions, but the option names themselves do not appear. The homepage at go-kratos.dev/blades is referenced in the repository metadata and is the obvious place to look for a quickstart, and the package has a pkg.go.dev badge, so the exported API is browsable there. The repository also carries a DeepWiki badge, which suggests generated documentation exists. None of that substitutes for a worked example, and an adopter should treat the first hour as reading source rather than following a guide. This is the single largest gap between what the README promises and what it hands you.
Where the abstraction costs you
The Generator return type is the design choice most likely to bite. Any caller that wants a finished Message has to consume the stream and assemble it, and the README does not describe what happens when the underlying model call fails after partial output. A framework that returns a slice can hand you an error and nothing else; one that returns a generator has to decide whether a mid-stream failure is an error value, a terminal message, or both. Blades documents neither. The second cost is the ModelProvider contract itself. Because Generate and NewStreaming are both required, a provider that only offers one of the two has to fake the other, and the quality of that emulation is the implementer's problem. The third is version velocity. Releases moved from v0.3.1 in December 2025 to v0.4.0 in March 2026 to v0.5.0 in April 2026, which is a fast cadence for a framework whose central interface is a single method. A pre-1.0 project at that pace can change the Agent contract between minor versions, and the release notes are the only place that would say so.
How this differs from LangChainGo and similar ports
The closest comparison in Go is LangChainGo, which follows the Python LangChain decomposition into chains, prompts, memory classes, document loaders and retrievers, and exposes a large surface of named types. Blades takes the opposite route. It defines a small number of interfaces, makes Agent the shared execution contract, and pushes variation into middleware and pluggable providers. The practical difference shows up when you add a capability. In a LangChain-style design you usually reach for an existing class or write one that matches an expected base type; in Blades you implement Agent or Tool and satisfy the interface. That is less to learn and less to reuse. Blades also inherits Kratos's middleware conventions, which is a real advantage if your service already runs Kratos and a neutral fact if it does not. If you want a wide catalogue of pre-built integrations, the larger port has more of them; if you want the agent to look like the rest of your Go code, Blades is the more consistent fit.
Licence, maintenance and what to check before adopting
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement and it does not impose copyleft obligations on your application. It also means no patent grant is included, which is standard for MIT and worth knowing if that matters to your legal review. I am not a lawyer and this is not legal advice; read the LICENSE file in the repository. On maintenance, the material shows a commit as recent as August 2026 and three releases across roughly five months, so the project is active rather than dormant. The cost of upgrading is tied to how much of the framework you touch. If you implement ModelProvider, Tool or Memory yourself, a change to those interfaces is your migration work. If you only consume the top-level agent, upgrades are cheaper. Before adopting, verify four things: which ModelProvider implementations ship in the repository and whether yours is among them, the full Memory interface and where it stores data, whether middleware can reject a tool call or only observe it, and the v0.5.0 release notes for interface changes since v0.4.0.
Editorial conclusion
Adopt blades if your team writes Go, already structures services around interfaces and middleware, and wants agents to be one more such component rather than a separate runtime. Do not adopt it if you need a documented install and configuration path today, or if your agents depend on a memory backend the project already maintains. Before committing, verify the ModelProvider implementations that exist for your target LLM, the concrete Memory interface and its storage semantics, and the v0.5.0 release notes for anything that changes the Agent interface.
Community notes