Q&A: side discussions

These side questions help when you adapt the guardrail pattern to another project.

OpenAI Agents SDK and other frameworks

Q: Why use the OpenAI Agents SDK for this workshop?

We use it because it already has input and output guardrails. That lets us start with the built-in version before rebuilding the pattern ourselves. My usual preference is PydanticAI, but the OpenAI Agents SDK gives us the guardrail hooks we need for this workshop.

Q: Can the SDK use providers other than OpenAI?

Yes, when the provider exposes an OpenAI-compatible API. Configure the base URL and API key for that provider. Anthropic, Gemini, and Grok-style providers are examples of the kind of API compatibility to look for.

Input size and simple checks

Q: Should input size be handled as a guardrail?

You can check input size inside a guardrail, but I would do it before calling Runner.run. The input is already available in your application, and a length check does not need an LLM. If the input is huge, sending it to the model first means you pay for those tokens.

Q: Does every guardrail need to be an agent?

No. The workshop uses an LLM-based topic classifier because topic classification is fuzzy. Simple checks such as string length, missing fields, or a hard allowlist can run as normal Python code.

If your agent touches a database, use normal database safety practices outside the LLM too. Guardrails are not a replacement for parameterized queries, permissions, and input validation.

Output guardrail parameters

Q: Why does the output guardrail receive context, agent, and agent_output?

agent_output is the response we check in this notebook. The other values are useful when the policy needs more information. agent can give you the assistant instructions. context can include the user message, tool calls, previous interactions, and token usage.

Multiple guardrails

Q: Can a fully guarded agent have more than one input or output guardrail?

Yes. The SDK supports multiple input guardrails and multiple output guardrails. They run in parallel, and when one trips you can see which guardrail triggered and what result it returned.

Tool-based guardrail reliability

Q: Will the LLM call the guardrail tool always, or only when it is unsure?

The instruction says it should call the tool every time. In practice, an LLM can fail to follow the instruction or a user can try to trick it into skipping the tool. If you use the tool-based pattern, build an evaluation set that checks whether check_topic is called before answers.

This is why SDK-enforced guardrails are stronger. The framework runs them outside the model's choice loop.

Mock guardrails

Q: What is the role of mock_guardrail?

The mock functions isolate the async pattern from real LLM calls. mock_agent stands in for slow agent work, mock_guardrail always passes, and failing_guardrail always raises. That makes it easier to see how asyncio.gather, task creation, exceptions, and cancellation behave before using the real FAQ agent.

Parallel calls and cost

Q: If we run one LLM call for the guardrail and one for the actual task in parallel, are we wasting tokens?

It is a tradeoff between latency and cost. Parallel execution gives the user a faster experience when the guardrail passes. If the guardrail fails, the agent may already have started producing output, but cancellation stops it early instead of letting it finish.

If you stop execution midway, assume you may still pay for tokens already consumed. Check your provider's billing behavior if this matters for your application.

Continue with Part 9: Async primer for the async walkthrough.