One Python package, five primitives, and a triage agent that hands off to specialists, blocks bad input, and remembers the conversation. Here is how to ship DevOps and security agents with the OpenAI Agents SDK without building a framework first.
See the workflow in action, tap through the tabs below:
// install and first run
python -m venv .venv source .venv/bin/activate pip install openai-agents export OPENAI_API_KEY=sk-your-key-here
// one front door, two specialists
from agents import Agent, Runner infra = Agent(name="Infra agent", instructions="Diagnose infrastructure and CI failures. Be concise.") sec = Agent(name="Security agent", instructions="Review findings for risk. Never run fixes.") triage = Agent(name="Triage agent", instructions="Route each request to the right specialist.", handoffs=[infra, sec]) r = Runner.run_sync(triage, "Our nightly build fails on a TLS error") print(r.final_output)
// stop bad input before it burns tokens
from agents import (Agent, GuardrailFunctionOutput,
input_guardrail, Runner)
@input_guardrail
async def no_secrets(ctx, agent, user_input):
text = str(user_input)
leaked = "AKIA" in text or "BEGIN PRIVATE KEY" in text
return GuardrailFunctionOutput(
output_info={"leaked": leaked},
tripwire_triggered=leaked)
ops = Agent(name="Ops agent",
instructions="Help with runbooks.",
input_guardrails=[no_secrets])
// read before you deploy
Tracing is on by default and can capture prompts and tool data. Turn that off for anything sensitive. Input guardrails only run on the first agent and output guardrails only on the last, so tool calls in the middle need tool guardrails. And never give an agent a write tool you would not give an intern. Full details in the article below.
What the OpenAI Agents SDK is
The OpenAI Agents SDK is a lightweight Python framework for building agentic apps, and OpenAI describes it as the production upgrade of its earlier Swarm experiment. It has very few abstractions: agents (a model plus instructions and tools), handoffs (delegation to another agent), guardrails (validation of inputs and outputs), sessions (memory across turns), and tracing (built in debugging). That small surface is the selling point. You can read the whole mental model in ten minutes. If you want to compare it with other options, our CrewAI tutorial and LangGraph tutorial cover the heavier end of the spectrum.
Quick setup
Install the package, set OPENAI_API_KEY, and run the Hello World from the official docs:
pip install openai-agents export OPENAI_API_KEY=sk-your-key-here from agents import Agent, Runner agent = Agent(name="Assistant", instructions="You are a helpful assistant") result = Runner.run_sync(agent, "Write a haiku about recursion.") print(result.final_output)
That is the entire boilerplate. No config files, no project generator. Use a virtual environment and keep the key in your secrets manager, never in the repo.
The mindset: small agents, sharp edges
Do not build one super agent with forty tools. Build a front door that routes, then narrow specialists with a handful of tools each. Narrow agents are cheaper, easier to test, and easier to trust. Treat every agent like a new hire: clear job description, limited access, and a supervisor (a guardrail) watching the risky moments. Start read only. Earn write access one tool at a time.
7 workflows worth building
1. Triage agent with handoffs
Handoffs are exposed to the model as tools, so a handoff to an agent named "Infra agent" appears as a transfer_to_infra_agent tool. Pass your specialists in the handoffs parameter and write routing rules in the triage instructions. Example prompt to the system: "Nightly build fails with a TLS handshake error on the artifact registry."
2. Agents as tools for a single owner
When you want one agent to stay in charge, skip the handoff and call a specialist as a tool with as_tool(). The orchestrator keeps the conversation and uses the specialist like a function, for example a "log summarizer" or a "CVE explainer".
3. Secret-leak input guardrail
Use @input_guardrail to scan the incoming message for key patterns before the model sees it. Return a GuardrailFunctionOutput with tripwire_triggered=True and the SDK raises InputGuardrailTripwireTriggered, halting the run. Run it in blocking mode when you want the check to finish before the agent starts, so a tripped guardrail burns no model tokens.
4. Tool guardrails for the middle of the run
Input guardrails fire only for the first agent and output guardrails only for the last. Anything happening mid-workflow needs @tool_input_guardrail and @tool_output_guardrail, which wrap function tools on every call. Use them to reject a tool call whose arguments contain a production hostname or a destructive flag.
5. Sessions for incident threads
Create SQLiteSession("incident_4821", "incidents.db") and pass it as session=session to Runner.run. History is stored and replayed automatically, so the on-call engineer can come back an hour later and ask "what did we rule out?" without re-pasting logs.
6. Read-only security review agent
Give a security agent function tools that only read: list open ports from a scan export, fetch a dependency report, summarize a finding. Its instructions say to recommend, never remediate. Pair it with an output guardrail that rejects any answer containing a shell command to run against production.
7. Trace-driven debugging
When an agent misbehaves, open the traces dashboard and read the timeline: which handoff fired, which tool ran, how long each step took. Most "the model is dumb" problems turn out to be a vague instruction or a tool returning noise.
Safety and gotchas
Tracing is enabled by default. That is great for debugging and risky for sensitive data. The docs describe three off switches: set OPENAI_AGENTS_DISABLE_TRACING=1, call set_tracing_disabled(True), or disable it per run in RunConfig. To keep tracing but drop payloads, set trace_include_sensitive_data to False (it defaults to true) or use the matching OPENAI_AGENTS_TRACE_INCLUDE_SENSITIVE_DATA environment variable.
Guardrail scope is narrow. Input guardrails only cover the first agent, output guardrails only the last. Do not assume a handoff target is protected by the front door's checks. Add tool guardrails wherever a tool can change something.
Handoffs share history by default. Use an input_filter on handoff() to control what the next agent sees, for instance stripping tool calls. Use on_handoff to log or pre-fetch data the moment a handoff fires.
Secrets and least privilege. Never paste credentials into prompts, keep tool credentials scoped, and require human approval for anything destructive.
Cost and usage tips
Route simple requests to a small model and reserve the large one for hard reasoning. Keep specialist instructions short and tool outputs trimmed, because every token of history is replayed on each turn. Use blocking input guardrails so junk never reaches the model, and cap the loop with a sensible turn limit. Check your current model pricing on the OpenAI pricing page before you scale up, since rates change.
FAQ
Is the OpenAI Agents SDK free?
The SDK itself is open source and installs with pip install openai-agents. You pay for the model calls and hosted tools you use through your OpenAI API account.
Handoff or agent as a tool?
Use a handoff when the specialist should take over the conversation. Use as_tool() when the main agent should stay in control and just borrow a capability.
How do I stop an agent leaking secrets into traces?
Disable tracing or set trace_include_sensitive_data to false, and add an input guardrail that blocks credentials from entering the run at all.
Your next step
Build the triage agent from the widget above, add one guardrail, and read your first trace. Want a guided path from this to production agents for DevOps and security work? Check out our courses.
