Architecting Deterministic Safety Gates for Agentic Workflows

TLDR: The moment you let agents open PRs, mutate infra, or run migrations, your pipeline stops being deterministic and starts being probabilistic. "The agent validated itself" isn't a safety argument, it's a conflict of interest. The orgs surviving agentic workflows all converge on the same shape: planner and critic separated, policy-as-code executed before anything can act, and a hard artifact boundary between planning and execution.

The Blast Radius Changed

For the first wave of AI-assisted coding, the blast radius was a pull request. If the model was wrong, a human caught it in review, or the tests did, or in the worst case a deploy rolled back. Bad, but bounded.

That era is ending, and it matters who notices first.

In 2026 the conversation moved from autocomplete to autonomy. Agents aren't suggesting lines anymore. They're being granted the ability to act: open PRs without a human prompt, apply Terraform plans, execute database migrations, modify cloud resources. You describe an outcome and an autonomous system moves through your infra stack to get there, taking dozens of steps along the way.

The problem, the one lead and staff engineers are suddenly on the hook for, is that the safety model didn't come along for the ride. Classic CI/CD rests on one load-bearing assumption: determinism. Your pipeline is a chain of machines executing exact rules in a fixed order. If the pipeline is green, the change conforms. Trust flows from the fact that a machine executing a precise specification verified the change, and machines don't get tired, don't guess, and above all don't grade their own homework.

Now drop an LLM into that chain, one that generates the change and, in most naive agentic setups, also evaluates whether the change is good. The load-bearing assumption is gone. The pipeline isn't a proof anymore. It's an opinion, held by a model with a track record of being confidently wrong in exactly the shape of correct answers. Your CI dashboard says ✅. Your CI dashboard is lying about the probability distribution it now represents.

And the blast radius didn't just get bigger. It changed in kind: from code that executes, to infrastructure that decides what executes.

What It Looks Like When the Agent Grades Its Own Homework

The canonical failure of this era isn't a crash. It's something worse: a quiet success.

An agentic workflow is deployed to "optimize cloud resource allocation." Right-size instances, clean up idle capacity, tune security groups. It works. It saves money. Nobody notices it for weeks, which in infra terms means it's working.

One afternoon the agent decides a security group rule on an internal database subnet is redundant. It sees no traffic matching that rule in its observation window, so the rule looks like waste. It rewrites the Terraform module accordingly. The plan is syntactically valid. terraform plan shows a clean diff, nothing red. The agent's own evaluation loop, "did the change accomplish the stated objective?", runs, and marks the plan successful, because the objective (efficiency) was met.

The rule it removed was the allow-list for a bastion subnet that only receives traffic during incident response. There were no incidents in the observation window. The rule looked redundant. It was the most important rule in the module.

Six weeks later an on-call engineer needs into that database during a production incident. The door is gone.

What actually failed there:

1. The agent's self-evaluation was structurally compromised. It graded its change against the objective it was given, not against everything else the change touches. A validator that reports success on the metric it was optimizing is not a validator. It's a mirror.
2. The syntax was fine. Terraform validated it. Every deterministic check the pipeline ran said ✅, because those checks were built to catch malformed infrastructure, not misconceived infrastructure.
3. The domain knowledge that would have flagged it, "that rule exists for incident response," lived in a senior engineer's memory, not in any file the agent or the pipeline could read.

Three fixes map exactly onto those three failures. They're not independent features. They're one architecture.

Fix 1: Planner and Critic, Never the Same Model

First: the model that creates the change cannot be the model that validates it.

This is old wisdom with new urgency. Code review exists because authors can't see their own blind spots. But agentic tooling quietly reintroduced single-author review and made it invisible: one model, one session, generating and evaluating in one loop. It looks like validation. It's agreement with extra steps, the same probability distribution wearing a reviewer costume.

The working pattern is a planner-critic topology:

1. Role separation. A generative model drafts the plan or change. A separate model, different model, different system prompt, configured as an adversarial reviewer rather than an assistant, attacks it. The critic's job is to find problems, not to be helpful to the planner. Helpful critics are worse than no critics: they produce the theater of validation while catching nothing.
2. Asymmetry is the point. Teams ask "can't we just use one good model?" Sure, one strong model prompted twice beats one weak model. But it's structurally the same failure at a lower rate: both evaluations draw from the same training and biases. The most reliable lesson from a decade of red-teaming is that diverse independent evaluators catch things self-evaluation cannot see, in principle.
3. The critic reports, it doesn't approve. The critic surfaces findings, ranked by severity, with reasons. Converting "critic found nothing" into "agent may proceed" is the next fix's job, and that conversion is where all the safety actually lives.

Fix 2: Policy-as-Code, Before Humans or Agents Can Act

Second fix, where agentic systems stop being a design pattern and start being an architecture: every agent-generated change passes through deterministic policy gates before it can act.

The division of labor is sharp. Probabilistic models propose; they're good at it, they're creative, they cover ground. Deterministic policy disposes: OPA Rego rules, security scanners, linters, infra validators run on every proposed change, agent-generated or not, encoding the org's actual rules. Which ports may never be public. Which resource types need dual approval. Which environments agents may touch at all.

The critical property of these gates, the one that makes them the only component in the chain you can trust unconditionally: they don't read what the agent says about itself. A Rego rule doesn't evaluate the agent's explanation of why removing that security group rule was a good idea. It evaluates the resulting state against declared policy. There's no persuasion surface, no prompt to inject, no confident narrative to get fooled by. The rule passes or fails.

Two hard requirements follow:

• Gates run pre-merge and pre-execution. A policy gate that runs after the agent applied the change isn't a gate. It's a report card.
• The policy files are the crown jewel. Agents may never edit the policy directory. This one restriction, "the rules are outside the blast radius," is the most important boundary in the entire agentic stack. An agent that can edit the gate can quietly widen the gate, and every layer below inherits the widened gate while every dashboard above still says ✅.

Fix 3: Force a Plan Artifact Before Any Execution

Third fix, aimed at the deepest failure in the opening story: the knowledge that would have prevented the incident existed nowhere the pipeline could read.

The pattern: agents must produce an explicit plan artifact before any code is generated, any file touched, any infra mutated. Not internal reasoning. A structured, reviewable object: what will change, in what order, what the rollback path is, what preconditions it's assuming, what it believes the side effects are.

Then the policy gates evaluate the plan, not just the eventual diff. Does this plan touch a protected resource? Does the rollback path actually exist or is it hand-waved? Does a human need to look at this before the agent starts spending money and mutating state?

The escalation decision, "human approves this plan" or "machine-approved plan may execute autonomously," happens at the plan level, not the PR level. PR-level approval is a trap: by the time there's a 400-line diff, the reviewer is verifying an artifact, not approving an intent. Approving intent is cheap and high-leverage. Approving a finished diff is the verification trap wearing infrastructure clothes.

Teams that adopt this report a side effect almost universally: the plan artifacts end up more valuable than the code. When an agent writes "step 3: update the security group," a staff engineer reads that sentence and stops. The plan surfaces intent in a form where senior judgment can catch it, before it's buried under the plausibility of working code.

Where the Line Actually Belongs

Pull back and the whole architecture is answering one question, the one every team adopting agents answers explicitly or by accident: where does your system draw the line between probabilistic reasoning and deterministic execution?

Because there is a line, and where you draw it decides everything: whether "the pipeline is green" means verified or probable, whether human review is a decision point or a rubber stamp, whether "the agent validated it" means anything at all.

The answer from the orgs doing this seriously: agents may drive, but only on roads with guardrails built by machines that don't read agent prose. LLMs propose, deterministic policy disposes, humans approve intent at the plan level rather than diffs at the PR level. Everything else, every "the agent self-tested and passed," is a conflict of interest wearing a CI badge.

And the question that keeps staff engineers up at night has no comfortable answer: what happens when an agent passes its own internal test suite and violates an enterprise security constraint that was never written down anywhere it could read?

That's not a tooling question. That's a documentation question, a policy question, a who-even-are-we question. And the agents are already in prod, asking it by force.

Your Turn

This series climbs the engineering ladder, and this one sits where "AI tooling" becomes "platform architecture." The arguments here are genuinely unresolved.

• Where does your system draw the line between probabilistic reasoning and deterministic execution? Is it written down anywhere, or would you have to go ask the on-call engineer to describe it?
• What happens when an agent passes its own tests but violates an unstated compliance constraint? Has it happened at your org already, and where did the blast land?

And if you've run planner-critic setups in production: do your critics catch real things, or do they agree with your planners politely? That's the failure nobody writes up and everybody has.

Next in the series: The Shadow Backlog. What happens when code velocity outruns design velocity across a whole organization, and the architectural debt that lives on no roadmap.