OpenAI ChatKit Customer Support

A request, a tool action, and an updated itinerary.

The native request changed flight OA476 from seat 14A to 14C. The assistant confirmed the change, the itinerary and timeline updated, and the same conversation recovered its state after browser reload.

What was verified

All eleven declared expectations were met in the selected workflow.

1. One native browser submission carried the declared seat-change request.
2. Native model response and tool-call identities matched independent provider records.
3. The application stream completed with the declared assistant response.
4. The hosted ChatKit component displayed the declared assistant response.
5. One native change_seat call produced the expected output, state and streamed profile update.
6. Independent readback matched the updated thread profile, while the untouched thread retained its state.
7. The same conversation and updated seat appeared after browser reload within the same server lifetime.
8. Support and concurrent title requests stayed within six model attempts.
9. Exactly one native application tool execution was observed.
10. Provider output stayed within 65,536 bytes.
11. The observed model-to-terminal interval stayed within 120,000 milliseconds.

Coverage of this run

Seven established scenarios from an inventory of fifteen:

• Native chat submission
• Application provider invocation
• Completed stream and visible response
• Tool execution and application effect
• Per-thread state and exact readback
• Conversation reload within one server lifetime
• Declared invocation and output budgets

Eight scenarios were not evaluated. Embedding, retrieval, retrieved context and a separate database consequence probe were not applicable to this selected route. Multi-turn memory, application retry, broader authorization and semantic answer quality remain for further verification.

This baseline uses a Factory synthetic provider and in-memory state within one server lifetime. Production configuration, live-provider behavior, real airline writes and server-restart durability require separate verification.

Supporting evidence

Four original browser captures from the recorded run. Customer details belong to the reference application’s sample workspace.

Recommended next verification

Verify production and live-provider behavior.

Use an authorized production-equivalent environment with explicit provider and answer-quality criteria.

Extend state and authorization checks.

Define expected update, delete and alternate-user access behavior. Include server-restart durability in a separate verification.