Statewright adds state-machine guardrails for AI coding agents

Statewright is a system for constraining AI agents with state machines so they can only use approved tools in each phase of a workflow. The project says this improves reliability in tools like Claude Code, Codex, Cursor, opencode, and Pi, and can boost local-model performance on coding tasks.

Statewright adds state-machine guardrails for AI coding agents

Statewright is a new project aimed at making AI coding agents more reliable by limiting what tools they can use at each step of a workflow. The company describes its approach as “agents are suggestions, states are laws,” meaning the model can only act within the rules of the current phase, such as planning, implementing, or testing.

The project was introduced in a Show HN post as a way to reduce the brittleness that shows up when an agent is given too many tools and too much freedom. According to the post, the usual answer is to use a larger model or longer prompts, but that only helps some of the time. Statewright instead narrows the tool set so the model works in a smaller, more focused context.

⚡ New to this?

This news is about a tool that puts hard rules around what an AI coding agent can do at each step. A state machine is a workflow with named phases and allowed transitions, so the agent cannot just pick any tool at any time. That matters because many AI agents fail when they have too much freedom and start looping, guessing, or making unsafe edits.

🦞 OpenClaw angle

If you build self-hosted agents, consider splitting jobs into explicit phases like read, edit, and test instead of giving one agent a broad tool list. Put hard allow-lists around shell commands and block redirects, destructive commands, and arbitrary interpreters outside write phases. If your stack supports MCP or hooks, enforce those rules at the protocol layer so the model cannot ignore them. Also keep an escape hatch for workflows that get too strict, because over-constraining an agent can stall the run.

In practice, that means a planning phase can allow only read-style tools such as Read, Grep, and Glob. When the agent moves into implementation, edit tools become available, but with limits on line counts, file counts, and shell actions. In testing, only approved commands are allowed, such as pytest, cargo test, or npm test.

If an agent tries to use a tool that is not allowed in the current phase, Statewright rejects the call and tells the agent which tools are available and how to move forward. The company says this prevents common failure modes such as agents repeatedly rereading files without making changes, or wandering into dangerous actions like destructive shell commands.

The system is built around a Rust engine that evaluates state machine definitions. The company says the engine is deterministic and does not involve an LLM in the control loop. On top of that sits a plugin layer that connects to coding agents through MCP, the Model Context Protocol, or through hooks in non-MCP setups.

Statewright says the same workflow definition can be enforced across Claude Code, Codex, opencode, Pi, and Cursor. The company labels enforcement as “hard” for Claude Code, Codex, opencode, and Pi in the contexts it described, while Cursor enforcement is described as advisory because of its architecture.

The post includes a bug-fix example where the agent starts in planning, transitions to implementing after reading code, then moves to testing after editing a file, and finally completes after tests pass. Statewright says that in a 5-task SWE-bench subset, two local models with 13.8GB and 19.9GB footprints improved from 2/10 to 10/10 with the state-machine constraints. It also says smaller models below 13GB still hit a ceiling because they cannot hold enough file content to make accurate edits.

Statewright is available as a plugin for Claude Code, with setup through the plugin marketplace and a browser signup at statewright.ai. The company says the managed cloud handles workflow storage, run history, and the MCP gateway, while the core Rust engine is Apache 2.0 and can be embedded without runtime dependencies. It also says single-developer and single-team self-hosting of the full stack is allowed under the FSL license.

The project’s docs include workflow authoring, schema reference, and examples. The company also notes that if a workflow is too restrictive, statewright_deactivate can be used as an escape hatch.

Source: HN Show HN ↗

More from OpenClaw News