ArchRails is the only governance product that gates AI agents before they write code — then enforces the same rules at PR-time. Agentic-friendly auth, federated cross-repo enforcement on the FINOS CALM v1 standard, audit-grade evidence, BYOC deployment. Built for regulated institutions.
Every other architecture / governance / lint tool waits for PR-time. By then your agent has already written the wrong code. ArchRails runs inside the agent's MCP session — your controls fire before the diff exists. Then the same engine runs at PR-time as backstop.
API keys for AI agents, CI pipelines, and IDE plugins. A human signs in once at the dashboard to issue a key; agents then run headless — no interactive browser sign-in mid-coding. Keys expire on a fixed schedule and are re-issued from the dashboard, so a forgotten key stops working rather than living forever.
Agents can't edit your CALM files to make non-compliant code legal. Architecture changes go through your normal human-reviewed PR process. The gate can't be rewritten by the thing it's gating.
If an agent is bypassed (raw git push, manual edit, a different agent), the merge gate runs the identical Python functions and still catches the violation. Two surfaces, one source of truth.
Ask ArchRails the same question twice and you get the same verdict twice. No model sits in the decision path, so there is nothing to re-roll and no answer that drifts between Tuesday and Thursday. That is what makes a verdict something you can put in front of an auditor rather than something you have to defend.
And it is judged against an architecture that is current. The graph moves with your merges, so what gets enforced today reflects what shipped yesterday — not a diagram someone exported last quarter and forgot.
Most tooling reviews what an agent already wrote. By then the change exists, the branch is open, and someone is arguing about it in a comment thread. ArchRails applies your architecture at the point the agent is deciding what to do — so a change that would violate it doesn't get written, and the agent works out another way to solve the problem instead.
Crucially, the rules do not soften because the author was a machine. An agent gets the same verdict a human would get for the same change, and every refusal is recorded. When your risk function asks what your agents have been prevented from doing, that is a question with an answer — which is not the same as being able to say you allow agents but supervise them carefully.
Architecture governance has lived at PR review forever. ArchRails keeps it there — and ALSO pushes the same rule engine into your IDE so agents catch violations before any code is written. Devs ship faster. Regulators still get the audit trail.
Cursor attempts a forbidden DB call during a 3 AM hotfix. ArchRails MCP blocks it inline; the agent rewrites against the CALM-permitted intermediary. Production stays in PCI scope.
ArchRails doesn't invent standards. It enforces what your team defines in a CALM document, and cites every node it used.
If a node, relationship, or interface constraint isn't in your calm.json, ArchRails won't enforce it. Full stop.
Feedback cites the exact CALM node ID, relationship ID, or interface that triggered it — so teams align faster and argue less.
Reviews resolve only the CALM nodes touched by the PR diff. Less noise, fewer false positives, no cross-service contamination.
This is the architecture graph ArchRails renders for every pull request. Drag nodes. Hover for details. Click any node to see how violations trace back to your CALM definition.
ArchRails
OrderService calls PaymentService directly — must route via service-api-gatewayOrderDatabase accessed via HTTP — node declares JDBC:5432 onlyInventoryService changes scoped to service-inventory — no leakagePaste your calm.json to instantly check for interface violations, missing controls, and structural issues — then render your architecture graph interactively. No account required.
archrails arch generate in your repo and it reads your code and writes a first-draft architecture document, plus the configuration ArchRails needs to enforce it. It uses a coding agent you already have installed — Claude Code, Codex, Gemini CLI or Cursor Agent — so ArchRails calls no model service of its own and no AI API key is involved. Budget 20–40 minutes on a large repo; it is a one-time cost. You review the draft like any other PR, merge it, and enforcement starts on the next one. If you'd rather author by hand, the free CALM Visualizer is available with no account required. Declaring the architecture once is the fundamental that lets AI amplification go in a useful direction; without it, more agents just means more entropy.calm.json. Every comment is traceable to a node ID you authored. It's deterministic, not probabilistic, and the same gate runs at PR time and inside the coding agent — so the agent can't reach an API your architecture forbids. As Adam Bender put it at SE@TP 2026: “all of your APIs just became public” the moment you let agents loose. ArchRails is the contract that says which ones they're allowed to call.calm.json at the repo root describes your full system graph, and ArchRails only evaluates the slice of the graph a given PR actually touches — a payment-service change won't trigger inventory-service checks. This is deliberate: dependency graphs scale quadratically with codebase size, so at the 10× AI-driven velocity everyone is preparing for, evaluating everything on every PR is how you burn your test budget into the ground.
Founder & Engineer
ArchRails started as a practical system: keep architecture consistent as teams scale — without relying on tribal knowledge. By grounding reviews in a CALM architecture graph rather than generic training data, every violation is provable and every comment is traceable.
Start with one repo and one CALM document. ArchRails will enforce it on every pull request.