FlowCraft
Build durable Go AI applications with pluggable memory, multi-provider inference, and streaming sessions.
Per-dimension scores and reasoning
The CI workflow defaults to contents:read, while the documentation describes workspace capabilities, sandbox policy, approval, and pluggable resource boundaries. Dependency checks run a pinned govulncheck version across the matrix, and SECURITY.md defines private reporting and remediation, earning full dependency-security credit. Deductions apply because approval is only referenced through a guide and feature claim, with no implementation shown. Credential instructions are delegated to an omitted example document, and the supplied material shows no secret storage, redaction, or retention policy. Model, tool, filesystem, and network flows are architecturally visible, but per-operation effects and consent points are incomplete. Checkpoints support pause/resume, although persistence is host-provided and cannot establish rollback of every side effect. MIT ownership and repository attribution are clear, but publisher identity remains unverified.
Module boundaries, build commands, and release claims in the README align with the CI matrix, race tests, cross-platform jobs, and sandbox integration jobs, justifying full self-consistency credit. Multiple model adapters and modular backends are identified, but the evidence does not describe third-party outage handling, fallback, or retry behavior; Go 1.26+ and external tools are also deployment prerequisites. Workflow failures include useful diagnostics, but no runtime error taxonomy, actionable user diagnostics, or representative failure messages are supplied, so failure handling is not thorough.
The material addresses library embedding, a local TUI, scripted tests, simulations, deployment runtimes, memory, and several inference providers, with English and Chinese example entry points. Boundaries are explicit: Realtime is reserved, checkpoint persistence belongs to the host, memory implementations are application-registered, and sandbox policy is distinct from workspace state. Scenario files demonstrate intended /start behavior, scope-drift rejection, and nonlethal resolution, but they contain turns rather than assertions and do not establish general trigger-routing precision. Linux bwrap, stated macOS seatbelt support, and dedicated Windows build/integration jobs provide strong environment-fit evidence.
The README provides a coherent module map, architecture, guide index, quickstart, and source-build instructions, while the complete MIT text is present. Pre-1.0 status, reserved Realtime support, host persistence responsibility, and the policy of not patching old minor releases are disclosed. SemVer, immutable changesets, changelog aggregation, and atomic tag publication are documented and enforced by workflows. Deductions apply because pre-1.0 modules permit breaking minor releases, so naming/API stability is not mature; examples are substantial but no actual FAQ is supplied. Reporting channels, response targets, and automation clarify maintenance paths, yet no individual maintainers or governance structure are identified.
The embeddable API, deployment YAML, streaming sessions, resumable execution, pluggable memory, and multi-provider adapters constitute usable outputs and offer substantial value over assembling those layers independently. The supplied evidence contains no representative agent output, benchmark, resource profile, latency data, cost controls, or scale measurements. Output usability and cost-benefit therefore merit ordinary-use credit but not full marks based on the “production-grade” description alone.
Many claims name concrete packages, guides, examples, CI jobs, and release tooling. The README, security policy, license, workflows, and scenario files strongly corroborate the repository's structure and its test, security, and release processes. Deductions apply because the referenced guides, implementation code, go.mod files, changelog, and test assertions are absent, preventing direct tracing of every runtime and safety claim. Broad wording such as “production-grade” is also not cleanly separated from the disclosed pre-1.0 status or backed by quantitative evidence.
- This assessment is limited to the supplied static excerpts. No build, test, vulnerability scan, or example was executed, and referenced implementation files and guides were not inspected.
- The project is explicitly pre-1.0 and permits breaking changes in minor releases. Pin every Go module and review coordinated upgrade requirements before adoption.
- Before using real credentials, long-term memory, or tool execution, verify secret storage and redaction, retention rules, default network policy, approval coverage, and idempotency or compensation for external side effects.
- Checkpoint contracts establish resumable execution with host-provided persistence; they should not be treated as transactional rollback for model calls, tool operations, or filesystem changes.
- The release workflow has actions, contents, and pull-request write permissions. Although scoped to release automation, branch protection, environment approvals, and token restrictions should be verified.
What does this agent do, and when should you use it?
FlowCraft is a modular Go workspace for building and evaluating AI applications without committing application code to one model provider or execution architecture. Its core module defines agent execution, declarative graphs, tools, messages, inference, memory contracts, events, telemetry, sandboxing, deployment assembly, runtimes, sessions, and delegation. Separate driver modules integrate OpenAI, Anthropic, ByteDance, and MiniMax, while backends/checkpoint supplies SQLite checkpoint support. Applications can embed the Go packages directly or assemble a deployment document into an interruptible, streaming session runtime. The repository also includes the runnable examples/forge workspace with an interactive TUI, scripted tests, and raid × persona simulations.
An application parses a deployment document with core/deploy and uses a runtime builder to assemble shared resources, named agents, execution engines, and lifecycle hooks. It opens a session through core/runtime/session using an AgentID and ContextID, submits a message.Message inside agent.Request, streams events through a SinkSpec, and waits for the final result. core/graph compiles declarative DAGs into agent.Engine implementations, while core/agent supplies primitives such as Engine, Host, Board, Run, Interrupt, and Checkpoint. During a run, core/memory uses the memory.context and memory.turn hooks to obtain context and dispatch turns or documents to application-registered implementations through contracts including ContextProvider, TurnSink, and DocumentSink. core/inference routes Generate, Embed, and Transcription operations to OpenAI, Anthropic, ByteDance, MiniMax, or compatible wire-family endpoints; the tool subsystem adds Registry, Catalog, Executor, middleware, and an MCP bridge.
- A Go backend team embedding an assistant that needs streamed output, leased sessions, and interruptible execution.
- A platform team configuring OpenAI, Anthropic, ByteDance, MiniMax, or compatible endpoints without coupling business logic directly to one provider SDK.
- Developers building durable jobs that save execution state through a CheckpointStore and resume work after a process restart.
- An application team connecting its own long-term-memory service through context retrieval, turn storage, and document storage contracts.
- Go engineers modeling agent workflows as declarative DAGs with parallel branches and custom node types.
- A development or QA team evaluating scenarios locally through the forge TUI, scripted tests, per-turn metrics, and raid × persona simulations.
What are this agent's strengths and limitations?
- Execution contracts are separated from provider adapters, so OpenAI, Anthropic, ByteDance, and MiniMax drivers depend on core rather than becoming core dependencies.
- The execution layer combines structured streaming events, checkpoints, interruption, and resumption with context.Context-compatible waiting semantics.
- Memory integration uses explicit ContextProvider, TurnSink, DocumentSink, ContextRenderer, Scope, and Turn contracts instead of prescribing one storage product.
- One inference runtime covers generation, embeddings, and transcription and can address multiple deployments through exact ModelRef values.
- Teams can embed it as Go modules, exercise it through the forge workspace, and validate deployment assembly offline with stub credentials.
- The core module is still pre-1.0, and its documented versioning policy permits breaking changes in minor releases until v1.0.0.
- A concrete long-term-memory implementation must be registered by the application; core supplies contracts and lifecycle glue rather than a complete memory store.
- Durable checkpoint persistence is host-provided through CheckpointStore, so the core module alone does not deliver a complete persistence setup.
- Realtime inference is reserved rather than implemented in the documented unified runtime; the stated operations are Generate, Embed, and Transcription.
- The independently versioned core, driver, and backend modules introduce coordinated dependency and upgrade work for adopters.
How do you install or deploy this agent?
Go 1.26 or later is required. Clone the workspace and inspect its build targets:
git clone https://github.com/GizClaw/flowcraft
cd flowcraft
make helpRun the repository-wide checks with:
make ciFlowCraft consists of independently versioned Go modules. An embedded application adopts core and adds only the required driver/* or backends/* modules. Remote inference also requires credentials for the selected provider; the supplied material does not state the exact environment-variable names.
How do you use this agent?
The shortest documented first run uses the forge example:
cd examples/forge
go run . help
go run . workspace create --config werewolf --workspace ./workspace
go run . test -test werewolf/opening_setupFor an embedded service, parse deployment YAML with deploy.Parse, build the application with runtimeBuilder.Build, and open a session through app.Sessions().Open. Start a turn with lease.Session().Start, passing an agent.Request containing message.NewTextMessage(message.RoleUser, "hello") and a streaming SinkSpec, then call turn.Wait(ctx) for the result. The deployment filename is arbitrary, although deploy.yaml is the convention. Configuration can be dry-run validated with:
skills/flowcraft-config/scripts/validate-config.sh deploy.yaml
skills/flowcraft-config/scripts/validate-config.sh --type graph graphs/assistant.jsonHow does this agent compare with similar options?
Compared with writing directly against a single provider API, FlowCraft isolates OpenAI, Anthropic, ByteDance, and MiniMax integrations behind drivers and a unified inference runtime with ModelRef addressing. Compared with frameworks that require graph execution, FlowCraft permits direct use of the core packages; core/graph is an optional declarative DAG engine.