The agents SDK and assistants

The Responses API is the modern single endpoint. One call can use built-in tools (web search, file search, code interpreter), your own functions, and structured outputs. It is stateful when you want it (previous_response_id chains turns) and stateless when you do not.

The Agents SDK is a lightweight Python/TypeScript library that orchestrates multi-step agent loops on *your* machine, calling the Responses APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → (or Chat Completions) underneath. It adds the parts a real agent needs: a tool-calling loop, handoffs between specialized agents, guardrails, and tracing.

Rule of thumb: reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → for the Responses API for a single smart call with tools, and the Agents SDK when you need multiple steps, multiple specialists, or control flow you can debug.

When an agent beats a single call

A single model call is the right answer more often than agent demos suggest. Adding a loop adds latency, cost, and new failure modes. Use an agent only when at least one of these is true:

• The number of steps is unknown ahead of time. "Keep searching the docs until you can answer" is a loop, not a call.
• You need real tool use with feedback. The model calls a function, sees the result, then decides what to do next. A single call cannot react to its own tool output.
• You want specialization and routing. A triage agent inspects the input and hands off to a billing agent or a technical agent, each with its own instructions and tools.
• You need guardrails mid-flight. Validate input before the expensive model runs, or check output before it reaches a customer.

If your task is "classify this ticket into one of five categories," that is a single Responses call with structured outputs. Do not wrap it in an agent. If your task is "classify it, then look up the customer's plan, then either draft a refund or escalate," that is an agent.

Anatomy of an agents SDK agent

Three concepts carry most of the weight.

Tools are Python functions you decorate so the model can call them. The SDK reads your type hints and docstring to build the JSON schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → automatically. No hand-written schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →.

Handoffs let one agent transfer control to another. Under the hood a handoff is just a special tool call, but the SDK models it as a first-class concept so your routing logic stays readable.

Guardrails run alongside the agent. An input guardrail can reject "ignore your instructions" prompts before they cost a tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition →. An output guardrail can block a reply that leaks an internal note.

Everything is traced. The SDK emits a run trace you can view in the OpenAI dashboard, which is the difference between debugging an agent and guessing at one.

A concrete support triage agent

Here is the scenario. InboundInboundA strategy that attracts prospects organically via valuable content (blog, SEO, social) rather than interrupting them.View full definition → support messages arrive. A triage agent reads each one and routes it: billing questions go to a billing specialist that can look up an account, everything technical goes to a tech specialist. We add one input guardrail so obvious abuse never reaches a specialist.

First install the SDK and set your key:

Now the agent. Note how tools are plain functions and handoffs are just a list:

Walk through what happens at runtime. The guardrail runs first and clears the message. The triage agent reads it, recognizes a billing issue, and hands off to the billing specialist. The billing specialist calls lookup_account, sees Ada's status, and drafts a reply that points to the next step without promising money. You wrote zero JSON schemas and zero routing if statements: the model handles control flow, the SDK handles the loop.

To make the billing specialist actually act in the real world, you would replace lookup_account's fake dict with a call to your billing system. That is the only line that changes between this sketch and production.

Structured outputs are your seatbelt

Inside agents and inside plain calls, structured outputs force the model to return JSON that matches a schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → you define. Use a Pydantic model (as AbuseCheck above) or a JSON SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → and the model is constrained to valid output. This is what makes routing reliable: is_abusive is always a real boolean, never the word "maybe" buried in a paragraph.

Two practical rules:

• Make schemas small. Every required field is something the model must justify producing.
• Prefer enums over free text for categories. priority: "low" | "medium" | "high" beats a string the model might phrase ten ways.

The structured outputs guide covers the supported subset of JSON SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → and the strict mode that guarantees conformance.

Choosing your building block

You now have four real options. MapMapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → them to the job.

Custom GPT or GPT Actions. No code, lives in ChatGPT and the GPT Store, calls your APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → through Actions. Best when your users are inside ChatGPT and you want distribution, not a service you host. Covered in your earlier lessons; not an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → build.

Single Responses API call with tools. One smart turn. Web search, file search, code interpreter, your functions, structured output, all in one request. Best for "answer this well, once."

Agents SDK. Multi-step loops, specialist handoffs, guardrails, tracing, all running in your code. Best for orchestrated workflows you need to own and debug, like the triage agent above.

Assistants API. Legacy. If you are starting fresh, do not. If you have an existing Assistants integration, plan a migration to Responses.

A quick gut check: if you can describe the work as "one prompt, one answer," use a Responses call. If you catch yourself saying "and then, depending on what it finds," you want the Agents SDK.

Production notes that bite people

A few things the happy-path demos skip.

State is your problem with the Agents SDK. Unlike the Assistants APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, the SDK does not store conversation history on OpenAI's servers by default. You pass prior turns back in yourself, or chain Responses calls with previous_response_id. Decide early where conversation state lives.

Tools can loop forever. Set a maximum number of turns on your run so a confused agent cannot call tools in circles and burn your budget. The SDK exposes a max-turns setting on the runner.

Guardrails should be cheap. Run input guardrails with a small, fast model. The whole point is to reject bad input before the expensive agent runs, so a slow guardrail defeats itself.

Trace everything in staging. Open the traces in the OpenAI dashboard and read what the agent actually did. Most "the agent is dumb" bugs are really "my tool returned an unhelpful string" bugs, and the trace shows you instantly.

Handoffs are not free context. When the triage agent hands off, the specialist sees the conversation, but be deliberate about what you pass. Long histories raise cost and can dilute the specialist's focus.

Key Takeaways

• Use a single Responses API call for "one prompt, one answer." ReachReachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → for the Agents SDK only when steps are dynamic, tools feed back into decisions, or you need routing between specialists.
• Treat the Assistants API as legacy for new projects and build on Responses plus the Agents SDK instead.
• In the Agents SDK, model your system as small specialist agents connected by handoffs, with plain Python functions as tools. Let the model handle control flow; you handle the integrations.
• Wrap routing and classification in structured outputs with tight schemas and enums so decisions are reliable booleans and categories, not prose you have to parse.
• Set a max-turns limit, run guardrails on a cheap fast model, and read the traces in the dashboard before blaming the model.