I’ve been building an open RPG game engine called Oathshaper. It’s current incarnation was created with Godot and inspired by the BioWare classics (Jade Empire, Mass Effect, Knights of the Old Republic, Dragon Age, etc.) The storytelling, voice acting and actions that have consequences in those games have always found a place in my heart.
A few weeks back I was showing my son how each BioWare game had different combat mechanics on a Steam Deck and I was inspired to create Oathshaper to model these mechanisms around a cohesive, voice driven story telling foundation. A short time later we heard the news that the BioWare studio was closing.
The game engine is written in Rust which hooks into Godot
I’ve released it as MIT on GitHub - https://github.com/oathshaper/oathshaper - free for the world to explore and collaborate on. It includes some tooling aimed at educators looking to teach AI/Agentic forward game design. An introductory game design course/offering could let students design their own storyboard implementation with assets as the first project and spend the rest of the curriculum going back and learning how each part of the asset/content creation pipeline actually works.
The GitHub release includes “Lantern Quay” a playable demo for Windows, Mac and Linux which lets you choose one of three combat style demonstrations:
* Command - A Knights of the Old Republic inspired system where you give queued orders
* Flow - A Jade Empire inspired system where combat flows naturally within a chosen style
* Vanguard - A Mass Effect inspired system where you run a squad in a third-person shooter type scenario
Here is a demo video highlighting the three styles and the story telling mode: https://www.youtube.com/watch?v=it2bQDUMk3k
Downloadable demos here: https://github.com/oathshaper/oathshaper/releases
Feedback is encouraged and welcome!
Hey HN!I’ve been building an open RPG game engine called Oathshaper. It’s current incarnation was created with Godot and inspired by the BioWare classics (Jade Empire, Mass Effect, Knights of the Old Republic, Dragon Age, etc.) The storytelling, voice acting and actions that have consequences in those games have always found a place in my heart.A few weeks back I was showing my son how each...
Native model switching without leaving the terminal UIs you know and love has opened a lot of doors (and saved a lot of tokens)... I'd love to answer any questions anyone has about it here!
We've all had the same struggle, torn between wanting to run longer loops and maximize our current subscription quotas but not wanting to hand the keys to the kingdom over to an unrestricted OpenClaw or Hermes agent.
These tools are prominent examples of the recent long-running agent wave... Loop Engineering is not just letting an agent run until it declares itself victorious, but also properly designing an outer loop around said agent. I believe the discipline is better served with a bit more structure.
A better loop in my eyes is a sequence of bounded phases where each phase carries its own model, reasoning level, tool permissions, budget alongside escalation rules and intervention points. The agent should keep moving autonomously until the task is completed or human intervention is required.
The expensive frontier model isn't always the right call. Routine tasks like inspection, data extraction and validation can all run comfortably on less capable models... but you don't want to be around to switch them manually.
With the 0.3.0 release of Statewright (statewright.ai) you can perform Loop Engineering directly within the Claude & Codex TUIs you already love and trust. I didn't want to create another separate tool which forces me to give up my existing skills, agents and other native conveniences like Codex auto-approve, so I opted to make Loop Engineering work better in native TUIs.
At each phase boundary, Statewright can change the active model, reasoning level and token budget which is the big change here. Mixed with it's previous feature set you can assign tool permissions and other necessary guardrails to prevent your agent from running amok. It accomplishes this without requiring that you utilize separate agent shells or be at the helm injecting /model and hoping it lands at the turn boundaries you desire.
The benefits are cut and dry at the onset: leaving a frontier model active is a blunt instrument which is often overkill. In a similar time period and workload I consumed 10% of my weekly quota where the previous day I spent 60%. While testing Claude I was finally comfortable letting the agent run in YOLO mode (--dangerously-skip-permissions) with Statewright’s guardrails.
The end goal with Loop Engineering is not to make agents run forever, it's to make each additional turn intentional with the right model/reasoning, the right guarded tool access, a known token budget and a reason to continue.
UserPromptSubmit hook: injects state context into every prompt... phase, available tools
Instructions: the model sees transition() and get_state() as MCP tools it can call. PreToolUse hook blocks disallowed tools at execution time and returns an error with what IS available.
PostToolUse hook: detects file changes and fires interrupts.
Things in CLAUDE.md are merely suggestions, hooks are enforcement. The model can rationalize away instructions but it can't rationalize away a blocked tool call.
The Pi plugin takes this further... pi's extension API lets us remove tools from the model's view entirely via setActiveTools() so it never even sees what it can't use. smaller tool space, better reasoning. Better Pi support is a recent enhancement and it's getting better.
OSS: The `engine` and `agent` crates are now fully open (Apache 2.0). only the `gateway` and the various plugins are FSL with a 3-year clock. You can run the full state machine locally, self-hosted, no cloud dependency. The end-to-end workflow works out of the box with ollama and any 13B+ model now.
Multi-agent support: I validated and enhanced plugins for Codex CLI, Oh-My-Codex, and Pi alongside the existing Claude Code plugin. Same gateway, same workflows, different agent frontends. the Pi plugin in particular is interesting because pi's extension API supports things Claude Code doesn't yet... programmatic model switching and per-state tool filtering where the model literally never sees disallowed tools.
Interrupts: Reactive file triggers that force state transitions. model edits a migration file? interrupt fires, pulls it into a review state. it uses the History State pattern to return where it was in the state machine after.
Fork/join: Parallel sub-agent execution. planning state dispatches N implementation branches each in their own worktree, join collects results.
Allowed_commands: Per-state bash command restrictions. testing state can run pytest but not rm -rf. enforced in the hook, not the prompt.
Tangentally, the Forge post this week (https://news.ycombinator.com/item?id=48192383) validated the same thesis from a different angle... structural guardrails on small models outperform unconstrained frontier models. three independent projects converging on "the harness is first-class infrastructure" in roughly two weeks.
Next on the agenda: per-state model routing. use a local 12B for grunt work, route to Opus/GPT-5 for the one call that matters. the cost math is trending towards ~80% reduction on a 6-phase workflow
You should be able to run self-hosted end-to-end with docker-compose, let me know with a GitHub issue if something isn't working in that regard
One of the most surprising findings was when a 9B model self-corrected through 4 tool parse failures within the guard rails. It tried to use a complex tool (patch_file), kept failing and eventually downshifted to a simpler tool (edit_line) that it could actually execute. The guardrails didn't make the model smarter, it just narrowed the execution space until it could find something that worked.
The plan/implement/test workflow is very basic and represents the most common agentic use case. But the state machine pattern applies to any multi-step work where agents are useful but susceptible to death spirals, hallucinations, or other non-deterministic quirkiness. This also enables Claude Desktop and other non-coding agents to perform useful constrained work.
I've been building a content pipeline for tabletop publishing and tested it a bit earlier yesterday. A research phase gathers lore and game details from a compendium, a drafting phase generates structured content including schema-specific JSON validation (so my Lua+LaTeX templates work without iterating). A review gate has me editing content directly (tmux+neovim dialog is great for this). The agent shapes the content, makes sure it conforms to JSON validation and content requirements, then I write it. Before I adapted the state machine to it, the agent tried to do everything all at once — calling multiple agents is sometimes effective but details get lost and you definitely lose visibility in the summarization. The state machine runs everyone serially (for now) but chaining and parallelization are on the roadmap.
While working with statewright on a different workflow over the weekend and Claude (as Claude does) attempted to write an intricate bash script to work around a guardrail... and statewright blocked it! I think that was when I knew there was some real power behind what's been built here. Enforcement has to be structural, not advisory.
Also, being generally useful for things besides coding you can start to think about things like SOC 2 change management. Every change needs a plan, a human review gate, audited implementation, pull request, review, human approval, and then finally a human to approve a production deployment. Today teams enforce this with checklists and hope. An agent constrained by a workflow that won't let it deploy without all the prerequisite pieces is enterprise delivery with an auditable paper trail and humans injected for approvals where they need to be - not managing each change's lifecycle.
The piece I'm most excited about is agent-generated workflows. You solve a problem once and maintain your context, then point the agent at the JSON schema and it creates and uploads a new workflow to statewright automatically that you can use immediately. No fine-tuning, no exhaustive prompt engineering, no dozens of agents... best-fit lightweight guardrails that agents help build themselves, compiling your intent into structure the models can't weasel their way out of. This is a fundamentally different reality than what the current state of the art is practicing. I think that's a big deal.
Done :) https://github.com/statewright/statewright/blob/main/PATENTS...
Thank you for calling my attention to this. I think the world would be a better place if everyone just left the lawyers out of everything
Opencode's plan/build is decent, like it is in Claude Code... state machines are the next evolution. model agnostic, tooling agnostic (where feasible)
they don't indicate whether the transition is guarded or not... that is shown in the sidebar when you click a state.
that's fine 90% of the time... the state machine for the other 10% where the model's judgement call costs you an hour of debugging later (confidently fixed wrong, or overzealously) or stops a mostly automated thing because it got stuck on the wrong path.
"the task is so simple that maybe I don't need worktrees" is the model overriding your intent with its own judgement and that's a pattern I'm seeing more and more as these models mature. statewright provides the guardrails... strong suggestions up front on what it can do in X state via injection and if it still wants to try and outsmart that, it gets hit in the post hook and the model gets the message "oh, you're right I shouldn't do it that way" ... instead of you course correcting, it's the state machine
the MCP server is just the way to get statewright in the hands of a wide array of existing use cases, claude code included. not all agentic clients are created equal and Pi is actually the experience I want to hone next (also the most extensible)
The main difference with Statewright is that tool access changes over time within a single agent. Planning phase gets read-only tools, edit capability unlocks after the agent proves it has adequate understanding... test tools unlock after the fix. State machines handle the phase transitions, guards and retry loops.
Your multi-agent approach decomposes by role instead of by phase/state. Both are valid. Since you're already in Rust, the engine crate (crates/engine) is a pure library with no deps. It might be interesting to see if putting a state machine around your orchestration layer improves your observed performance
re: Claude Code... we actually don't filter or modify the tool list so all tools stay visible -- disallowed calls get blocked at execution time with an error message. No cache busts on transitions, the model sees the full tool sets. The cost there is prompt caching dollars not latency I suppose
re: The research (Rust agent + Ollama) the model only receives tool schemas for the current states' allowed tools. Ollama does have a KV cache reuse facility so changing the tool list busts that cache. Depending on your workflow this can happen as many times as you expect your states to transition until completion. For simple workflows this is 3-5x. Within each state the tool list is stable and cache operates normally. Presenting fewer tools instead of dozens on every agent processing step reduces input tokens and decision complexity, which is where the measurable gains come from.
Both enforce the same constraints depending on the execution interface. The schema level filtering in the research is the S-tier approach. Adding tools/list filtering to the MCP gateway would be beneficial if possible (it looks like we could only filter MCP tools not core ones, which could provide tangible benefit. I've added this evaluation to the roadmap.
Each state has an `instructions` field for phase specific guidance and when an agent's action (tool call) gets rejected the error message lets the model know what went wrong, and what's available to move forward
Tool 'Edit' is not available in the 'planning' phase. Allowed Tools: Read, Grep, Glob To advance, call statewright_transition with READY -> implementing
Models (even simple ones) tend to reason through these error messages, adjusting their approaches as opposed to retrying the blocked call. Additionally, on transitions the model is required to include a rationale explaining why it's transitioning (`data.rationale`) which creates an audit trail of the agent's reasoning at each phase boundary. That ends up being one of the most useful parts of the run history viewable on statewright.ai
The omission wasn't intentional -- the patent grant wasn't on my radar when the original license text was committed. FSL licensing is very new territory for me and I duffed it slightly, now corrected.
Re: Reproducing the results: the engine, agent crate and demo TUI are all in the repo. If you have ollama running with a 13B+ model, task run:bugfix reproduces the simple bugfix result end to end. What isn't published yet is the SWE-bench experiment harness (task selection, patch scoring, control runs). I need to get that out, I prioritized the end-to-end simple Claude Code plugin for the launch. The demo crate (crates/demo) contains a demo TUI which calls ollama and runs the bugfix state machine interactively with code.
Re: Engine: The core engine (crates/engine/) is the pure Rust state machine evaluator. It's what Statewright is running on the backend. JSON in => transition decisions out. Agent (crates/agent/) builds on top of it to make it useful for LLMs. That all is Apache 2.0 with no restrictions.
Re: the Patent: The patent covers the method of using state machines to constrain LLM agent tool access at the protocol layer. It's defensive, it helps protect the managed service and the idea from "being scooped" from a larger company with more personnel and resources. It's not targeted against solo developers, self-hosters or researchers.
You'll find that the portions that I've released FSL 1.1 have explicit grants which do not restrict solo developers or single team self-hosting. The code released this way becomes Apache 2 in exactly 3 years. This is not unlike what Sentry and MariaDB did. I am planning on releasing more portions as FSL 1.1, I just hadn't crossed that bridge and honestly this thing seems to have gotten popular at the moment so I thought I'd set the record straight a bit
it (the LLM) can't skip from implementation to deploy if the guard says the tests haven't passed. the model will receive feedback that what it's tried to do is invalid and give the reasons why. it can't be skipped. it then tries to resolve that new information to make the state transition... almost like it would responding to a human in the chair denying a step.
the model can't merge if it hasn't gone through your review state, even if it wants to (it'll try though)
the state engine doesn't judge, it enforces... with code and not transformers ^_^
if a tool (or any other guardrail) isn't valid at a given state the model call gets rejected before the model sees the result. that's the gap between "a model said this is okay" vs. "the system structurally prevents this"