← Integration Examples

OpenAI Agents / Local scripted evaluation

Let the agent request a booking. Verify it before confirming.

Keep your Agents SDK tool while an application-owned AnswerUp host authorizes the action, checks what happened and releases only the confirmation the current caller may receive. This restaurant example uses the real Agents SDK with a local scripted model and a sample business system. No OpenAI API key or real model call is needed. AnswerUp SDK downloads require approved private-preview access.

Run the local example

The verified setup uses Linux x86-64, Node 22.23.2, npm 10.9.8, tar and writable working and temporary directories. Installation needs npm registry access or a populated cache. No server, database, Docker or additional runtime is required. Other platforms and versions have not been verified.

The source includes the tool wrapper, business binding, protected host, setup scripts, README and complete Apache 2.0 LICENSE and NOTICE. Private SDKs are not included. Obtain Core 1.0.0-rc.1, Runtime 0.2.0-preview.5 and Actions 0.2.0-preview.8 through Package access, keeping the three .tgz archives together without extracting them.

Extract the source into an empty directory. You can optionally verify the archive with sha256sum -c openai-agents-source.tar.gz.sha256 before extraction.

mkdir openai-agents-source
tar -xzf openai-agents-source.tar.gz -C openai-agents-source
cd openai-agents-source

From the extracted directory, run these two commands in one terminal, replacing the SDK directory with yours:

node quickstart/setup.mjs /absolute/path/to/authorized-sdk
node quickstart/start.mjs

Setup verifies the three SDK hashes before copying them and runs locked npm ci --ignore-scripts. The runner compiles TypeScript, disables tracing and runs the evaluation with network access denied. Dependency installation is separate from that network guard. The selected Agents SDK is @openai/agents 0.18.0 with zod 4.2.1; the included README and lockfile list the complete selected versions.

A tool result is not business proof

The sample provider saves a reservation but loses its response. The protected tool returns UNKNOWN without a confirmation. A separately authorized host check still returns UNKNOWN until an independent read can verify the original effect. The same saved intent then yields a permitted COMMITTED result, even with a new Agents SDK tool-call ID.

The accepted evaluation reports UNKNOWN → UNKNOWN → COMMITTED → COMMITTED, with 1 provider mutation, 3 independent verifier reads and 0 recovery redispatches. Two local scripted model invocations exercise the real SDK; there are no real model calls or network attempts. This demonstrates tool-boundary behavior, not model reasoning or live-provider validation.

Only the protected write tool is registered. Recovery stays on a trusted host path, not an agent tool. The script uses stop_on_first_tool and displays the bounded tool result; it does not generate a free-form customer answer. See the included example/before.ts, example/booking-tool.ts and quickstart/evaluate.ts for the complete before/after and runnable code.

Connect your application's authority

Your application supplies authenticated identity, an authorized saved intent, business-input authorization, provider execution and an independent verifier. Keep tenant, request and action identity stable across retries; agent session and tool-call IDs are not business operation identity. Credentials and recovery authority must not come from model arguments.

The host checks canRecover separately and checks current canReadResult before releasing a result, including replay. Revocation can withhold a result without undoing an already admitted effect. Your application also owns protected storage, provider configuration and permission to deliver or later read saved messages. Loading agent history does not reauthorize its contents.

UNKNOWN means check the original effect with authoritative evidence, not blindly repeat the write or create a new intent. See provider and verifier responsibilities and UNKNOWN reconciliation.

What this evaluation covers

This is a synthetic-provider and synthetic-authentication evaluation with one trusted file writer and graceful close. The host stays alive throughout; this quickstart does not test a host restart. Process-local context tickets must be reissued through trusted ingress after a session restore.

The provider and sessions live in memory, and each run starts a new evaluation. Temporary state is removed on normal completion; forced termination may leave files that are not a supported restore path. This does not establish arbitrary-crash safety, multi-writer durability, exactly-once execution, production certification or real-model validation.

Host result authorization does not atomically protect later network delivery or subsequent agent prose. Use the included README for the complete host callback contract and recovery boundaries. The Apache 2.0 source license does not grant private SDK entitlement or change dependency terms in LICENSE and NOTICE. For the same business scenario over HTTP, see the Restaurant HTTP quickstart.