Guardrails vs statewright
NVIDIA's programmable guardrails for LLM apps: input, output, dialog and retrieval rails defined in Colang, wrapping any model or LangChain runnable. — versus — State-machine guardrails for AI agents: define workflow phases once and only that phase's tools unlock — enforced across Claude Code, Codex, Cursor, opencode and Pi. Rust.
Both constrain what a model may do, at different layers: NeMo rails conversational I/O in Colang; statewright gates tool access by workflow phase for coding agents.
| Guardrails | statewright | |
|---|---|---|
| Stars | 6.9k | 452 |
| Forks | 798 | 19 |
| Language | Python | Rust |
| License | NOASSERTION | NOASSERTION |
| Last activity | 2 days ago | 13 days ago |
| Topics | security | coding, orchestration |
| Curated connections | 6 | 2 |
Guardrails — the curator's take
For when policy needs to be programmable, not a blocklist: topic bans, jailbreak checks, tool-use constraints and dialog flows written in Colang, enforced as input/output/dialog/retrieval rails around any LLM — RunnableRails drops it straight into a LangChain pipeline. NOT free at runtime: every rail is extra LLM calls and latency, Colang is its own language to learn, and rails mitigate rather than guarantee — you still red-team the result (that's garak's job).
statewright — the curator's take
'Agents are suggestions, states are laws' — gating the TOOL space per phase is the right enforcement layer, and their small-model results (2/10 → 10/10 on a 5-task SWE-bench subset) suggest constraints can substitute for scale. When NOT: it's SaaS-keyed — sign-up required, NOASSERTION license; the enforcement client is open but the service isn't. The benchmark is 5 tasks, not 2294, and hard-blocked tools also block legitimate improvisation.