The OpenAI Agents SDK ships free, in-process guardrails for agents you build on that SDK. ValGuard is a vendor-neutral OpenAI-compatible validation proxy with shared rule packs, shadow mode, and audit rows. Use both when you want SDK ergonomics and an org-wide enforcement boundary.
Quick answer
Choose OpenAI Agents SDK guardrails when one Python codebase owns the agent path and in-process checks are enough. Choose ValGuard when several services or languages must share policy, you need shadow → enforce without redeploying app code, auditors want rule IDs on every evaluation, or playbooks gate multi-step handoffs. Keep the SDK for tools and turns either way. Point its OpenAI client at ValGuard when you want the network gate. See ValGuard + OpenAI Agents SDK.
Verdict
SDK-native guardrails fit a single Agents SDK service you control end to end. ValGuard fits multi-service policy, packaged domain packs, and audit evidence without building that control plane yourself. They are not mutually exclusive.
What each is built for
OpenAI Agents SDK owns agent loops, tools, handoffs, and optional in-process input/output guardrails tied to that runtime.
ValGuard sits on the OpenAI-compatible path. Deterministic rules run on every completion before the next model, tool, or customer-facing action. Playbooks add a light step graph so rules apply at handoffs. It is not a general workflow engine.
Comparison table
| Capability | Agents SDK guardrails | ValGuard | Who wins |
|---|---|---|---|
| Form factor | In-process Python SDK | Hosted OpenAI-compatible proxy (+ Enterprise self-host) | SDK for one process; ValGuard for shared policy |
| Cost of guardrails | Included with the SDK | ValGuard plan | SDK when in-process is enough |
| Vendor neutrality | OpenAI Agents ecosystem | Any OpenAI-compatible client | ValGuard for non-SDK services |
| Shadow → enforce | Build logging and rollout yourself | Per-agent setting on every plan | ValGuard |
| Audit with rule IDs | Depends on your logging | Per-rule evaluation rows | ValGuard when auditors need named evidence |
| Domain packs (IDs, invoice math, leak patterns) | Custom code | Built-in packs | ValGuard |
| Orchestration handoffs | SDK handoffs | Playbooks with validation-gated routing | Depends on graph needs |
| Zero extra network hop | Yes (in-process) | No | SDK |
Where ValGuard is stronger
- Same rule IDs whether the client is Agents SDK, Node, or an n8n HTTP node.
- Shadow mode without redeploying the agent service.
- Domain and compliance packs you do not rewrite per language.
- Playbooks that block, re-ask, or escalate at handoffs with measured overhead in benchmarks.
Where OpenAI Agents SDK guardrails are stronger
- No vendor hop and no hosted dependency for checks that stay in one process.
- Tight loop with tools and handoffs you already wrote in the SDK.
- Free with the SDK when in-process policy is enough.
Cost and latency
SDK guardrails add CPU in your process. ValGuard engine packs are microseconds. HTTP path about 0.36 ms p50 with a mocked upstream. Model time is hundreds of milliseconds. Block/re-ask buffers the stream. See methodology.
Failure example
An agent proposes issue_refund with a schema-valid argument object. The SDK shape check passes. The amount exceeds the captured charge. Without a shared network gate, a second service that calls the same model can skip your in-process wrapper. With ValGuard on the path, a cross-field refund rule fails with a named rule ID before the tool runs.
Code
Point the SDK client at ValGuard (full wiring on the integration page):
import os
from openai import AsyncOpenAI
from agents import set_default_openai_client, set_default_openai_api
client = AsyncOpenAI(
base_url="https://api.valguard.ai/v1",
api_key=os.environ["VG_API_KEY"],
default_headers={"X-VG-Agent": "support-triage"},
)
set_default_openai_client(client, use_for_tracing=False)
set_default_openai_api("chat_completions")
Keep SDK-native guardrails for checks that must stay local. Put shared business rules on the ValGuard agent.
Choose OpenAI Agents SDK guardrails if
- One Python Agents SDK service owns the path
- You accept rewriting policy when you add Node or a canvas
- A network hop is unacceptable for that path
Choose ValGuard if
- Several clients must share the same packs
- You need shadow → enforce and rule IDs out of the box
- You want playbooks or OpenAI-compatible canvas integrations
Using both
Keep SDK tools and handoffs. Put ValGuard on the chat-completions path for org policy. Avoid duplicate retries: assign each failure action to one owner.
Objections
- Why pay if the SDK is free? Pay when policy must span services or you need packaged shadow and audit.
- Latency. Quote engine µs, proxy ms, and model ms together. Streaming caveat applies to block/re-ask.
- If ValGuard is down. The call fails; we do not silently skip rules. Trust.
- Data residency. SaaS by default; Enterprise self-host for VPC. No free local runtime.
- False positives. Shadow first.
- Misses. No rule signature means no catch; side effects off-path are out of scope.
FAQ
Do you replace the Agents SDK? No. Keep the SDK for agents and tools.
Are SDK guardrails enough alone? Often for one service. Rarely for org-wide packs.
Where is the how-to? ValGuard + OpenAI Agents SDK.
Related
Next step
Quickstart or the Agents SDK integration.