Follow the request, identify who owns each responsibility, and see what changes when a task needs tools, approvals, or recovery.
Start with the prerequisites, read the linked guides, then check whether you can explain the boundary in your own words.
Before you begin: Start here; no agent experience required.
You will be able to: Explain when you need a tool-using workflow and who should own its orchestration.
No. A focused model request may use Responses directly. Choose a managed session when the workload benefits from the managed harness and durable work.
Before you begin: Understand runtime ownership from step 1.
You will be able to: Distinguish configuration, conversation, one turn of work, and the machine executing commands.
No. Your application releases provider compute separately and preserves needed files before cleanup.
Before you begin: Know which application owns the session.
You will be able to: Choose functions, MCP, or environment capabilities and put credentials in the correct place.
No. Authenticate the user outside the model and authorize each tool operation against that server-owned identity.
Before you begin: Read the function-call contract; API access is needed only to execute the examples.
You will be able to: Create a session, handle a tool request, return a result, and recognize the root turn outcome.
No. Check the root turn's terminal outcome, then inspect its output and tool results.
Before you begin: Understand the successful tool loop from step 4.
You will be able to: Add approvals, durable delivery, and recovery without repeating a business action.
No. Delivery IDs and business-operation IDs solve different problems. Reconcile downstream effects and enforce operation-level idempotency.
Before you begin: Define the user outcome and unacceptable actions.
You will be able to: Compare configurations using task success, unsafe actions, latency, and total cost.
Not automatically. Inspect the bottleneck and compare a representative workload; delegation adds coordination and cost as well as potential parallelism.
Switch the environment, then inspect responsibilities, stored data, and credential boundaries. Optional components are choices for your workload, not an installation checklist.
Use application functions or service-origin remote MCP without a workspace. Built-in shell and environment-local capabilities are absent.
Select a component to trace its connections. A solid border marks your selection; dashed borders mark connected components.
Identity, product behavior, and delivery
Harness and durable agent resources
Business tools, data, and optional compute
Authenticate users, submit input, handle function calls, and return results.
Reference: OpenAI Agents API architecture ↗
Start with the downloadable read-only example, then follow the architecture decisions for policy answers, approved refunds, durable delivery, and evaluation. These are illustrated workflows; the explorer does not execute orders or payments.
Stage 1 of 5: Read an order
The answer depends on customer data, so a model-only answer is insufficient. A read-only function can look up the authorized order without a sandbox.
The model supplies an order ID. The server supplies identity and returns only the permitted status fields.
A request for another customer's order returns no order data.
Select a scenario and walk through it. Compare the user-visible status, your application's responsibility, and the actual API signal. This is an explanatory trace, not a live session.
Successful lookup · Step 1 of 4
Submitting the order request.
Authenticate the user and store the job-to-session association.
Create a session with initial input; watch its events.
Keep the distinction: Root completion plus valid tool output establishes this task's result; idle alone does not.
Read the implementation guideUI: Submitting the order request.
Application: Authenticate the user and store the job-to-session association.
API: Create a session with initial input; watch its events.
UI: Checking the order…
Application: Retrieve current required_actions and validate the pending function call.
API: Stream: agent.session.requires_action. Read turn_id and call_id from the action.
UI: Order found; preparing the answer.
Application: Check order ownership and return serialized status data.
API: Submit agent.session.input.tool_result with success: true and matching IDs.
UI: Your order has shipped.
Application: Inspect output and tool results; store the business outcome.
API: Root agent.session.turn.completed. Final text may arrive without deltas.
References: Events and items ↗ · Sandbox lifecycle ↗ · Function results ↗
Run a local example, or use the encyclopedia to explore a specific boundary.
Build the order example Browse all topics