Prompts tell your agent what to do. Guardrails determine whether it should be allowed to do it right now — given how much it has already spent, how deep the call stack has gone, and how many times it has already tried.
A runtime guardrail is a check that runs at execution time, before an action is taken, against the live state of a running agent. It is not a rule in a prompt. It is not a filter on model output. It is a decision made by an external component that has access to information the model itself does not have: cumulative spend, call depth, step counts, request rates, and retry history.
The distinction matters because agents frequently behave within their prompt constraints while still exceeding operational limits. A model following its instructions correctly can still issue many requests in a short window, exceed a cost budget, or recurse beyond a useful depth — not because it ignored a rule, but because it has no mechanism to observe or enforce those limits from inside the inference loop.
It is reasonable to include cost or retry guidance in a system prompt. It is not reliable enforcement. A prompt instruction is processed at inference time. The model weighs it against context, conversation history, and current task pressure. Under high task pressure or in long-running contexts, prompt instructions can be underweighted or simply not acted on.
Runtime enforcement operates outside the model entirely. It receives a request, checks it against current state, and returns a decision before the action is attempted. The model has no role in that decision.
Agents that call expensive tools or models can accumulate significant charges quickly, particularly in retry or exploration scenarios. Enforcement requires tracking spend in real time across all calls in a session or chain and stopping before the next action that would exceed the budget — not after.
When agents delegate to sub-agents, which delegate further, the resulting call stack can grow in ways that are invisible to any individual agent in the chain. An outer agent has no direct view of how many layers of delegation are below it. An inner agent has no view of what delegated it. Runtime enforcement at each layer is the mechanism for capping nesting depth across the full stack.
Agents retry on failure. In some configurations they retry repeatedly on the same failing action without making progress. A step cap and a retry limit, enforced at runtime against external counters, stop a chain that is not converging — independently of what the model believes about its own progress.
High-throughput agent workflows, particularly batch pipelines, can issue requests at rates that affect the services they are calling. Volume controls at runtime give orchestration layers a way to slow down before reaching a hard external limit.
Each of these checks is individually understandable to implement. Building all of them correctly for production use involves real engineering: runtime state that survives restarts, policies that can change without redeployment, handling of concurrent calls, enforcement across agents, and operational visibility into what was decided and why. The total is not prohibitive, but it is meaningful ongoing work. A dedicated service handles that maintenance so the engineering team does not have to.
Redlynr is a guardrail API designed to sit in your orchestration layer and answer one question before every agent action: proceed, slow down, or stop.
You call POST /run before each step. Redlynr checks four dimensions — cost, chain depth, steps and retries, and request volume — and returns a single verdict. Your orchestration layer acts on it.
Before executing, your orchestration layer calls Redlynr.
Cost, chain depth, retries, and volume — evaluated in a single request.
Your orchestration layer acts on the verdict before the action runs.
No policy configuration is required to start. Redlynr applies sensible defaults immediately after registration: a $50/24h tenant cost ceiling, a 5-level depth cap, a 20-step chain limit, and a 2-retry limit per agent. You can observe actual behavior with those defaults and adjust from there.
Runtime guardrails are most valuable when agents are making real-money tool calls, operating over long chains, delegating to sub-agents, or running in batch pipelines where volume is high and human oversight is limited. If your agent makes a small number of calls in a short session with a human in the loop throughout, prompt-level guidance may be sufficient. If it runs unattended, at scale, or with meaningful cost per action, runtime enforcement is worth considering.
Redlynr costs $0.001 per /run call, with no subscription. Your first 30 calls are free — no account or email required, just solve a short proof-of-work challenge to claim a trial token. Payment on the paid tier is settled in USDC on Base via x402.
A Python SDK is available via pip install redlynr and handles enforcement directly in the execution path. For other languages, the REST API requires no additional tooling.