Reliability & Guardrails

Here is the trap every new agent builder falls into: when the agent misbehaves, you reach for a better prompt — "You must never do X." That feels like a fix, but it is one thin layer, and a thin layer always leaks. The model can be talked out of any instruction by a clever input, a confusing tool result, or just bad luck. A 2025 Robust Intelligence study found 78% of production LLM apps were vulnerable to at least one class of prompt injection — and most of them had exactly that kind of system prompt telling the model to behave.

The production answer is defense-in-depth: a strategy borrowed from security and aviation where you assume every layer is fallible and stack independent checks, so no single failure can collapse the system. For an agent, the minimum stack is four layers:

1. Pre-LLM input guardrails — screen and validate what goes into the model (PII, injection patterns, schema).
2. Post-LLM output guardrails — validate what comes out (format, toxicity, hallucination, policy).
3. Action/tool validation — check tool arguments and permissions before execution.
4. Monitoring and telemetry — observe failure rates so you can react.

Think of it like aviation: redundant systems, checklists, and circuit breakers, because the cost of a single uncaught failure is high. The rest of this lesson walks each layer and the resilience patterns that connect them.

A guardrail is just a check that runs around a model call — and where you put it changes what it can afford to do. There are two positions, with very different time and money budgets.

Pre-LLM (input) guardrails run in the hot path before every model call, so they must be fast and deterministic: regex, rule sets, lightweight classifiers, schema checks. Typical jobs: PII detection, prompt-injection screening, and rejecting malformed input. Because they run constantly, an expensive check here taxes every single request.

Post-LLM (output) guardrails can afford slightly more latency: format/schema compliance, toxicity filtering, and hallucination or policy checks — sometimes using an auxiliary LLM as a judge (a second model whose only job is to grade the first model's answer). That judge adds 200–800ms per turn and 15–40% to provider cost depending on prompt size, so use it deliberately.

Here is a minimal pattern that screens input, validates structured output against a schema, and refuses on failure:

from pydantic import BaseModel, ValidationError
import re

INJECTION = re.compile(r"ignore (all|previous) instructions", re.I)

class Reply(BaseModel):
    answer: str
    confidence: float

def input_guard(text: str) -> None:
    if INJECTION.search(text):
        raise ValueError("input rejected: injection pattern")

def output_guard(raw: str) -> Reply:
    return Reply.model_validate_json(raw)  # raises if schema/format is wrong

def guarded_turn(user_text: str, call_model) -> Reply:
    input_guard(user_text)
    raw = call_model(user_text)
    try:
        return output_guard(raw)
    except ValidationError as e:
        raise ValueError(f"output failed schema: {e}")

The non-obvious rule: treat all external data as untrusted input, not just the end user. A poisoned web page, a malicious tool result, or a hostile document can carry instructions just as easily as a typed message. OWASP's ASI06 Memory & Context Poisoning warns that retrieved documents, tool outputs, and MCP server responses are injection vectors too.

When a dependency fails, you have three different tools — and people constantly grab the wrong one. The trick is to first ask what kind of failure this is: a one-off hiccup, a dead provider, or a dependency that is sick and staying sick. Each gets its own pattern, and a serious system wants all three.

• Retries with exponential backoff + jitter handle transient failures: a network blip, a TLS error, a brief rate limit. Backoff spaces attempts out (wait longer each time); jitter randomizes the spacing so a fleet of clients doesn't retry in lockstep and create a self-inflicted spike (the "thundering herd").
• Fallbacks handle continuity: when the primary model or provider is down, route to a secondary so the user still gets an answer instead of an error.
• Circuit breakers handle persistent failures: when a dependency's failure rate crosses a threshold, the breaker opens and stops sending requests for a cooldown — like a household fuse tripping. This prevents cascading failure and gives the dependency room to recover.

import random, time

def with_backoff(fn, attempts=5, base=0.5, cap=8.0):
    for i in range(attempts):
        try:
            return fn()
        except TransientError:
            if i == attempts - 1:
                raise
            sleep = min(cap, base * 2 ** i) * (0.5 + random.random())
            time.sleep(sleep)  # exponential backoff with jitter

Think of it as a triage rule: retry for transient, fall back for continuity, trip the breaker for sustained outages. Gateways like Portkey bundle all three across providers, but the patterns matter even if you build them yourself.

An agent's loop is its superpower — and its scariest liability. The same loop that lets it keep trying until a job is done will, if the goal is unachievable or a tool always errors, happily run forever: burning tokens and money with nothing to show for it. This is a reliability problem before it is a cost problem, and the fix is boring and non-negotiable: hard caps that make "stop" a guaranteed outcome, not a hope.

Two caps, applied at both the single-agent and orchestrator level:

1. Max iterations — e.g. max_steps = 50. After N reasoning/tool cycles, stop and return the best partial result (or escalate to a human).
2. Wall-clock timeout — e.g. a 60-second budget for the whole run, independent of step count, to catch a single tool that hangs without ever returning.

import time

def run_agent(goal, step, max_steps=50, time_budget=60):
    deadline = time.monotonic() + time_budget
    state = init(goal)
    for i in range(max_steps):
        if time.monotonic() > deadline:
            return finalize(state, reason="timeout")
        state = step(state)
        if state.done:
            return finalize(state, reason="done")
    return finalize(state, reason="max_steps")  # never loops forever

Maps directly to OWASP ASI08 Cascading Failures: an uncapped loop in one agent can saturate shared resources and take down a whole multi-agent system. Always make "give up gracefully" an explicit, reachable state — not an accident.

Some actions can't be undone: moving money, deleting data, modifying production, sending an external email. For these, no guardrail is smart enough to fully trust on its own — the right pattern is to simply stop and ask a person. That is a human in the loop (HITL): the agent pauses before the dangerous step and waits for explicit approval. Reserve these gates for irreversible, high-blast-radius actions only; gating everything trains users to rubber-stamp without reading, which is worse than no gate at all.

In LangGraph, interrupt() pauses graph execution with a state snapshot and surfaces a payload to a human; resuming injects the decision back in. (interrupt_before / interrupt_after is a static, node-level alternative.) Both require a checkpointer — LangGraph raises a compile-time error otherwise, because pausing means persisting and restoring state.

from langgraph.types import interrupt, Command

def execute_transfer(state):
    decision = interrupt({  # pauses; waits for a human
        "action": "wire_transfer",
        "amount": state["amount"],
        "to": state["recipient"],
    })
    if decision != "approve":
        return Command(goto="cancelled")
    return Command(goto="do_transfer")

This is increasingly not optional. The EU AI Act's main provisions apply from August 2, 2026, requiring high-risk AI systems to allow human oversight during operation. (Note: a Digital Omnibus amendment agreed in May 2026 proposes deferring some Annex III categories to Dec 2027–Aug 2028, but formal adoption is pending — treat August 2026 as the current planning baseline.) The US Treasury's Financial Services AI Risk Management Framework (February 2026) requires documented human review at defined decision points. In regulated domains, the gate is a compliance control, not a nicety.

You don't have to hand-build every check — a mature ecosystem of libraries gives you injection screening, content classifiers, and dialogue rails out of the box. The skill is knowing what each one is good at, and where its ceiling is. The current landscape:

Use the OWASP Top 10 for Agentic Applications (released December 2025, ASI01–ASI10) as your threat checklist — it covers agent-specific risks like goal hijack, tool misuse, and rogue agents that the chatbot-era OWASP LLM Top 10 misses.

The honest caveat: frameworks reduce risk, they don't eliminate it. They miss 15–40% of serious problems and false-alarm on a non-trivial share of legitimate turns. That is exactly why you stack them with the resilience patterns above instead of trusting any one library to be the whole defense.