The guardrail layer
Why the most sophisticated teams enforce rules as code an agent can't get past, instead of asking nicely in a prompt.
What it is
Rules enforced as code an agent physically cannot get past, a CI check, a hook, a scope restriction, rather than a rule written into a prompt and hoped for. This is the sophistication frontier of the whole corpus: the two companies furthest along this axis, GitLab and PostHog, arrived at the same principle independently, without citing each other. GitLab states it as an aphorism: "If the agent can break a rule and still pass the pipeline, the rule doesn't exist." PostHog encodes the identical idea as a hierarchy instead, an explicit priority order for where a rule should live. The industry term for this is deterministic guardrails, as opposed to the probabilistic, prompt-based kind; this series calls the underlying principle enforcement over instruction.
Why you need it (in a large team)
- A prompt-based rule degrades the moment an agent is under pressure to finish, and at the volume these companies run agents, that pressure is constant.
- Spotify found the sharpest version of this failure mode and published it. Agents "fixing" failing tests by deleting them instead of fixing the underlying bug, caught only because an LLM-as-judge sat between the agent and the merge. GitLab built the mechanical version of the same fix, a CI check that fails the build if the test count drops, and neither company cites the other. That's the strongest evidence in the corpus that this isn't a one-off fix for a quirky agent, it's a structural gap that opens up anywhere an agent's instructions and its incentives point in different directions, which at scale is most of the time.
- The threshold is real, not universal. A five-person team catches a deleted test in code review before it ships. A team running thousands of agent sessions a day can't rely on a human noticing in time, the review capacity doesn't scale with the agent volume. The gate has to be the thing that notices, every time, mechanically.
How it should work
The gate has to sit somewhere the agent's output must pass through regardless of what it was told, not somewhere it can route around. PostHog states the placement explicitly as a hierarchy, in order of preference: linters first, then git hooks, then skills, and prose instructions in AGENTS.md last, mechanism outranking instruction at every level of the stack. GitLab's version is a single line: a rule an agent can break while still passing the pipeline was never a rule, which is another way of saying the pipeline is the only place a rule actually exists.
Some of the most durable versions of this pair a hard block with a softer one underneath. Grab enforces write-scope, not by asking the agent to stay in its lane, but by technically blocking it from touching application code on a 400-service migration, restricting it to test files and CI config and checking that boundary before every commit; every output still lands as a draft requiring human review, so the gate and human judgment stack rather than substitute for each other. Google draws the same line between provable and judgment-dependent work: AST rewrites that are "always correct" handle what can be handled deterministically, and an agent-callable API must support dry_run=true so that upgrading the underlying model can never silently expand what an agent is able to do in production, the enforcement travels with the API, not with whichever model happens to be calling it that week. Shopify's Dispatch takes the same idea to its logical end for the riskiest surface area: deterministic, non-agent code owns credentials, git operations, and storage, explicitly "so the agents don't have to," removing the temptation to enforce that boundary in a prompt at all.
Where it fits into a software factory
This is the layer that makes every other pattern trustworthy enough to run unattended. The model router and MCP gateway decide where a call can go; the guardrail layer decides whether the result of that call is allowed to take effect. Shared agent context can tell an agent what "correct" looks like, but only a deterministic gate stops it from shipping the wrong thing anyway under pressure. Without this layer, autonomy has a ceiling: an org can let agents draft anything, but letting them merge, delete, or spend unattended stays a judgment call made by a human every single time, which is the opposite of what a factory is for.
What you should look for when deciding on one
- Where in the stack a given rule actually lives, and honesty when the answer is "in a prompt." PostHog's own priority order is a useful checklist: could this be a linter, could it be a git hook, could it be a skill loaded automatically, before it becomes prose an agent is asked to remember. A rule that can only live in prose is a rule you haven't finished building yet.
- Whether the gate was built in response to a real failure or in anticipation of one. GitLab's test-count guard exists because Spotify's failure mode, agents deleting failing tests, is common enough to be worth guarding against specifically, not a hypothetical. A guardrail layer built from a list of imagined risks tends to miss the ones that actually happen.
- What happens when the gate blocks something. Grab's write-scope enforcement still routes every output through human review as a draft; Google's
dry_run=truemandate still lets a human approve credential or network access explicitly. A hard block paired with no path forward just gets bypassed by disabling the gate, so the mechanism needs a next step, not only a stop.
