OpenAI Responses API and Agents SDK practice questions

Worked examples for OpenAI Responses API and Agents SDK

1. Question 1

   An operations team runs a high-traffic legal-research assistant on the OpenAI Agents SDK. The main agent is a large, expensive model that performs multi-step retrieval and reasoning. The team adds a small, fast model as an **input guardrail** whose only job is to decide whether an incoming request is within the assistant's remit. Which TWO statements correctly describe why placing this cheap check as a guardrail — rather than folding the same judgement into the main agent's instructions — is sound design?

   1. A. It stops out-of-scope requests before the expensive agent starts its multi-step work, avoiding the cost and latency of a full run that would have been rejected anywayCorrect answer

      Correct. Cost and latency savings are an explicit motivation for input guardrails in the Agents SDK: a cheap, fast model screens the request so the expensive agent is never invoked on work that will be thrown away.

   2. B. The scope decision is enforced deterministically outside the agent's reasoning, so it cannot be talked around by a crafted user message that reshapes how the agent reads its own instructionsCorrect answer

      Correct. Instructions are input to the model's reasoning and can be undermined by prompt injection or simple drift; a guardrail is a separate check on the run whose tripwire does not depend on the main agent choosing to comply.

   3. C. Registering the guardrail improves the main agent's reasoning quality, because the agent learns from the guardrail's rejections over successive runs

      Assumes guardrails train or improve the agent. Guardrails are runtime checks around a run; they do not update model weights or accumulate learning, and the main agent's reasoning ability is unchanged by their presence.

   4. D. The guardrail becomes an additional tool in the agent's toolset, which the agent invokes when it is unsure whether a request is in scope

      Conflates a guardrail with a tool. A tool is called at the agent's discretion during reasoning; a guardrail runs as part of the run's machinery whether or not the agent wants it, which is precisely what makes it a reliable control.

   5. E. Guardrails are documentation-level policy statements that record intent for auditors but leave the run's behaviour unchanged

      Treats guardrails as optional decoration with no runtime effect. A guardrail whose tripwire fires actually halts the run, so it changes behaviour rather than merely declaring intent.

   Explanation

   Two properties justify guardrails as a separate concern from the agent's instructions. First, economics: a cheap, fast guardrail model can reject an off-remit request before the expensive main agent begins a multi-step run, saving the cost and latency of work that would be discarded. Second, enforcement: instructions are consumed by the model's own reasoning and can be drifted away from or subverted by a crafted input, whereas a guardrail is evaluated outside that reasoning and its tripwire halts the run regardless of what the agent concludes. Guardrails do not train or otherwise improve the agent — they are runtime checks, not a learning signal — and they are neither tools the agent may elect to call nor inert policy documentation, since a tripped guardrail actively stops execution.

2. Question 2

   A team is describing the **role of a tool** in an OpenAI Agents SDK agent to new developers. They want to explain both what a tool contributes to the agent and what causes the run loop to stop. Which TWO statements are accurate?

   1. A. Tools give the agent the ability to take actions or reach information beyond what the model can produce from its own reasoning alone.Correct answer

      Correct: tools are the agent's hands — they let it call functions, query systems, or otherwise act on the outside world rather than only generating text.

   2. B. The loop ends when the model returns a final response instead of requesting another tool call, or when a configured limit on loop turns is reached.Correct answer

      Correct: the loop terminates on a final output from the model, and the SDK also guards against runaway loops with a maximum-turns safeguard.

   3. C. Each tool a developer adds permanently updates the model's weights so the capability is retained for future agents.

      Confuses adding a tool with fine-tuning. Tools are described to the model at request time and executed by the runtime; no training or weight update occurs.

   4. D. The loop always stops after exactly one tool call, since an agent may use at most one tool per run.

      The one-tool-per-run misconception. The loop is iterative by design — an agent can chain many tool calls across successive turns before producing its answer.

   5. E. A tool must be invoked directly by the end user in the chat message before the agent is allowed to use it.

      Assumes tools are user-triggered commands. The user supplies a natural-language request; deciding which tools to use, if any, is the model's job.

   Explanation

   Tools extend an agent past pure text generation by letting it perform actions and fetch information the model could not produce on its own, and the runtime executes them on the model's behalf. The agent loop keeps running as long as the model keeps requesting tool calls; it finishes when the model returns a final output, with a maximum-turns setting as a safety stop against unbounded looping. Registering a tool does not train or modify the model, an agent is not restricted to a single tool call per run, and users do not invoke tools directly — the model decides.

3. Question 3

   A developer new to the OpenAI Agents SDK is asked to explain, at a conceptual level, what an **agent** actually is in the SDK before writing any code. The team wants to know what an agent consists of and how its behaviour is determined at run time. Which statement best describes an agent in the OpenAI Agents SDK?

   1. A. A fine-tuned copy of the underlying model, produced by training on the developer's own examples so the new behaviour is baked into the model weights

      Confuses configuring an agent with fine-tuning. Creating an agent changes nothing about the model's weights — the instructions and tools are supplied as context and capabilities at run time, and the same base model can back many different agents.

   2. B. A model equipped with instructions that describe its role and task, plus an optional set of tools it may choose to call while it worksCorrect answer

      Matches the SDK's core abstraction: an agent is a model configured with instructions (its guiding prompt) and a set of tools it can invoke, and the model itself decides on each turn what to do next.

   3. C. A stored collection of documents and embeddings that the SDK searches to answer a user's question

      Confuses an agent with a retrieval knowledge base. A search or retrieval capability can be exposed to an agent as one of its tools, but the agent itself is the instructed, tool-equipped model, not the document store.

   4. D. A fixed script that specifies, in advance, the exact sequence of tools to invoke and the order in which their results are combined

      Confuses an agent with a hard-coded workflow or pipeline. The defining property of an agent is that the model — not the developer's predetermined ordering — decides which tool to call and when, so the path varies from run to run.

   Explanation

   In the OpenAI Agents SDK an agent is the central building block: a model paired with instructions that establish its role and task, optionally equipped with tools it may call. Behaviour emerges at run time from the model's own decisions rather than from retraining or a predetermined call sequence. Fine-tuning is a separate, weight-changing process and is not what defining an agent does; a document-and-embedding store is a retrieval resource that could be wrapped as a tool but is not the agent; and a fixed, developer-specified sequence of tool calls describes a static workflow, which is precisely what an agent is not, since the model chooses each next step.

4. Question 4

   An engineering team is building a report generator with the OpenAI Agents SDK. The workflow is fixed and known in advance: an outline agent produces a structured outline, a drafting agent expands it, and a reviewer agent scores the draft; if the score is below a threshold the draft goes back for one more revision. The team needs predictable step order, predictable cost and latency, and the ability to inspect each step's structured output in their own application code before deciding what runs next. Which **orchestration** approach best matches these requirements?

   1. A. Code-driven orchestration, where the application code invokes each agent in a fixed sequence, passes each step's structured output to the next, and branches on the reviewer's score to trigger a revision.Correct answer

      Orchestrating via code is the documented fit when the workflow is known ahead of time: it gives deterministic step order, inspectable structured outputs between steps, and ordinary control flow for the score-based loop, making cost and latency predictable.

   2. B. LLM-driven orchestration, where one agent equipped with handoffs decides at run time which agent goes next — this is the most predictable option because the model follows the order given in its instructions.

      Assumes model-chosen routing is deterministic. Letting the LLM plan the route buys flexibility for open-ended tasks, but the sequence, cost, and latency vary per run — the opposite of the predictability the team requires.

   3. C. Run the outline, drafting, and reviewer agents concurrently on the same input, since orchestration means multiple agents always execute in parallel over one automatically shared memory.

      Confuses orchestration with unconditional parallelism plus implicit shared state. Orchestration is coordination, not forced concurrency, and agents do not automatically share one memory; here each step also needs the previous step's output, so parallel execution is impossible.

   4. D. Abandon the multi-agent design and use one agent with all the tools attached, because chaining agents from application code does not count as orchestration.

      Wrongly restricts orchestration to model-decided routing. Coordinating agents from code is a first-class orchestration pattern, and collapsing three clearly separable roles into one agent discards the specialisation that keeps each step's instructions focused.

   Explanation

   The Agents SDK distinguishes orchestrating via the LLM — letting a model decide the route, typically through handoffs — from orchestrating via code, where the application decides which agent runs when. A workflow whose steps are known in advance, whose intermediate outputs must be inspected, and whose repetition is governed by an explicit score threshold belongs in code, which yields deterministic order plus predictable cost and latency. Leaning on model-chosen routing here would make the sequence vary run to run, forcing every agent to run in parallel over an assumed shared memory misreads orchestration as concurrency and ignores the data dependency between steps, and treating code-driven chaining as "not orchestration" would throw away useful role specialisation (OpenAI Agents SDK — Orchestrating multiple agents).

5. Question 5

   An architect is reviewing two candidate designs for a multi-agent document-processing system built with the OpenAI Agents SDK. In the first design, a coordinator agent inspects each incoming document and decides at run time which specialist should handle it, using the model's own judgement. In the second design, the application code always runs an extraction agent, then a validation agent, then a summarisation agent, in that fixed order, regardless of the document. Which statement most accurately characterises **orchestration** in a multi-agent system of this kind?

   1. A. Orchestration means the agents automatically share one common memory, so any agent can read the full internal reasoning of every other agent without anything being passed between them.

      This is the 'orchestration implies automatic shared memory' misconception. Coordination governs which agent runs and what context is handed to it; context reaches an agent because the design passes it along, not because a global memory is implied by using several agents.

   2. B. Orchestration removes the need for any single point of control, because each agent independently determines when it should activate and no component decides the overall flow.

      This is the 'orchestration eliminates a point of control' misconception. Something always decides what runs next — either a coordinating agent's decision or the surrounding application code — and both candidate designs in the scenario have exactly such a decider.

   3. C. Orchestration can be driven either by the model — letting an agent decide which specialist to delegate to — or by code that runs agents in a predetermined sequence, and both are legitimate patterns chosen according to how predictable the workflow must be.Correct answer

      Correct. The Agents SDK documents orchestration both via LLM decision-making and via deterministic code-driven flows such as chaining agents in a fixed order; the choice trades the model's flexibility against predictability, cost, and ease of evaluation.

   4. D. Orchestration means the specialist agents always execute concurrently on every request, with the framework reconciling their outputs after the fact without any explicit coordination step.

      This is the 'multiple agents always run concurrently without coordination' misconception. Running agents in parallel is one deliberate pattern among several, not the definition of orchestration, and any parallel results still need an explicit step that combines or selects among them.

   Explanation

   The OpenAI Agents SDK describes two complementary ways to orchestrate multiple agents: letting the LLM decide — an agent uses its judgement to delegate to the right specialist — and orchestrating via code, where the application chains agents in a deterministic order or otherwise fixes the flow. Model-driven orchestration buys flexibility for open-ended work, while code-driven orchestration buys predictability, lower cost, and easier evaluation, so both candidate designs are valid patterns rather than one being wrong. Coordinating several agents does not imply an automatic shared memory, does not abolish a decision point about what runs next, and does not mean every specialist fires concurrently on each request.

6. Question 6

   A team is building a customer-support assistant with the OpenAI Agents SDK. Billing questions require a strict refund policy, a payments-history lookup, and a cautious tone; technical questions require log-search tooling, a device knowledge base, and a diagnostic troubleshooting style. The team is deciding between one agent equipped with every tool and instruction set, versus a triage agent that **hands off** to a billing agent or a technical agent. Which statement best describes what the handoff design gives them that the single multi-tool agent does not?

   1. A. Each specialist owns its own instructions and its own narrowed tool set, and a handoff transfers control of the conversation to that specialist, so the model reasons within one focused role instead of arbitrating between two conflicting instruction sets and a large tool surface.Correct answer

      Correct. In the Agents SDK an agent is instructions plus tools plus guardrails, and a handoff passes control of the run to a different agent. Splitting clearly separable responsibilities keeps each agent's instructions coherent and its tool list small, which is exactly the case the SDK's handoff/triage pattern is designed for.

   2. B. A handoff is simply another tool invocation inside the same agent, so the only real difference is that the tool list is written in two files rather than one; the reasoning context and active instructions are identical either way.

      This is the 'a handoff is just another tool call in the same agent' misconception. Although a handoff is surfaced to the model in a tool-like way, its effect is a transfer of control: the receiving agent's own instructions and tools become the ones in force, which is not true of an ordinary tool call.

   3. C. The handoff makes the billing agent and the technical agent run concurrently on every user turn, and the orchestrator merges their two drafts into one reply, which is why quality improves.

      This is the 'handoffs mean parallel execution' misconception. A handoff transfers control to one agent; it does not fan the turn out to several agents whose answers are then merged. Parallel execution is a separate orchestration choice, not what a handoff means.

   4. D. Adding more tools to one agent is always the stronger design because tool descriptions are cheaper than extra agents, so the handoff only matters once the tool count exceeds the model's tool limit.

      This is the 'more tools always beats specialisation' misconception. The deciding factor is whether the responsibilities are separable and need different instructions and tone, not a raw tool count; a single coherent job is well served by one multi-tool agent, and conflicting jobs are not.

   Explanation

   In the OpenAI Agents SDK an agent bundles instructions, a tool set, and guardrails, and a handoff transfers control of the run from one agent to another. That makes handoffs the right fit when responsibilities are clearly separable and each needs its own instructions and narrowed tools — a billing specialist and a technical specialist — while one agent with many tools suits a single coherent job. Treating a handoff as an ordinary tool call misses that the receiving agent's instructions and tools become the ones in force; treating it as concurrent execution with merged drafts describes a different orchestration choice entirely; and judging the design purely by tool count ignores that the real problem is conflicting instruction sets, not the size of the tool list.

7. Question 7

   An online retailer's assistant, built with the OpenAI Agents SDK, starts every conversation with a **triage** agent. For a customer asking about sending back a jacket, triage performs a handoff to a returns specialist that has return-window instructions and shipping-label tools. Three turns later the same customer changes subject and asks whether their espresso machine is still under warranty — a topic the returns specialist has neither instructions nor tools for. The team wants to document how control moves in this system before designing the fix. Which TWO statements about handoffs in a multi-agent system are accurate?

   1. A. Once triage hands off, control is locked to the returns specialist for the remainder of the conversation, so reaching a different specialist requires starting a new session.

      The misconception that a handoff is a one-way, terminal transfer. Handoffs are not restricted to a single direction or a single hop — the agent currently in control can itself hand off, so routing can continue within the same conversation.

   2. B. The returns specialist can itself perform a handoff — for example back to the triage agent — so control can return when the request no longer matches its speciality.Correct answer

      Correct. Any agent can be configured with its own handoffs, including one back to a triage or router agent, which is the standard way a specialist releases a conversation that has drifted outside its scope.

   3. C. After a handoff both agents stay active and answer in parallel, and the framework merges their two replies into one response for the customer.

      The misconception that multiple agents in a system run concurrently with no transfer of control. A handoff moves control to one agent; it does not fan the turn out to several agents whose outputs are then combined.

   4. D. At any point in the run exactly one agent is in control, and that agent's instructions and tools govern the next step until another handoff occurs.Correct answer

      Correct. A handoff hands the conversation to another agent, which then takes over with its own instructions and its own tool set; the receiving agent stays in control until it hands off in turn.

   5. E. A handoff back to triage is simply the specialist calling triage as one of its tools and resuming its own work once triage replies.

      Conflates a handoff with using an agent as a tool. Calling another agent as a tool returns a result to the caller, which remains in control; a handoff gives up control entirely, so the specialist does not resume afterwards.

   Explanation

   A handoff lets one agent delegate a conversation to another agent, which then takes over with its own instructions and tools; control rests with exactly one agent at a time and moves only when a further handoff happens. Because any agent can be given its own handoffs, a specialist that finds the request outside its scope can hand control back to a triage or router agent, so routing continues within the same conversation rather than being a single one-way hop. The idea that a handoff permanently locks the conversation to the receiving agent contradicts that bidirectional capability; the idea that both agents then run in parallel and have their replies merged confuses handoffs with concurrent execution; and describing a handoff as a tool call misses the defining difference — calling an agent as a tool returns a result to a caller that keeps control, whereas a handoff surrenders it.

8. Question 8

   A team building an assistant with the OpenAI Agents SDK wants a mechanism that checks whether the text a user submits is on-topic before the main agent does any expensive work, and that checks the agent's final answer before it is shown to the user. They are deciding whether **guardrails** are the right mechanism for this. Which statement best describes the role guardrails play in an Agents SDK system?

   1. A. Guardrails supply the agent's instructions and reasoning strategy, so the quality of the agent's decisions is determined by which guardrails are configured.

      Confuses guardrails with the agent's own instructions/prompt. The agent's reasoning comes from its instructions and model; guardrails are separate checks layered around the run and do not drive how the agent thinks.

   2. B. Guardrails are advisory annotations used only for logging and evaluation dashboards; they record concerns but cannot change or stop what the run produces.

      Treats guardrails as optional decoration with no effect on behaviour. A guardrail that detects a violation trips and halts execution, so it materially changes the outcome rather than merely observing it.

   3. C. Guardrails are tools registered on the agent that the model invokes whenever it judges a safety check to be necessary.

      Conflates a guardrail with a tool the agent chooses to call. Guardrails are enforced by the framework around the run, not selected by the model — a misbehaving or manipulated agent could simply decline to call a tool.

   4. D. Guardrails are validation checks that run alongside the agent — inspecting the incoming user input and the agent's final output — and can immediately halt the run when a check fails.Correct answer

      Matches the documented purpose: input guardrails run on the user's input and output guardrails on the agent's final output, running in parallel with the agent, and a failed check trips and stops execution (Agents SDK — Guardrails).

   Explanation

   Guardrails in the Agents SDK are checks that run in parallel with the agent: an input guardrail validates what the user sent before the main work proceeds, and an output guardrail validates the agent's final answer, with a failed check tripping and halting the run. That makes them a control layer around the agent rather than part of how the agent reasons — they do not supply the agent's instructions or decision strategy, they are not passive logging annotations because a failed check stops execution, and they are not tools the model elects to call, since enforcement must not depend on the agent's own cooperation.