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.
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.
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.
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.
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.
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.
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. The highlighted component is selected; its connections are listed below.
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 guideReferences: 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