A guardrail is a check that limits what an AI agent can accept, produce, or pass to another agent. Like a safety check before a file is written, it can stop a risky action before it is committed. That differs from filtering a response after the action has already happened. section 4.4 section 4.4.1
Observation is not enforcement. A handoff callback lets you inspect and log data moving between agents; use a guardrail when bad data must be blocked or corrected. section 4.3.3
Place checks at the boundaries where failure matters:
- Input: reject a disallowed request before the agent works on it. Output: reject an invalid or inadequate result before it is used. section 4.4.1
- Agent-to-agent transfer: check that data has the expected shape, excludes unnecessary context, and does not carry hostile instructions. Prioritize handoffs before writes, sends, or irreversible actions. section 4.4.3
- High-risk tool use: enforce applicable content policy and schema checks around the tool, not only at the conversation’s endpoints. section 11.1.5
Start with the cheapest check that expresses the rule. String comparisons, type checks, schemas, assertions, and business-rule predicates handle explicit constraints. Small classifier models can catch structured risks such as personal-information exposure or prompt injection. Use an LLM-based guardrail when the decision genuinely requires interpretation—for example, whether a plan is sufficiently useful or a tool call matches the user’s intent. Run cheaper checks first: extra model calls add latency and token cost, and a validating model can make the same mistake as the agent. section 4.4 section 4.4.1
Check a plan before passing it on
A planning agent produces a research plan for a filesystem agent. An output guardrail tests whether the plan is detailed enough and trips on failure. The flow can return feedback to the planning agent and retry, but it must cap attempts and surface a clear failure if none succeeds. In the OpenAI Agents SDK, input and output guardrails wrap an agent; they are not native handoff guards, so validate the upstream result before the transfer. section 4.4.3 section 4.4.2
Listing 4.11 10_agent_guardrails_retry.py
# only relevant code shown
print("Running...", goal)
research_agent.mcp_servers = [research_srv]
result = await Runner.run(research_agent, goal)
thinking_agent.mcp_servers = [thinking_srv]
final_output = result.final_output #1
max_retries = 3
for attempt in range(max_retries): #2
try:
result = await Runner.run(thinking_agent, final_output)
final_output = result.final_output.research_plan #2
break
except OutputGuardrailTripwireTriggered as output_tripped: #3
final_output = output_tripped.guardrail_result.output.output_info
if attempt == max_retries - 1:
final_output = "A research plan was not generated. Please try again #4
with a different goal." #4
filesystem_agent.mcp_servers = [fs_srv]
result = await Runner.run(filesystem_agent, final_output)
print(result.final_output)
Inspect the bounded retry loop, its tripwire exception handling, and its fallback when attempts are exhausted. section 4.4.3
Block an ungrounded answer
For a retrieval-augmented agent, a grounding agent checks whether an answer is supported by the available context. An output guardrail trips if it is not. The caller catches the exception and returns “No grounded answer available”; regeneration with feedback is another possible recovery path. section 7.3.3
Treat a tripped guardrail as a failure to handle, not as proof that every other output is safe. Test both passing and failing paths, bound retries, and use traces and evaluations to monitor quality, latency, and cost. section 4.5 section 7.6
