AWF packages multi-provider AI orchestration into an open-source stack built around three binaries. Its Go CLI runs YAML-defined workflows across OpenAI, Anthropic’s Claude, Google’s Gemini and Ollama, with documented support for parallel steps, retries, resumable runs, token tracking and workflow diagram exports. Two companion tools add logical reasoning and scheduled execution. AWF’s project site describes the components as independently usable and designed to work together.
The project already has a release history. Its CLI blog dates “AWF Is Live” to March 21, 2026, and lists an April 5 release of v0.6.0 introducing workflow packs. Those records establish an earlier public launch; the opened pages do not confirm an October 29 announcement.
The useful question for developers is how much operational control the stack provides. AWF separates workflow execution, logical reasoning and timing into distinct tools. That design makes it possible to adopt the runner without immediately committing to a new knowledge store or scheduler.
Three Binaries With Separate Jobs
AWF’s architecture assigns each component a different responsibility:
| Component | Implementation | Documented role |
|---|---|---|
| AWF CLI | Go | Run YAML workflows, coordinate providers and record execution history |
| ZPM | Zig with an embedded Trealla Prolog engine | Store facts and rules, answer queries and expose proof-oriented reasoning through MCP |
| ztick | Zig | Accept scheduled jobs and dispatch them to shells, webhooks, messaging systems or AWF workflows |
The separation matters operationally. A workflow can start as a terminal command, later gain a scheduled trigger, and use ZPM when a task needs explicit rules and deductions.
I’d start with the CLI unless an application already has a clear need for the other two components. Retries, run identifiers and readable workflow definitions solve immediate integration problems. Adding a reasoning database makes sense when there are actual facts and rules to maintain.
Install the CLI and Define a Workflow
The CLI documentation publishes a shell installer and a Go installation command:
curl -fsSL https://raw.githubusercontent.com/awf-project/cli/main/scripts/install.sh | sh
go install github.com/awf-project/cli/cmd/awf@latest
The shell command downloads and executes the project’s installation script. The Go command builds and installs the CLI through an existing Go toolchain. Neither command has been executed for this article.
For a development machine, either documented route is straightforward. For CI, I’d use a reviewed, fixed release instead of allowing @latest to change the installed version between builds. Reviewing a downloaded script before running it is also a sensible precaution.
AWF describes the CLI as a single static binary with no runtime dependencies. That describes the runner itself: hosted model access still requires connectivity and authentication, while an Ollama-backed step needs its chosen local backend available.
Workflows use a state-machine structure. This minimal illustration follows the schema shown in the CLI documentation:
name: audit-summary
states:
generate:
type: step
agent:
provider: claude
prompt: "Explain why workflow audit logs matter."
on_success: done
done:
type: terminal
status: success
The generate state invokes Claude. If it succeeds, on_success moves execution to done, which records a successful terminal state. The documented run-command pattern gives this example:
awf run audit-summary
Provider authentication and model configuration remain separate setup requirements. The documentation also demonstrates typed inputs and passing values with --input, allowing a workflow definition to stay fixed while its task data changes.
One documentation detail deserves attention: the homepage’s code-review example uses a top-level type: agent, while the CLI quick start places agent inside type: step. The illustration above follows the CLI quick start. Before building a larger pipeline, check the schema accepted by the installed release.
Provider Choice Without Rebuilding the Pipeline
AWF lists OpenAI, Claude, Gemini and Ollama as supported backends. Its pitch is that changing a provider can be a one-line YAML edit.
The practical benefit is a stable orchestration layer. Input handling, transitions, retry policies and execution records can stay in the workflow definition while the model backend changes. That can reduce the work needed to move an internal tool between a hosted API and a local model.
Provider interchangeability still needs testing. Models can differ in instruction following, output structure and available capabilities. A provider field abstracts how a step is invoked; it cannot guarantee equivalent answers. I’d treat a backend change as a workflow revision that needs output checks, especially when later steps consume generated text.
AWF also advertises token tracking per step, workflow and run. That gives developers a useful way to locate an expensive loop or unexpectedly large prompt. Token counts are not automatically a comparable dollar total across providers: translating usage into spend requires the applicable pricing and billing rules.
Recovery and Auditability Are the CLI’s Strongest Hooks
The project documents several controls around execution:
- Retries: exponential, linear or constant backoff configured per step.
- Resume: continue a run from a failed step using its run identifier.
- Parallel execution: coordinate concurrent steps with
all,anyorracestrategies. - Composition: call another workflow with typed input/output mapping.
- Diagrams: export the workflow state machine as Graphviz DOT with
awf diagram.
The CLI documentation also describes structured JSONL audit logging, secret masking and atomic writes. JSONL stores individual JSON records on separate lines, making execution history suitable for line-oriented processing and log ingestion.
Explicit states make recovery understandable: the runner has named steps and transitions to track, instead of an opaque sequence hidden inside one large prompt. Diagram exports can make that structure easier to review alongside the YAML.
Resume still requires care around external effects. If a step sends a notification or changes another system, restarting that step could repeat the action unless the integration prevents duplicates. A recorded workflow position alone cannot resolve every ambiguity after a network failure.
AWF also claims deterministic replay and production readiness. The sources here are project documentation, with no independent tests establishing those claims. The published material does not explain enough about replay semantics to conclude that fresh model calls will produce identical text. Workflow traceability and repeatable model output are separate properties.
ZPM Adds Proof-Oriented Memory, Not Guaranteed Truth
Frequently Asked Questions
4 questions
1Which AI providers does AWF support?
AWF lists OpenAI, Anthropic’s Claude, Google’s Gemini and Ollama. Switching backends can preserve the workflow structure, but outputs still need validation.
