Cycles

Appearance

← Blog

· Albert Mavashev · 6 min read

openaiagentsguardrailsbudget-controlruntime-authoritygovernance
Share Share

OpenAI Guardrails vs Runtime Budgets ​

A support agent built on the OpenAI Agents SDK has three useful controls in place.

An input guardrail rejects unsafe user requests. An output guardrail checks the final answer before it reaches the customer. A tool guardrail validates the arguments passed to issue_refund before that custom function tool executes.

Those controls are doing real work. They help keep content safe, outputs structured, and individual function-tool calls well formed.

Then the agent enters a retry loop. It calls a search tool 40 times, hands off to a specialist agent, calls the model again, and keeps trying to resolve the same case. Every individual call may still look valid. The problem is no longer whether a single argument object is acceptable. The problem is whether this tenant, workflow, or agent run should be allowed to spend more budget at all.

That is the difference between guardrails and runtime authority. Guardrails validate the thing being attempted. Runtime budgets decide whether the next action should still run, given what has already happened.

What OpenAI Agents SDK guardrails are for ​

The OpenAI Agents SDK documentation describes guardrails as checks that validate input or output around an agent run. Input guardrails can stop a request before more work happens. Output guardrails can inspect the final result before it is returned. Tool guardrails can wrap custom function tools and validate or block a function-tool invocation before or after execution.

That is useful for production systems. A finance assistant can reject a user request that asks for disallowed advice. A support agent can require a refund reason before a refund tool runs. A data assistant can validate that a tool result matches the schema the rest of the workflow expects.

But tool guardrails are intentionally scoped. They operate around custom function tools. The current OpenAI Agents SDK docs distinguish that path from hosted tools and built-in execution tools, which do not use the same tool-guardrail pipeline. The docs also note that guardrail tripwires can race with parallel work that has already started.

Those caveats are not defects. They are scope boundaries. Guardrails are still the right place for content validation, shape validation, and per-tool checks. They are not a shared budget ledger.

Runtime budgets answer a different question ​

Runtime budgets govern accumulated consumption.

They ask:

  • How much has this tenant already spent?
  • How much budget remains for this agent run?
  • How much risk has this workflow accumulated?
  • Is the next call cheap enough, safe enough, and still within policy?
  • If the action executes, how much usage should be committed back?

That question is broader than a single function-tool validation. A custom function-tool guardrail can inspect issue_refund({ amount: 25 }). A runtime budget can decide that the refund should not execute because the tenant has already exhausted its action budget, the run has crossed its risk allowance, or a parent budget delegated only enough authority for read-only support tasks.

The enforcement point matters. A budget decision has to happen before the expensive call, tool side effect, or delegated action starts. If the system waits until traces, logs, or dashboards update, the action has already happened.

The control map ​

ControlBest atNot enough for
Input guardrailRejecting unsafe or malformed user inputAccumulated cost after a run starts
Output guardrailChecking final responses before returnPreventing tool side effects mid-run
Tool guardrailValidating one custom function-tool callCross-run, cross-tenant, or hosted-tool budgets
Human approvalHandling exceptional high-risk actionsHigh-volume production paths where every action needs a fast decision
Runtime budget authorityDeciding whether the next action should proceedContent safety or response-quality evaluation

The point is composition, not replacement. A mature agent system usually needs all of these controls:

  • Guardrails for input, output, and custom tool validation.
  • Runtime budgets for pre-execution cost, risk, and action authority.
  • Observability for debugging, reporting, and tuning policy after the fact.

That same division is the core argument in Runtime Authority vs Guardrails vs Observability. The layers answer different questions, so forcing one layer to do every job creates blind spots.

Where this shows up in OpenAI Agents workflows ​

In OpenAI Agents SDK workflows, the budget boundary usually appears in four places.

Model calls. A single response may be cheap, but loops and handoffs can multiply model calls quickly. A model-call budget is often the lowest-friction starting point, especially when a team wants to cap spend before changing tool code.

Function tools. Custom function tools are where tool guardrails and runtime budgets often meet. The tool guardrail can validate shape and local policy. The runtime budget can reserve cost or RISK_POINTS before the tool executes, then commit actual usage when it completes.

Hosted or built-in tools. The current OpenAI tool-guardrail pipeline does not cover these surfaces the same way it covers custom function tools. That makes lifecycle-level budget governance more important if the workload uses hosted search, code execution, or other built-in capabilities.

Agent handoffs. Handoffs change who is acting, but they should not create unbounded authority. If a parent agent delegates work to a specialist, the delegated agent should receive bounded budget and bounded action authority, not a blank check.

Cycles uses the OpenAI Agents SDK RunHooks integration point to apply a reserve-commit lifecycle across model calls, tool invocations, and handoffs. The OpenAI Agents integration guide covers the implementation details; this post is about the architecture decision.

A practical rollout sequence ​

The safest first rollout is usually not "budget everything perfectly."

Start with the smallest boundary that would have prevented the incident you are worried about:

  1. Model-call budgets for runaway LLM spend.
  2. Tool budgets for repeated expensive or risky actions.
  3. Run budgets for loops and long-running workflows.
  4. Tenant budgets for SaaS isolation and customer-level spend control.
  5. Delegated budgets for handoffs between agents.

That sequence lets the team keep existing OpenAI guardrails in place while adding the missing budget boundary around execution. It also keeps policy explainable. If a call is denied, the operator can point to a specific exhausted budget instead of a vague safety failure.

The first-rollout guide goes deeper on choosing between tenant budgets, run budgets, and model-call guardrails. For teams already using OpenAI Agents SDK, model-call and tool budgets are often the fastest way to prove value because they attach to workflows the team already owns.

What to avoid ​

Avoid treating guardrails as a universal agent-control layer.

If a tool guardrail validates a refund request, it does not automatically enforce the tenant's monthly action budget. If an input guardrail blocks unsafe content, it does not automatically prevent a retry loop later in the run. If an output guardrail catches a bad final answer, it does not undo tool calls that already executed.

Also avoid replacing guardrails with budgets. Budgets do not decide whether text is safe, whether an answer is grounded, or whether a tool argument is semantically valid. They decide whether the next unit of spend, risk, or authority is still allowed.

The reliable pattern is layered:

  • Validate content and tool arguments with OpenAI Agents SDK guardrails.
  • Enforce cost, risk, and action limits with runtime budgets before execution.
  • Record the decisions and outcomes so operators can tune thresholds and explain actions later: scope, action, estimate, actual usage when available, ALLOW_WITH_CAPS or DENY reason, and trace or correlation ID.

Last updated: