All entries
Published

What Are Guardrails?

Guardrails are the checks that decide whether a step may proceed, enforced inside the pipeline rather than described alongside it. A guardrail is not a policy document and not an instruction in a prompt. It is a condition the run must satisfy to continue, evaluated at the point of action. If the condition fails, the step does not happen.

Definition

The distinction is easy to blur and expensive to confuse. A rule written into a prompt is a request made to a probabilistic system: it will usually be followed and cannot be relied on to be. A guardrail is a property of the pipeline: the step cannot pass unless the condition holds. One describes intent; the other removes the option. "The prompt says not to write there" and "the write cannot execute" are not two versions of the same control. They differ by whether failure is possible.

Guardrails sit at the boundaries that matter: what an output may contain, what a step may read, where a result may be written, and how much of a process may run without a check. Each one is a test with a defined pass condition, placed before the action it protects — not after it, where the only work left is cleanup.

Why it matters

Automation moves the consequence of a mistake from a person's judgment to a system's behavior. A person who is unsure stops. A model that is unsure produces output anyway, in the same form as when it is certain. That asymmetry is the reason a rule has to be enforced rather than requested. Anything that depends on the model choosing to comply is a preference, and a preference is not a control.

Enforcement also changes what a team can answer. When a guardrail is a check, its outcome is an event: it passed or failed, on this run, with this input, and the record says which. A team can then answer the questions a control is supposed to answer — what is this system permitted to do, did it stay inside that, and what happened when it did not. A guideline in a document answers none of them, because it never runs.

There is a practical effect as well. Guardrails are what make speed possible. A pipeline whose limits are enforced can be left to run unattended, because the limit does not depend on anyone watching. A pipeline whose limits are advisory has to be supervised, which puts a person back in the loop and cancels the reason it was built. A check that is genuinely enforced is what lets a step move quickly without being shadowed.

How Opsyl implements it

Opsyl builds guardrails as executable steps, not as documentation around the work.

  • Checks, not text. A guardrail is a condition the pipeline evaluates, not a sentence in a brief. It has a defined pass state and a defined fail state.
  • Placed before the action. The check runs before the step it protects, so a failed condition prevents the action instead of reporting on it.
  • Validate before it writes. A result that fails its check does not reach a system of record. Nothing is written first and reconciled later.
  • Failures route, they do not disappear. A guardrail that fails sends the run down the human path with the reason attached, rather than silently retrying or dropping it.
  • Every outcome is recorded. Passed and failed checks are both logged, so the control is visible in the run record and in telemetry, where blocked runs count as failures.

The point of a guardrail is the claim the rest of the system works to: AI is probabilistic, our pipelines are not. A guardrail is where that is made operational — the place where the pipeline stops depending on a model's willingness to comply and simply cannot continue if the condition is not met.

Where this connects

Guardrails are the mechanism; the statement they enforce is the Output-Contract Validation that defines a valid result in the first place. Together they sit inside the Operating Layer and form the enforceable half of Agent Governance — the difference between rules that are documented and rules that hold. And when a guardrail does fail, the response is not a wall but the handoff described under Human-in-the-Loop.

The commercial consequence

Whether an automation is safe to run is decided by where its guardrails are, not by how well it performs in a demonstration. The first paid step with Opsyl is the Agentic Ops Audit: a fixed-scope week that maps the operation and returns a written assessment of which steps can be enforced and which still depend on something being followed. You keep the assessment whether or not you build.

Start with the audit → /pricing/

→ Related: Output-Contract Validation · Agent Governance