Core documentation
Build and review software through a graph¶
Zeroshot enforces your team's QA process on coding agents. You define it as a graph of implementation, review, test, repair, and delivery steps; its authored transitions decide which node runs next, so no agent skips a step.
Run a first task Read the CLI reference
Open the workspace UI to design profiles, watch live runs, and replay recorded history.
What a run contains¶
Three authored values determine execution:
- a graph that defines control flow and typed state;
- a runtime plan that binds each executable node to a harness, provider, model, and named connections;
- an initial input that belongs to the caller and that Zeroshot checks against the graph before execution.
After validating those values, Zeroshot opens a durable ledger where it records each node result. Authored edges then route review, retries, and the final result.
The built-in software-change template uses the route shown above. For work that does not need its
review loop, use single-worker. For research, use auto-research. It runs ten rounds of experiments
by default, and a new result replaces the current one only when the progress judge accepts it. Custom
graphs follow the same protocol contracts.
Choose where it runs¶
-
Local
Local mode works in any folder (
--cwd FOLDER), keeps state on the same machine, and calls your chosen harness. Git is optional without delivery. -
Self-hosted target
The target image checks out source on infrastructure you control. Agent processes and the run ledger stay there as well.
-
Zeroshot Platform
Platform accepts the same graph and runtime plan through a managed target. Its documentation covers accounts, organization policy, and queue behavior.
Where code is processed¶
The execution target and model provider are separate choices. Local and self-hosted runs keep the checkout and run ledger on your infrastructure, but a harness using an external model provider sends that provider the code and context it needs. Self-hosting zeroshot does not make model processing local. Check the selected provider's data-handling terms before using client code.
For Platform-hosted execution, see the Platform privacy notice for data locations and retention. Runtime connections describe how to select providers and supply credentials.
Read more¶
How execution works describes the graph and reduction model. Read Runtimes and connections before choosing models or supplying credentials; Observe and control runs covers failed-run recovery, durable status, and log streams. Use a local graph as an ACP agent covers the experimental stdio endpoint. Build a review loop builds a custom graph and runtime plan step by step.
These reference pages are generated from product-owned definitions:
- CLI reference, generated from the Clap command tree;
- Python API, generated from the SDK's public objects and docstrings;
- Cluster API, generated from the checked-in OpenRPC contract and protocol schemas.
Current follows main and may describe unreleased changes. For an installed release, choose its
minor version from the header; each minor documents its newest published patch.
Documentation versions defines the URL and manifest contract.