Stop probabilistic models from breaking deterministic systems. OpenGantry fail-closes on verify before scoped edits merge — hooks, runtime exec, and CI gates enforce architectural boundaries and SDLC checks. Unstructured errors become machine-readable findings[].
curl -fsSL https://opengantry.ai/install.sh | sh
powershell -c "irm https://opengantry.ai/install.ps1 | iex"
npm install -g @jeger-ai/opengantry
pnpm add -g @jeger-ai/opengantry
bun add -g @jeger-ai/opengantry
{
"status": "failed",
"envelope_schema_version": 3,
"findings": [
{
"failed_gate": "arch",
"offending_file": "src/auth/internal.ts",
"line": 12,
"severity": "error",
"resolution_hint": "Import crosses layer boundary per TARGET_ARCHITECTURE.yaml"
}
]
}Why
OpenGantry scopes multi-agent graphs and single IDE sessions with the same verify gates. When an agent drifts, you get structured findings[] with offending_file and resolution hints when a structured producer supplies them — generic gates stay coarse; use gate_log_path for full traces. Pin a mission, run your orchestration graph, and let the kernel enforce TMVC roots, import layers, and gate_command hooks you already trust.
Whether agents draft docs, landing pages, or release notes, probabilistic output needs a gate before it ships. OpenGantry scopes what files an agent can touch and verifies changes against your standards before commit — so published material stays on-brand, accurate, and traceable to an approved mission.
You want the velocity of autonomous agents, but you cannot afford the technical debt of unverified code. Probabilistic models naturally drift, hallucinate exports, and violate architectural boundaries. OpenGantry is the local governance layer that puts a strict, deterministic cage around your multi-agent workflows. Scoped missions, hooks, and `gantry verify` fail closed before unapproved edits land in Git.
Autonomous agents expand your attack surface every time they run unchecked. OpenGantry enforces scope boundaries, audit trails via mission YAML and EXECUTOR_LOG, and fail-closed verification before code enters your supply chain. Every rejection is machine-readable — ready for SIEM integration and compliance review.
In practice
Composite scenes from how OpenGantry is used.
Staff engineer
I pinned MSN-0042 and let the session run. It tried to rewrite .gitagent/foreman/MANIFEST.json. Runtime failed closed. findings[] named the path. The next hop stayed in src/cli/.
gantry pin · TMVC deny
Tech lead
I will not rubber-stamp a chat transcript. The executor appends PASS rows to EXECUTOR_LOG.md. Those rows have to quote the gate output. gantry verify maps every claim. A missing quote fails the mission.
SOD · verbatim PASS quotes
Security lead
Review is a mission YAML, a quote in EXECUTOR_LOG.md, and an optional attest file under .gitagent/history/receipts/. I keep the verify JSON. I do not keep a screenshot of a model saying it was careful.
attest receipt · verify JSON
North Star
OpenGantry referees an agentic graph. Inner and Outer Loop name the DevEx locus — local generation vs cloud PR — not a cyclical agent workflow.
Commits rain into a PR funnel faster than humans can review. Probabilistic AI reviewers stamp question marks — not proofs.
The Visionary drops business intent on the graph. The Architect draws the cage: deterministic rules, not feature code.
Intent fans out to parallel Executor nodes. The work is a DAG — not a sequential loop.
Structural violations hit the cage and route Exit 1 back to the Executor. Compliant blocks pass Exit 0 into staging — no human in the dark.
Define the intent. Enforce the physics. Read the manifesto.
Orchestration
OpenGantry governs agentic graphs — planners, parallel workers, promote steps,
and retry branches — with the same mission YAML and findings[] contract. A single
IDE chat is the minimal case; orchestration buses and CI pipelines are the norm at scale.
Production setups use orchestration buses (e.g. iii.dev): many holder workers, shared mission scope, and promote-class calls that must carry a verify verdict. OpenGantry registers cold-path `gantry::verify` and hot-path `gantry::middleware` — admission and worktree automation stay in your graph, not in GXT law.
Cursor or Claude Code in one session is still the same contract: legislate scope, execute inside TMVC, verify with structured JSON. One chat is the minimal graph — one executor hop, one verify gate.
GitHub Actions, Harness, or custom runners map cleanly: one mission scopes the run, each stage runs gate_command or calls verify, and structured failures branch the graph without stderr parsing.
How it works
Four gates between agents and merge — at every graph node that touches the repo. Fail closed with machine-readable remediation, not unstructured stderr.
Restrict agent file mutations to explicitly authorized directories and paths via TMVC roots and forbidden zones.
Prevent agents from sneaking unauthorized dependencies or public surface area into your codebase.
Stop hallucinations before they compile. Wire mission hooks directly into your existing linters and type checkers.
Force agents to fix their own mistakes. On failure, OpenGantry returns structured JSON findings[] so agents self-correct instead of dumping broken code into your lap.
Integrations
OpenGantry sits between agent harnesses and the systems you already trust — Git, npm, and your test runners.
OpenGantry
verify · scope · findings[]
Quickstart
gantry legislate "your intent" --msn MSN-0042 --skill-key gantry
gantry verify --json