OpenAI Agents SDK: Lightweight Production‑Ready Agent Framework

Full framework comparison: Guide to choosing a framework

What Is OpenAI Agents SDK

OpenAI Agents SDK is the official framework from OpenAI for building production AI agents. It provides a minimal, Python‑native abstraction for defining agents, equipping them with tools, handing off control to other agents, validating inputs/outputs with guardrails, and tracing every step – all with first‑class support for OpenAI’s API.

Unlike frameworks that introduce graph‑based or role‑based mental models, the Agents SDK keeps things simple: an agent is a system prompt plus a set of tools, plus optional handoffs. The Runner executes the agent loop, automatically handling tool calls, handoffs, and streaming. Built‑in tracing (via OpenTelemetry) shows you token usage, latency, and tool execution without any extra configuration.

from agents import Agent, Runner

research_agent = Agent(
    name="researcher",
    instructions="You search for accurate information.",
    tools=[search_tool]
)

writer_agent = Agent(
    name="writer",
    instructions="You write clear, concise articles.",
    tools=[]
)

triage_agent = Agent(
    name="triage",
    instructions="Route the user to the appropriate agent.",
    handoffs=[research_agent, writer_agent]
)

result = await Runner.run(triage_agent, "Research the latest AI trends.")

The SDK is open source (Apache 2.0) and designed to be provider‑agnostic (2026 versions support non‑OpenAI models). It has gained rapid adoption with approximately 22,000 GitHub stars (Python) plus a TypeScript port, and is used in production by hundreds of teams as the simplest path from idea to deployed assistant.

Why OpenAI Agents SDK Was Created

Before OpenAI released its official SDK (late 2024 / early 2025), developers building agents on top of OpenAI’s API faced the same repetitive tasks:

• Manual tool orchestration – Parsing tool_calls, executing functions, appending results, handling errors.
• Custom agent routing – Writing if statements or state machines to switch between different system prompts.
• Bespoke tracing – Logging timestamps, token counts, and tool calls by hand, then struggling to make sense of it.
• No standard for validation – Implementing input/output checks as extra steps, often forgotten or inconsistent.
• Fragmented handoffs – No built‑in way for one agent to delegate to another while preserving conversation context.

Each team reinvented the same wheel. OpenAI recognised that agent development shouldn’t require replicating the loop every time. The Agents SDK provides that loop, along with battle‑tested patterns for tool calling, handoffs, guardrails, and tracing – all production ready out of the box.

Key Features of OpenAI Agents SDK

Feature	Description
Agents	Simple abstraction combining instructions, tools, handoffs, and guardrails
Tool Calling	Automatic parsing, execution, and result injection for any async/sync function
Handoffs	Transfer control from one agent to another while preserving conversation history
Guardrails	Input and output validation that can reject or reroute before/after agent runs
Structured Outputs	Force agents to produce Pydantic‑validated JSON with the output_type parameter
Tracing	OpenTelemetry‑compatible traces showing agent runs, tool calls, handoffs, and token usage
Human‑In‑The‑Loop	Pause execution and request human input using InputGuardrail or manual interruption
Streaming	Stream token deltas and tool call updates via Runner.run_streamed()
Sessions	Persistent conversation history across multiple runs (optional, in-memory or custom)

The SDK is intentionally small – you can learn 90% of it by understanding Agent, Runner, tool, and handoffs. Everything else builds on those primitives.

How OpenAI Agents SDK Works

Execution flow in detail:

1. Call Runner.run(agent, user_input) – The Runner maintains the conversation state and executes the loop.
2. Input guardrails run – You can validate or modify the user input before the agent sees it. If a guardrail fails, the run can be rejected or handed off to a different agent.
3. Agent loop – The current agent’s instructions + conversation history are sent to the LLM. The LLM may respond with:
   • Final text – The loop ends and the result is returned.
   • Tool calls – The Runner executes the functions, injects results as tool messages, and continues the loop.
   • Handoff – The agent calls a special “handoff” tool that transfers control to another agent. The target agent continues the loop with the same conversation history.
4. Output guardrails – After the agent produces a final response, you can validate it. A failure can reject the output or trigger a handoff.
5. Tracing – Every LLM call, tool execution, handoff, and guardrail check is recorded as spans. You can export these to any OpenTelemetry backend (or view them on the OpenAI dashboard).

The entire loop is async‑first (though sync wrappers exist), making it easy to integrate with web frameworks and parallel tool calls.

Core Concepts

Agent

The Agent is the central abstraction – it holds instructions, tools, handoffs, guardrails, and output type. Agents are immutable (you create a new instance to change behaviour), which encourages declarative definitions.

from agents import Agent

greeting_agent = Agent(
    name="greeter",
    instructions="You respond to greetings in a friendly manner.",
    output_type=GreetingResponse,   # Pydantic model
    tools=[],                       # can be empty
    handoffs=[support_agent],       # optional handoff targets
    input_guardrails=[check_spam],  # run before agent
    output_guardrails=[check_toxicity]  # run after final output
)

Key parameters:

• instructions – System prompt (can be a string or a function that returns a string).
• tools – List of Tool objects (usually created via @tool decorator).
• handoffs – List of Agent instances or Handoff objects for customisation.
• output_type – Pydantic model – the agent is forced to produce JSON matching it.
• input_guardrails / output_guardrails – Validation callbacks.

Runner

The Runner orchestrates the agent loop. It is responsible for managing conversation state (sessions), executing tool calls, handling handoffs, and triggering guardrails.

from agents import Runner, trace

async def main():
    with trace("my_app"):               # optional – group related runs
        result = await Runner.run(
            starting_agent=greeting_agent,
            input="Hello, can you help?",
            session_id="user_123"       # optional session persistence
        )
    print(result.final_output)

Important: The Runner does not automatically persist conversation history across runs unless you provide a Session implementation. For production, you’ll want to implement a custom session store (e.g., Redis or database) or use the built‑in RedisSession.

Tools

Tools are functions that agents can call. The SDK automatically converts Python functions into OpenAI‑compatible tool schemas.

from agents import tool

@tool
async def search_web(query: str) -> str:
    """Search the web for information."""
    # your search implementation
    return f"Results for {query}..."

@tool
def calculate(expression: str) -> float:
    """Evaluate a mathematical expression."""
    return eval(expression)   # caution – only for trusted inputs

Features:

• Supports both sync and async functions.
• Automatically generates schema from type hints (Python 3.10+ typing).
• Can inject RunContextWrapper as first parameter for context access.
• Tool calls are executed in parallel when possible.

Handoffs

Handoffs are how one agent transfers control to another. They are implemented as special tools that the LLM can call. When a handoff occurs, the target agent takes over with the same conversation history.

from agents import Agent, handoff

support_agent = Agent(name="support", ...)

sales_agent = Agent(
    name="sales",
    handoffs=[handoff(support_agent, description="Escalate to support team")]
)

What handoffs preserve:

• Full conversation history
• The original user input
• The current session ID

What handoffs do not preserve:

• The internal state of the previous agent (agents are stateless)

For advanced use cases, you can customise the handoff by providing a on_handoff callback that runs before the target agent starts.

Guardrails

Guardrails are validation hooks that can reject or reroute a run. They are perfect for safety, content filtering, or early routing.

from agents import InputGuardrail, GuardrailFunctionOutput, RunContextWrapper

async def check_profanity(ctx: RunContextWrapper, agent: Agent, input: str) -> GuardrailFunctionOutput:
    if "badword" in input:
        return GuardrailFunctionOutput(
            output_info={"reason": "profanity"},
            tripwire_triggered=True,
            handoff_on_tripwire=safety_agent   # handoff instead of rejecting
        )
    return GuardrailFunctionOutput(tripwire_triggered=False)

greeting_agent.input_guardrails = [InputGuardrail(check_profanity)]

Two types:

• Input guardrails – Run before the agent sees the user input. Can reject the run outright or hand off to another agent.
• Output guardrails – Run after the agent produces a final response. Can reject the output or trigger a handoff (e.g., for sensitive topics).

Tracing

Tracing is built into the Runner – you get it for free. Spans include:

• agent.run – entire agent execution
• agent.llm_call – each LLM invocation
• agent.tool_call – each tool execution
• agent.handoff – handoff events
• guardrail – guardrail checks

You can export traces to any OpenTelemetry collector or view them in the OpenAI dashboard (if you set OPENAI_API_KEY and environment variable OPENAI_TRACES_ENABLED=1).

from agents import trace

with trace("customer_support", group_id="user_123"):
    result = await Runner.run(agent, "I need a refund")

Traces can be nested, grouped by user, and correlated with your application logs.

OpenAI Agents SDK Ecosystem

LLM models. The SDK works with all OpenAI models (GPT‑4o, GPT‑4o‑mini, o1, etc.). As of 2026, it also supports non‑OpenAI models (Anthropic, Google, local) via a compatibility layer, but the best experience remains with OpenAI’s API.

Responses API. The SDK uses OpenAI’s new Responses API (which unifies chat completions and assistants) for lower latency and built‑in tool streaming.

MCP Integration. While the SDK does not have native MCP client support, the community provides mcp-openai-agents and a CLI adapter (mcp-cli) that wraps any MCP server as a set of OpenAI‑compatible tools. For production, many teams use a lightweight proxy or the mcp-agent library.

Observability. OpenAI’s own trace dashboard is the default. For self‑hosted or multi‑provider deployments, you can configure the OpenTelemetry exporter to send traces to Datadog, Grafana, Jaeger, or Azure Monitor.

Deployment. The SDK is pure Python, works on serverless (AWS Lambda, Google Cloud Functions, Azure Functions), containers, and even edge runtimes (Cloudflare Workers via Pyodide). No heavyweight dependencies.

When to Use OpenAI Agents SDK

OpenAI Agents SDK is the best choice for a wide range of applications where simplicity, production readiness, and OpenAI integration are priorities.

Single‑Agent Assistants (Chatbots, Copilots)

You have one primary agent with a few tools. Example: customer support bot that can look up orders, update tickets, and answer FAQs. The SDK’s minimal loop keeps latency low and token usage predictable.

Multi‑Stage Handoff Workflows

The user starts with a general triage agent that hands off to specialized agents (billing, technical, sales) as needed. Handoffs preserve conversation history, making the experience seamless.

Prototyping and Iteration

Because the SDK is simple, you can go from idea to a working agent in under 10 lines of code. This makes it ideal for hackathons, MVPs, and internal tools where speed matters more than exotic orchestration.

Teams Already Using OpenAI

If your stack is already built around OpenAI’s API (chat completions, embeddings, etc.), the Agents SDK feels like a natural extension. No new mental models, no dependency on LangChain.

Applications That Need Good Observability Out of the Box

Tracing works immediately. You see token usage per turn, latency per tool call, and handoff paths – everything you need to understand and optimise your agent in production.

When Not to Use OpenAI Agents SDK

Complex, non‑linear workflows. If your agent needs to loop back, retry based on intermediate results, or execute conditional branches that are not easily expressed as handoffs, you may need a graph‑based framework like LangGraph.

Multi‑agent collaboration where agents talk to each other freely. The SDK’s handoffs are one‑way – control transfers, but agents do not converse like in AutoGen or CrewAI group chat. For free‑form dialogue among several agents, CrewAI or Microsoft Agent Framework is more appropriate.

Deep enterprise orchestration with .NET/Java. The SDK is Python‑first (TypeScript port exists but is less mature). If your enterprise standardises on Java or .NET, Semantic Kernel or Microsoft Agent Framework is the better fit.

Scenarios that require very low‑level control over the loop. The Runner hides the loop details. If you need to inspect every message, modify state between turns, or implement custom retry logic, you may be better off using the OpenAI API directly plus your own loop.

When you need persistent long‑term memory across many sessions. The SDK’s sessions store conversation history but not vector memory or knowledge bases. For RAG or persistent user memory, you’ll need to build that layer yourself.

OpenAI Agents SDK Learning Path

The handbook provides a structured series of guides to take you from zero to production.

Core Concepts

/frameworks/openai-agents-sdk/core-concepts/

Learn:

• Agent, Runner, and the execution loop
• Sessions and conversation persistence
• Streaming and async patterns

Tool Calling

/frameworks/openai-agents-sdk/tool-calling/

Learn:

• @tool decorator and type hints
• Parallel tool execution
• Best practices for tool design
• MCP integration via community adapters

Handoffs

/frameworks/openai-agents-sdk/handoffs/

Learn:

• Simple handoffs and custom handoff logic
• Handoff callbacks (on_handoff)
• Preserving state across handoffs

Guardrails

/frameworks/openai-agents-sdk/guardrails/

Learn:

• Input guardrails for safety and routing
• Output guardrails for content validation
• Handoff on tripwire

Observability

/frameworks/openai-agents-sdk/observability/

Learn:

• Enabling and interpreting traces
• Exporting OpenTelemetry to your own collector
• Grouping traces and adding custom spans

Production

/frameworks/openai-agents-sdk/production/

Learn:

• Deploying to serverless, containers, or edge
• Rate limiting, retries, and error handling
• Cost optimisation (caching, smaller models)
• Custom session stores (Redis, PostgreSQL)

OpenAI Agents SDK vs Other Frameworks

Framework	Primary Model	Best For	Learning Curve	Production Readiness
OpenAI Agents SDK	Single‑agent loop with handoffs	Simple assistants, handoff workflows	Low	Excellent
LangGraph	Graph state machines	Complex branching, loops, persistence	Steep	Excellent (with LangSmith)
CrewAI	Role‑based crews	Structured multi‑agent teams	Moderate	Good (for internal tools)
AutoGen	Conversational dialogue	Open‑ended multi‑agent discussion	Moderate	Maintenance mode
Semantic Kernel	Plugin‑based kernel	Enterprise .NET/Java, deep Azure	Steep	Excellent

OpenAI Agents SDK vs LangGraph

LangGraph gives you a graph with explicit nodes, edges, and persistent state. OpenAI Agents SDK gives you a linear loop with handoffs.

• Choose OpenAI SDK when your workflow is a sequence of tasks or a simple triage‑and‑delegate pattern. Handoffs are enough, and you don’t need cycles, checkpoints, or parallel branches.
• Choose LangGraph when you need fine‑grained control over state, loops, conditional routing, or durable execution across restarts.

OpenAI Agents SDK vs CrewAI

CrewAI organises agents into crews with roles and sequential task execution. The OpenAI SDK treats agents as stateless, handoff‑capable units.

• Choose OpenAI SDK when you want a single, primary assistant that can delegate to specialists on request. The mental model is closer to a human manager.
• Choose CrewAI when you have a fixed pipeline of tasks (research → write → edit) and each agent has a clear, unchanging role.

OpenAI Agents SDK vs AutoGen

AutoGen (now in maintenance mode, succeeded by Microsoft Agent Framework) focuses on multi‑agent conversations where agents freely exchange messages. OpenAI SDK focuses on controlled handoffs.

• Choose OpenAI SDK when you need a lightweight, production‑ready assistant with handoffs. Handoffs are simpler and easier to debug than free‑form conversation.
• Choose Microsoft Agent Framework (successor to AutoGen) when you need agents to debate, negotiate, or brainstorm – situations where handoffs are too rigid.

OpenAI Agents SDK vs Semantic Kernel

Semantic Kernel emphasises plugins, planners, and cross‑language support. OpenAI SDK emphasises minimal Python‑first agents.

• Choose OpenAI SDK when you are a Python shop and want the fastest path from idea to working assistant with built‑in tracing.
• Choose Semantic Kernel (or Microsoft Agent Framework) when you need Java/.NET support, deep Azure compliance, or integration with enterprise systems.

Common OpenAI Agents SDK Use Cases

AI Customer Support Agent

A triage agent that hands off to billing, technical support, or sales agents based on user intent. Each specialist agent has tools to query the CRM, create support tickets, or process refunds. Guardrails check for profanity or off‑topic questions.

Internal Knowledge Assistant

An agent that queries internal documentation (via RAG tool), answers employee questions, and hands off to a human escalation agent when the question is too sensitive or outside its knowledge.

Research Assistant

A researcher agent with web search and summarisation tools. After gathering information, it can hand off to a writer agent that produces a report. The writer may hand off to a fact‑checker agent for validation.

Workflow Automation Agent

An agent that processes user requests, calls internal APIs (e.g., create Jira ticket, send Slack notification), and confirms completion. Handoffs route different types of requests (incident vs feature request) to different sub‑workflows.

Productivity Assistant (Calendar, Email, Tasks)

An agent with tools to read calendar, send emails, and manage to‑do lists. Uses guardrails to validate that it never schedules meetings for weekends or sends emails to unauthorised recipients.

Common Beginner Mistakes

Overusing Handoffs

Beginners sometimes create a handoff for every small shift in topic, leading to “handoff churn” where the user is passed between agents without achieving anything. Each handoff adds latency and consumes tokens for the handoff prompt.

Recommendation: Use handoffs only when the specialised agent has a distinct set of tools or instructions that the current agent cannot use. For simple changes in conversation tone, just continue with the same agent.

Ignoring Guardrails

Without guardrails, agents can produce harmful outputs, leak sensitive information, or waste tokens on off‑topic requests. Many teams only discover the need for guardrails after a production incident.

Recommendation: Always add at least an input guardrail that checks for disallowed topics (e.g., PII, offensive language) and an output guardrail that validates structured output matches expected schema.

Poor Tool Design

Tools that are too broad (e.g., execute_python_code) or too slow (e.g., calling a 2‑second API) degrade user experience. Also, missing error handling in tools can cause the agent to loop forever or crash.

Recommendation: Keep tools focused, idempotent, and fast. Add retries and timeouts inside tools. Use the RunContextWrapper to pass per‑run state (e.g., user ID) without making it a parameter.

Lack of Tracing in Development

Developers often skip tracing during development, assuming they will “add it later”. When production issues arise, they have no visibility into what the agent actually did.

Recommendation: Enable tracing from day one – even in local development. Set OPENAI_TRACES_ENABLED=1 and optionally export to a local Jaeger instance. It costs nothing and saves hours of debugging.

Missing Structured Outputs

For any agent that produces data to be processed by another system, not using output_type leads to fragile string parsing and inconsistent formats.

Recommendation: Use output_type with a Pydantic model for every agent whose output is consumed by code. The LLM will generate JSON that validates against the model – no parsing bugs.

Assuming Sessions Persist Automatically

The Runner does not automatically persist conversations across runs unless you pass a session_id and provide a session store. Many beginners are surprised when the agent forgets the conversation after the script ends.

Recommendation: For production, implement a custom session store (e.g., RedisSession) or use the built‑in FileSession for development.

Best Practices Overview

Keep agents focused. Each agent should have a single responsibility and a small set of tools. If an agent’s instructions exceed a paragraph, consider splitting it.

Use structured outputs. Always define output_type for agents that produce machine‑readable data. It eliminates parsing bugs and improves reliability.

Design handoffs to be explicit. Give each handoff a clear description (e.g., “Transfer to billing agent for payment issues”). The LLM uses these descriptions to decide when to hand off.

Validate tool inputs and outputs. Use guardrails or explicit checks inside tools to prevent invalid data from reaching your backend.

Enable tracing in every environment. Set up OpenTelemetry export to a central collector (Datadog, Grafana, etc.) so you can correlate agent runs with your application logs.

Implement a session store early. Even for prototypes, use FileSession so you can replay conversations when debugging.

Use smaller models for routine agents. Not every agent needs GPT‑4o. Use GPT‑4o‑mini for classification, tool routing, and simple responses. Save the larger models for complex reasoning.

Set reasonable timeouts. The Runner does not enforce timeouts by default. Use asyncio.timeout or a custom wrapper to avoid hangs.

OpenAI Agents SDK and Modern Agent Development

OpenAI Agents SDK + MCP

The SDK does not include a native MCP client, but the community has built lightweight bridges. The recommended approach uses mcp-cli (or mcp-openai-agents) to expose MCP servers as a set of OpenAI‑compatible tools:

npx @modelcontextprotocol/mcp-cli expose weather-server --port 8000

Then your agent can call the exposed HTTP endpoints as normal tools. For full MCP client support, consider using LangGraph or Semantic Kernel, or wait for an official integration.

OpenAI Agents SDK + Human‑In‑The‑Loop

You can implement human approval by using an input guardrail that pauses the run and waits for external input. Or use Runner.run_streamed() and manually handle an “approval required” tool.

@tool
async def request_approval(action: str) -> str:
    """Request human approval for an action."""
    # Custom logic: store the action, wait for webhook, return yes/no
    return "approved"

More sophisticated patterns (breakpoints, state editing) require a graph‑based framework like LangGraph.

OpenAI Agents SDK + Production Monitoring

Export OpenTelemetry traces to your existing observability stack. Example with Datadog:

from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace import TracerProvider

provider = TracerProvider()
provider.add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="...")))
trace.set_tracer_provider(provider)

Then use the agents SDK normally – all spans will be exported.

FAQ

1. What is OpenAI Agents SDK?

It is OpenAI’s official Python framework for building production agents with built‑in tool calling, handoffs, guardrails, and tracing.

2. Is OpenAI Agents SDK open source?

Yes, it is Apache 2.0 licensed. The source is available on GitHub under openai/openai-agents-python.

3. Is it production‑ready?

Absolutely. It is used by OpenAI internally for customer‑facing assistants and by hundreds of external teams. The SDK is built on the same API that powers ChatGPT and the Assistants API.

4. Does it support MCP (Model Context Protocol)?

Not natively, but community adapters exist (mcp-openai-agents, mcp-cli). For native MCP, consider LangGraph or Semantic Kernel.

5. How do handoffs work?

Handoffs are special tools that, when called, transfer control to another agent. The target agent continues the conversation with the same history.

6. How are guardrails used?

Guardrails are async functions that validate input (before agent runs) or output (after agent finishes). They can reject the run or trigger a handoff.

7. Can I use non‑OpenAI models?

Yes, as of 2026 the SDK supports custom model clients (e.g., for Anthropic, Google, local). However, built‑in tracing and tool calling work best with OpenAI.

8. Is there a TypeScript version?

Yes, @openai/agents (beta) provides TypeScript/JavaScript support with similar concepts.

9. How do I persist conversation history?

Provide a session_id to Runner.run() and implement a custom session store (e.g., RedisSession) or use the built‑in FileSession for prototyping.

10. Does it support streaming responses?

Yes, use Runner.run_streamed() to get an async iterator of tokens and tool call updates.

11. What is the difference between handoffs and tool calls?

A tool call performs an action (e.g., search, calculation) and returns to the same agent. A handoff transfers control to a different agent, which continues the conversation. Handoffs are a special type of tool.

12. Can agents run in parallel?

The Runner executes tool calls in parallel when the LLM requests multiple tools at once. However, multiple agent runs (different sessions) are independent and can be run concurrently using asyncio.gather.

13. How do I debug an agent run?

Enable tracing (OPENAI_TRACES_ENABLED=1) and view spans in the OpenAI dashboard or export to Jaeger. You can also print the result object, which contains the conversation history.

14. What is the output_type parameter?

It forces the agent to produce JSON that matches a Pydantic model. The Runner automatically validates and parses the output. This is the recommended way to get structured data from an agent.

15. How does the SDK compare to the Assistants API?

The Assistants API is a managed service with file search and vector stores. The Agents SDK is a lightweight framework that runs on your infrastructure. The SDK gives you full control and lower latency, while the Assistants API handles persistence and retrieval for you.

16. Is there a cost for using the SDK?

The SDK itself is free and open source. You pay only for OpenAI API usage (tokens) and any infrastructure you run.

17. Can I use the SDK with Azure OpenAI?

Yes. Configure the OpenAI client with base_url and api_key pointing to your Azure OpenAI endpoint. The SDK is API‑compatible.

18. What are the limitations of handoffs?

Handoffs are one‑way and cannot be “returned” automatically. Also, handoffs do not preserve tool state across agents (agents are stateless). For two‑way collaboration, you need a multi‑agent framework.

19. How do I validate tool arguments?

Use Pydantic type hints in the tool function. The SDK will validate types (e.g., int, str) before calling your function. For custom validation, check inside the tool and raise an exception.

20. When should I choose OpenAI SDK over LangGraph?

Choose the OpenAI SDK when your workflow is mostly linear (or a simple triage → handoff pattern) and you want the fastest path to production with great tracing. Choose LangGraph when you need complex branching, loops, persistent checkpoints, or human interruption at arbitrary points.

Conclusion

OpenAI Agents SDK is the simplest production‑ready framework for building agents on top of OpenAI’s API. It replaces hundreds of lines of manual orchestration code with clear, tested abstractions: Agent, Runner, @tool, handoffs, guardrails, and tracing.

Core strengths to remember:

• Minimal learning curve – you can build your first agent in minutes.
• Production‑grade tracing out of the box – no vendor lock‑in.
• Handoffs provide a clean way to delegate to specialised agents.
• Guardrails make your agent safe and reliable.
• Works seamlessly with OpenAI’s API, and supports other providers with minor config.

When to reach for this framework:

• You need a single‑agent assistant or a simple triage‑and‑handoff workflow.
• You value simplicity and production readiness over exotic control flows.
• Your team is already comfortable with Python and OpenAI.

When to look elsewhere:

• You need graph‑based branching, loops, or checkpoints → LangGraph.
• You need role‑based multi‑agent teams → CrewAI.
• You need free‑form multi‑agent conversations → Microsoft Agent Framework.
• You need Java or .NET enterprise support → Semantic Kernel.

Start building today:

• Core Concepts: Agents and Runner
• Tool Calling
• Handoffs
• Guardrails
• Observability
• Production Deployment

Compare with other frameworks:

• Full Framework Comparison
• LangGraph Guide
• CrewAI Guide
• AutoGen Guide
• Semantic Kernel Guide

Additional resources:

• MCP Integration Guide
• Production Engineering

Last updated: June 2026