# FlowCraft: a Go SDK for AI agents with memory, retrieval and voice > FlowCraft is a modular Go workspace for building AI agents without tying application code to one model provider. The core is contracts; provider adapters and memory implementations plug in from outside, and the forge demo shows the whole stack running locally. **GizClaw/flowcraft** — Production-grade Go SDK for building AI agents with long-term memory, knowledge retrieval, and voice — runnable as a library, a daemon, or a real-time pipeline. - Repository: https://github.com/GizClaw/flowcraft - Website: https://gizclaw.github.io/flowcraft/ - Stars: 416 · Forks: 9 - Language: Go - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/gizclaw-flowcraft ## The problem FlowCraft targets: provider lock-in in agent code Most agent codebases start by importing a vendor SDK and end up with the vendor's types threaded through business logic. FlowCraft's README frames the goal as building and evaluating AI applications "without tying application code to one model provider or execution model." That second clause matters more than the first. Graphs are described as one built-in option rather than a required architecture, so a team that only wants tool calling and a message loop can use the core packages directly instead of adopting a graph DSL. The intended audience is Go engineers building production services, not notebook users. The module map lists provider adapters for Anthropic, Azure, ByteDance, DeepSeek, Kimi, MiniMax, OpenAI and Qwen, each distributed as its own versioned Go module. A service that only needs OpenAI can depend on core plus that one driver. The cost of this design is assembly: you are expected to wire deploy, runtime and session yourself, and the README points at docs/guides/deploy.md and docs/guides/runtime.md for the contracts rather than walking through a full application. ## How the layering rule shapes the architecture The README states the layering rule explicitly: execution contracts live in core/agent (agent.Engine, agent.Host, agent.Board) and stay leaves of the core, meaning the agent package does not import graph or tool packages. core/graph builds on those contracts and returns an agent.Engine. Memory contracts live in core as well, while app-registered implementations and adapters stay outside and depend on the core, never the reverse. That inversion is the whole design. core/memory defines the capability contracts (ContextProvider, TurnSink, DocumentSink, ContextRenderer, Scope, Turn) plus generic glue: a memory.Assembly deploy resource that dispatches to implementations by an impl: name, the memory.context and memory.turn agent-lifecycle hooks, and a GoTemplate context renderer. The README says the flowcraft memory module is one such app-registered implementation, which is a useful honesty signal: the project does not claim its own memory backend is the only one, or even that it is inside the core. The same pattern governs inference. core/inference is generic, and each provider is a registered factory. So there are two extension points with identical mechanics, one for models and one for memory. If you have used a plugin registry before, this will feel familiar; if you have not, the indirection costs you a reading pass through the deploy guide before anything compiles. ## Installing FlowCraft and running the forge workspace demo The README does not give a go get line for a single package. It points at the forge demo in examples/forge as the fastest way to explore the stack, and the demo is a Go program you run from its own directory. The badge in the README states Go 1.26 or later. Start by cloning the repository, then run the demo's own help command from examples/forge: ```bash cd examples/forge go run . help ``` The README gives this example, so the help output is the authoritative command reference. Next, build a workspace from the werewolf scenario and run one scripted test: ```bash cd examples/forge go run . workspace create --config werewolf --workspace ./workspace go run . test -test werewolf/opening_setup ``` According to the README, the demo builds workspaces from native deploy, inference and memory scenario documents, opens an interactive TUI, and runs scripted tests plus raid by persona simulations. Command reference, scenario layout and credentials live in examples/forge/README.md, with a Chinese version at examples/forge/README_zh.md. Credentials are not documented in the top-level README, so treat the forge README as the place to look before the demo will talk to any provider. For embedding, the README shows assembling a deployment from deploy.yaml with core/deploy, running it with core/runtime, and driving turns through core/runtime/session. The snippet parses a deploy document, builds an app, opens a session lease keyed by AgentID and ContextID, starts a turn with a user message and a sink, then waits on the result. Note the shape: sessions are leases, turns are waited on, and output goes to a named sink rather than a return value. ## Where FlowCraft is the wrong tool The README is silent on several things a production adopter will ask about. There is no documented rollback or migration path for stored state, even though backends/checkpoint provides SQLite checkpoints. If your agent runs are long and resumable, you are trusting a checkpoint format whose evolution is not described. The recent releases list is empty, so there is no changelog entry to read for upgrade behaviour; CHANGELOG.md and CHANGELOG.legacy.md exist in the repository root, which suggests history is kept, but the README does not show what is in them. The distribution model is also a real constraint. Layers are independently versioned Go modules and applications adopt only the layers they need, which means you manage a multi-module dependency graph. The Makefile works around this with a GO_FOREACH macro over modules listed in go.work, and its comments record a past bug where a subshell swallowed errors and make reported a failing loop as green. That is a maintenance detail, but it tells you the workspace has enough moving parts that the build tooling needed its own corrections. Finally, voice appears in the project description and the topics list, but the README sections reproduced here describe memory, inference, deploy and runtime. If voice is your primary reason for looking, verify it exists in the code before you plan around it. ## FlowCraft compared with graph-first agent frameworks The closest comparison is a graph-first framework such as LangGraph, where the graph is the application and nodes are the unit of composition. FlowCraft inverts that: core/graph compiles declarative graphs into agent.Engine implementations, so a graph is one way to produce an engine rather than the thing your service is written against. If you want to swap a graph for a hand-written loop without rewriting callers, that inversion is the point. If you want the framework to own control flow and give you a visual trace of node transitions, it is friction. The second comparison is a provider SDK used directly, for example the Anthropic or OpenAI Go clients. Those give you typed access to one vendor and no abstraction tax. FlowCraft's driver modules sit on top of core and register as factories, so switching providers is a configuration change rather than a code change, at the cost of learning the deploy and session contracts first. The README's own framing is that memory implementations plug in the same way inference providers do, which is a coherent story only if you accept the registry indirection in both places. A third option is a Python or TypeScript agent framework. FlowCraft is Go, and the README does not present bindings for other languages. If your team is not a Go team, the provider-agnostic design will not compensate for the language mismatch. ## Maintenance, licensing and upgrade cost The repository is not archived and the last push was on 2026-09-10, ten days before this writing, so the project is being worked on now. That is a statement about commit activity, not about release cadence: no recent releases were retrieved, so there is no tagged version to pin against from the information available. Upgrade cost is structural rather than incidental. Because layers are independently versioned modules, an upgrade can touch core, one or more driver modules and backends/checkpoint separately. The Makefile exposes the machinery for this: make tidy runs go mod tidy across all modules, make ci runs vet plus test, and make release-check tests release tooling, validates changesets and verifies the pending module release plan. tools/releasegate handles changeset validation, release planning and changelog aggregation. If you vendor FlowCraft, budget for running those targets yourself rather than assuming a single version bump. The licence is MIT, which permits commercial use and modification with the copyright notice retained. That is a permissive choice with no copyleft obligation on your application code. This is a description of the licence identifier in the README, not legal advice; if you redistribute modified modules, read the LICENSE file in the repository root. ## Conclusion Adopt FlowCraft if you are writing Go services that need provider-agnostic agents and you are willing to assemble a deployment from deploy.yaml yourself. Do not adopt it if you want a batteries-included Python or TypeScript agent framework, or if you need a documented rollback story for stored checkpoints, which the README does not cover. Before committing, run the forge demo, then read docs/guides/deploy.md and docs/guides/runtime.md and confirm the session contract matches how your service opens long-lived conversations. ## FAQ ### What is FlowCraft? FlowCraft is a Go workspace for building AI applications with long-term memory, provider backends and local interactive workflows. Its core module defines agent execution, graph, tool, model, message, inference, memory, event, telemetry, deploy and runtime contracts, while provider adapters and memory implementations live outside the core as separately versioned modules. ### How do I install FlowCraft and try it for the first time? The README does not give a single install command. It points at the runnable demo in examples/forge, where you run go run . help, then create a workspace from the werewolf scenario and run a scripted test. Command reference and credentials live in examples/forge/README.md. ### Does FlowCraft lock me into one model provider? No. The README states the goal is building AI applications without tying application code to one model provider, and the driver modules cover Anthropic, Azure, ByteDance, DeepSeek, Kimi, MiniMax, OpenAI and Qwen. Each provider is a registered factory built on core, so switching is a configuration change rather than a rewrite of application code. ### How does FlowCraft handle long-term memory? core/memory defines the contracts (ContextProvider, TurnSink, DocumentSink, ContextRenderer, Scope, Turn) plus generic glue: a memory.Assembly deploy resource that dispatches by impl: name, the memory.context and memory.turn lifecycle hooks, and a GoTemplate context renderer. Memory implementations register under their own impl: name, and the README says the flowcraft memory module is one such app-registered implementation. ### Is FlowCraft the same as other products named Flowcraft? No. This FlowCraft is the Go SDK from the GizClaw/flowcraft repository. Search results for the name also return unrelated products, including a slingshot, a foil board, mountain bikes and a studio, and none of those are this project. ## Sources - [GizClaw/flowcraft on GitHub](https://github.com/GizClaw/flowcraft) - [Issues](https://github.com/GizClaw/flowcraft/issues) - [License: MIT](https://github.com/GizClaw/flowcraft/blob/main/LICENSE) - [Project website](https://gizclaw.github.io/flowcraft/) - [README](https://github.com/GizClaw/flowcraft/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gizclaw-flowcraft