Where the OpenAI Agents SDK puts input and output guardrails relative to the agent loop

**Input guardrails fire before the agent runs.** They get the raw input (a user message or a handoff payload from a previous agent), run a check (LLM-as-judge, regex, classifier), and either pass or trip. A trip short-circuits the run; the agent never spends tokens. **Output guardrails fire after the agent produces its final response.** Not after every intermediate tool call, after the final response. They check the output and either pass or trip. A trip can: - Suppress the response (return a generic refusal). - Force a regeneration (try again with extra constraints). - Hand off to a remediation agent (escalate to a different role). **Both run as small parallel evaluations**, so latency cost only shows up on tripped paths. **Why framework hooks beat prompt instructions.** Prompt-based 'please refuse if X' is unreliable; a sufficiently determined adversarial input can talk an agent past its own instructions. A guardrail hook is deterministic Python that runs outside the agent's reasoning loop. The agent cannot reason its way past Python code; the code runs whether the agent wants it to or not. That distinction (framework-enforced versus prompt-suggested) is the practical reason for the SDK to expose guardrails as first-class hooks instead of leaving them to system-prompt discipline.

**Input guardrails run once, before the active agent processes the input.** They get the raw input (user message or handoff payload from a previous agent) and run a check, often an LLM-as-judge call but sometimes a regex or a classifier. If the check trips, the run short-circuits and the agent never spends tokens. Typical input checks: PII detection, policy-violating intent, jailbreak attempts, out of scope requests. **Output guardrails run once, after the agent produces its final response.** Not after every intermediate tool call (that would create unacceptable latency and false-positive cascades); after the final response only. If the check trips, three responses are available: suppress (return a generic refusal), regenerate (retry with extra constraints in context), or hand off to a remediation agent. Typical output checks: harmful content, factuality, format compliance, accidental data leakage. **Both run as small parallel evaluations** (the SDK runs them concurrently with relevant parts of the agent loop where possible). Latency cost is bounded: input guardrails add a fixed overhead on every request; output guardrails add overhead only on the final response path. Tripped runs save cost overall because they short-circuit token-heavy work. **Why framework hooks instead of prompt instructions.** Prompt-based safety ('do not respond if X') is talked-around. An adversarial input can be sufficiently persuasive that the agent ignores its own instructions, especially after a long conversation. A guardrail hook is deterministic Python that runs outside the agent's reasoning. The agent does not get a vote; the code runs. That deterministic boundary is the entire point of the guardrail abstraction; it is the difference between safety as aspiration and safety as enforced.