Introducing Airbender ARC

Every team putting agents into production ends up asking the same question: how do you get unreliable agents reliably into production? Today we're releasing the first blueprint of our answer. Airbender ARC is an Agentic Rail Controller. It is a server you run beside your own applications that resolves the rules your agents must follow, decides in milliseconds whether an action may proceed, enforces the decision, and records evidence an auditor can replay.

We call the discipline Agentic Rail Management, and its unit is the rail.

Why rails

Agents fail in ways software didn't. A model call that is correct 90% of the time is a good model call; an agent that issues the wrong refund one time in ten is an incident. Our working assumption, carried over from the original Airbender manifesto, is that agentic systems embedded in human workflows carry a base error rate of 10 to 30 percent. Better models move that number. They don't remove it.

So the useful question is what happens after the agent is wrong. Guardrails, as the industry uses the word, mostly filter text on the way in or out. That matters, but the expensive failures are actions: a refund issued before an order lookup, a tool called after untrusted content entered the session, a model the security team never approved. Rails govern those.

A rail is a declared, versioned, machine-checkable constraint on agent behaviour, with an enforcement action and an evidence trail attached.

What a rail looks like

Rails live in a bundle in your application's repository, next to the code they govern:

- key: refund_needs_human_above_500
  class: gate
  discipline: safety
  bindTo: [ccp_issue_refund]
  predicate:
    requiredWhen: { measure: refund_amount, operator: ">", value: 500 }
    approverRole: refund_approver
    maxAgeSeconds: 900
  flags: { critical: true }
  rung: R2

Every rail declares six things: its scope (where it applies), its measure (what is observed), its predicate (when it trips), its verdict (how bad that is), its action (what the platform does) and the evidence it leaves. ARC ships ten rail classes: threshold, budget, allowlist, gate, sequence, detector, provenance, drift, aggregate and coverage. The set is closed on purpose. A constraint that needs a general-purpose language becomes a detector behind a rail, so that a rail never turns into a program nobody can audit.

Six rungs, one decision

When rails trip, ARC composes them into one decision and applies it on an enforcement ladder:

A refusal from one rail is never softened by a pass from another. A kill switch is never cached. The database flip is authoritative, and network-level actuators are defence in depth whose failures are recorded rather than hidden.

What is in the blueprint

The blueprint is a walking skeleton with every plane in place, deployed and running:

• railgate, the control plane in Go: the contract of operations, the decision API, rail-bundle publishing and release, and the evidence ledger.
• railproxy, the data plane in Rust: an OpenAI-compatible front door that enforces allowlist and detector rails before a model call leaves your network.
• raildetect: injection, PII and jailbreak detectors behind a bring-your-own-detector interface.
• railconsole: the operator console, built on a design system we wrote for governance work.

The decision kernel exists twice, in Go and in Rust, and both are pinned to the same 83 language-neutral conformance vectors. In production the control plane re-derives every verdict the Rust data plane makes with the Go kernel and raises a platform alarm if they ever disagree. In our first runs they haven't.

What makes it different

Three things, each the subject of a post this week.

• Rails come from a hazard study, not from inspiration. ARC adopts HAZOP from process safety: every control point × guide word is a cell that is covered by a rail, waived with an owner and an expiry, or visibly uncovered. Read the HAZOP post.
• Every verdict is replayable. Evidence is append-only, hash-chained per tenant, and carries the exact inputs the kernel saw. Read the evidence post.
• No activation, no AI. An app proves at connection time that it implements what the released rails demand, or it gets no credential. Read the contract post.

Where it runs

ARC is a server, not a SaaS dashboard. You run one per environment, beside the applications it governs, with a defined API and a defined blast radius. It deploys on Kubernetes through Kilter, on your own clusters or on Paddington's sovereign cloud. Your prompts, completions and evidence stay where your applications are.

Work with us

We're taking a small number of design partners: teams with an agent that is close to production, a risk owner who has to sign off on it, and the patience to run a HAZOP study with us. If that's you, tell us about your agent.