Weave: A Go Microkernel Platform with an AI Stack Bolted Into the Plugin Model

The problem Weave targets: one plugin interface for tools, services and AI features

Most Go teams that add LLM features end up with two codebases: the service platform they already run, and a separate AI layer glued on with its own config, its own HTTP handlers and its own deployment story. Weave's pitch is that this split is unnecessary. The README describes a platform where LLM, AIChat, Agent, RAG and MCP are not a sidecar but plugin capabilities sitting next to ordinary tools and services, all behind the same Plugin interface. The stated scenarios are tool and application aggregation, a data and service flow middle platform, API gateway and service orchestration, AI application development, and automated workflows combining ETL, DevOps and Agent. That list is broad, and breadth is the first thing to be sceptical about. But the underlying idea is narrow enough to evaluate: one kernel, one plugin contract, many capabilities. If you are building an internal platform in Go and you want AI features to be plugins rather than a second stack, Weave is aimed at you. If you only need a chat endpoint, the platform around it is overhead.

Microkernel plus layers: what the architecture actually separates

Weave combines two patterns. The microkernel side provides plugin management, lifecycle control and inter-plugin communication. The layered side organises the core system into four tiers: an interface layer handling HTTP requests, routing and controllers; a business layer holding core logic and the plugin system; a data layer for storage and access; and an infrastructure layer for logging, configuration and security. The kernel itself supplies the runtime environment, plugin management, configuration management, logging and security mechanisms. Plugins attach through interfaces and are meant to be isolated: each gets its own namespace and route prefix. The README also claims dependency resolution and conflict detection so plugins can coexist, and a hot-plug capability where plugins load and unload at runtime without restarting the system. That last claim is the one to test first. Runtime plugin loading in Go is constrained by the language's static linking model, and the README does not explain the mechanism. It may be implemented through a registry of compiled-in plugins toggled at runtime, which is a reasonable design but not the same as loading new code. The documentation does not say which, and the distinction changes how you plan deployments.

The AI capabilities and what the README does not specify

The AI stack is listed as LLM, AIChat, Agent, RAG and MCP, with topics on the repository confirming eino, large language models and MCP. Eino is a Go LLM framework, which suggests the LLM and Agent layers build on it rather than on a bespoke abstraction. The README does not name a default model provider, a vector store for RAG, an embedding model, or how MCP servers are registered. Those are the decisions that determine whether a RAG plugin is usable in your environment, and none of them are answered in the material available. Treat the AI features as a framework with defined extension points rather than a turnkey pipeline. That is a defensible choice for a platform, since it avoids locking you to one provider, but it means the integration work is yours. If your evaluation depends on a specific vector database or a specific model vendor, you will need to read the plugin implementations in the repository before you can judge fit.

Getting it running: what the README gives you and what it does not

This is where the material runs out. The README states the Go version requirement as 1.24 or later, shown as a badge, and the repository topics include docker and k8s, which implies container and Kubernetes deployment are intended. There is no install command, no configuration file example, no environment variable list, no make target, and no docker run or kubectl invocation in the README text provided. There are no retrieved releases either, so there is no versioned artefact to pin. The homepage field points to a separate organisation, NexusForgeAI/Weave-Toolkit, which may hold related tooling, but nothing in the supplied material confirms what it contains. Practically, the first step is to clone the repository and read the source for the entry point and config loading, since the infrastructure layer is described as handling configuration but the keys are not documented. Do not plan a deployment timeline around this README alone.

The licence gap is the first thing to resolve

The licence is listed as unknown, and no licence file is referenced in the material. For a platform you would embed in internal services or ship alongside proprietary code, that is a blocking unknown rather than a detail. Without a licence you have no stated grant of rights, and the repository description's emphasis on security and stability does not substitute for one. This is not a legal judgement, and it is not a reason to assume the project is unusable. It is a reason to check the repository root for a LICENSE file and, if none exists, to contact the maintainers before writing code that depends on Weave. The same applies to any transitive dependency the plugin system pulls in, particularly around the AI stack, where provider SDKs often carry their own terms.

Where Weave is the wrong tool, and what to use instead

Weave is the wrong tool when the platform is the problem rather than the solution. If you need a retrieval pipeline and nothing else, a focused Go RAG library will get you there with less surface area: no kernel, no plugin lifecycle, no route prefix conventions, no conflict detection to reason about. LangChainGo is the obvious comparison point, and the difference in approach is structural. LangChainGo is a library you call from your own application; you own the process, the HTTP layer and the deployment. Weave inverts that: it owns the process and you extend it through plugins. The library approach gives you freedom and leaves you to build the aggregation, routing and lifecycle management yourself. The platform approach gives you those things and asks you to accept its kernel, its interface layer and its conventions. Neither is better in the abstract. The question is whether you are building a platform or a feature.

Maintenance and upgrade cost

The material supports only a limited read here. The repository is not archived, and the last push is dated 2026-07-15, so the project appears active at the time of writing. There are no retrieved releases, which means no changelog, no semantic versioning signal and no upgrade path documented. For a platform that plugins depend on, that matters: a change to the Plugin interface or the kernel's configuration handling ripples through every plugin. The README's claim of a stable core and a unified interface is the design intent that would contain that cost, but intent is not a compatibility guarantee. If you adopt Weave, pin to a commit rather than a branch, and read the diff before moving that pin. The Go 1.24 or later requirement also sets a floor on your toolchain, which is a real constraint if your organisation lags on Go versions. On licensing, the unknown status is the open item: resolve it before the codebase depends on it.

Editorial conclusion

Weave is worth a look if you are building a Go service platform where AI capabilities (LLM, AIChat, RAG, Agent) sit alongside ordinary tools and services behind one plugin interface, and where you are willing to work from the repository rather than a written quickstart. It is the wrong choice if you need a documented setup path today, a stated licence before you commit code, or a pure RAG pipeline without the surrounding platform. Before adopting, verify the licence file, the Go 1.24+ toolchain requirement, the actual plugin interface in the source, and whether the hot-plug claim in the README is implemented at runtime or only described.

Official sources

1. Issues
2. liaotxcn/Weave on GitHub
3. Project website
4. README