Air traffic control for AI coding

The AI Control Layer for Coding Agents

The control the labs describe for far more capable systems, applied to coding agents today: layered gates that run before a change lands and give the same answer every time.

  • Runs before the change lands.
  • Same verdict every time; no model makes the call.
  • Layered: scope, rules, approval, evidence.

The labs building the most capable models talk about "AI control": keeping a system you cannot fully inspect inside limits you can enforce. Google DeepMind's 2026 control roadmap, as reported by Axios, stresses multiple layers of defence and supervisor systems for increasingly autonomous agents. The conversation is usually framed around much more capable systems, up to superintelligence.

You do not need to believe in superintelligence to need the same property today. If you run coding agents on a production codebase, you already have autonomous systems making changes faster than people can read them. The question is the same at every scale: what stops a change you did not intend?

Oversight that does not scale

Most teams answer with review. A person reads the pull request, or an AI reviewer reads it first.

Both break as agents multiply. A person cannot read forty agent changes a day with the care they gave four. An AI reviewer is a model judging a model: it can approve tomorrow what it rejected today, and you cannot prove why it did either. That is oversight that gets weaker exactly when you need more of it.

Control means deterministic gates

A control layer for coding agents has three properties.

It runs before the change lands. A rule that fires in CI after merge is a detector, not a control. Nool runs your tests and policies when an agent proposes a change, and a change that fails is refused, not flagged afterwards.

It gives the same answer every time. No model makes the call. The same change gets the same verdict tomorrow, so a refusal means something and an approval can be audited.

It is layered. No single rule covers everything, so Nool stacks them:

  • Scope. Agents claim the code they will change before they start, and a task can name paths its work must not touch. Out-of-scope edits are refused.
  • Configurable rules. YAML policies beside the code: block secrets, protect folders, require tests. Your team edits them, and the edit itself lands through the same checks.
  • Hard rules. Logic your platform team compiles to WASM and installs. It runs sealed off, with no network, no files and no clock, and an agent cannot change it by editing a file.
  • Named human approval. For the paths that matter, a change waits for a specific role. In a real run, a change to authentication code paused with pending: needs 1 × steer:ciso until the security lead signed.
  • Evidence. Every landed change carries its intent, test results and approvals in a signed record anyone can verify.

That is the same shape DeepMind describes: several independent layers, and a supervisor that does not depend on the system it supervises.

What it looks like when control works

In one session the model reported its goal "Fully Complete". The acceptance check said otherwise. The session stopped at 80% of its $2 budget and handed the decision to a person. The agent did not get to decide that it was done.

That is the whole idea in one event. Capability is the agent's job. Deciding what lands is yours, and the gate makes sure it stays yours as the agents get better.

Where to start

Start with the rules you would never want an agent to break: no secrets in source, no changes to authentication without the security lead, no billing code without a test. Write the first two as configurable rules, install the third as a hard rule, and turn on approval for the paths that matter.

Read more about AI governance for coding agents, policy as code and security, or talk to us about rolling it out across a team.