From Threads to current conversation state
OpenAI's conversation guide explains that a text-generation request is independent unless an application supplies earlier state. A current application can manage history itself, include prior response output in a new request, or use a durable Conversations API object with the Responses API.
The Conversations API stores items such as messages, tool calls, and tool outputs. Its durable ID can be passed into later Responses API calls, including calls from another session, device, or job. This is useful plumbing, not a customer-support policy engine.
| Choice | What it provides | What you still own |
|---|---|---|
| Application-managed history | Full control over supplied context | Storage, privacy, truncation, retries, and identity mapping |
| Prior response output | A way to continue a multi-turn exchange | Preserving all required output items and deciding what to retain |
| Conversations API | Durable state that Responses can reuse | Authorization, retention choices, tool permissions, and customer outcome |
Do not migrate old Threads code by changing an object name and assuming the safety work is done. A support conversation can remember an earlier refund request and still be wrong about the current policy, the authenticated customer, or whether an order system actually issued anything.
Build support state around checks, not memory alone
Start with the state the next turn actually needs. A customer may need the current ticket, verified account identity, and the approved return policy. Do not inject unrelated history merely because it exists. It raises token cost and can expose context to the wrong interaction.
Then test representative cases:
- A normal follow-up where the earlier message changes what the customer means.
- A customer asking to change identity or account details mid-conversation.
- A request that cites an outdated policy or lacks required evidence.
- An ambiguous request that must hand off to a person.
- A tool request that must be held until a human approves it.
For each, inspect the context supplied to the model, the reply, any requested tool action, and the result in the system that owns that action. A stored conversation or fluent reply does not prove a refund, replacement, or account update happened.
Use eesel CLI to test a teammate conversation
OpenAI conversation state is infrastructure that your application manages. eesel is a ready-to-work helpdesk teammate. Its CLI operates the same teammate and workspace as the dashboard; it does not create OpenAI Conversations objects or run a Responses API request.
That distinction is useful when a support lead wants to test how an existing teammate handles an ongoing case. A lead can inspect the dashboard while a script or Claude Code, Codex, or Cursor reads CLI JSON and reports the selected teammate's sources, downloaded status, and standing instructions. The report is read-only: it must not connect accounts, change permissions, upload files, or enable automation.
With Node.js 18.17 or newer, confirm the workspace and explicitly select the teammate:
npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
TARGET_EESEL_AGENT="paste-agent-id-or-name-here"
npx @eesel/cli status --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli integrations --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli instructions --agent "$TARGET_EESEL_AGENT"
After a support owner approves a revised escalation instruction, preview the change with --dry-run before sending it. Before a chat test, contain or disable actions outside its scope. A held-action queue does not control an action that can run without a hold.
Create a new named conversation so the test does not inherit a real customer exchange:
npx @eesel/cli new --name "return-conversation-state-check" --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli chat "A customer first asked about a damaged parcel, then asks for a refund outside the normal window. State the approved evidence needed, do not promise a refund, and say when a human must decide." --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli approvals --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli activity --agent "$TARGET_EESEL_AGENT"
Review whether the reply used the right policy, respected the boundary, and made an honest handoff. CLI chat is billed work; setup and observation are free. If the test creates a held action, inspect it before approval. Confirm the final helpdesk or order-system result before telling a customer anything succeeded.
The Activity page lists recent teammate work with approved, rejected, and pending filters.
Choose the system that owns the job
Use OpenAI conversation state when you are building a custom experience and will own the history, authorization, tools, evaluation, and operations around it. Use eesel when the immediate job is operating a helpdesk teammate with your approved knowledge and workflows. The CLI makes that teammate available to people, scripts, and coding agents without creating a second workspace or separate dashboard copy.
Inspect support conversations before rollout
Try eesel if you want to inspect and test the support teammate before expanding customer access. Read the CLI guide for the documented commands.
Frequently asked questions
What happened to the OpenAI Threads API?
Threads were part of the Assistants API. For current work, OpenAI documents conversation state through the Responses API, the Conversations API, or application-managed history. Choose the approach that fits how long state should persist and what your system needs to inspect.
How does the Conversations API preserve state?
A Conversations API object has a durable identifier and stores items such as messages, tool calls, and tool outputs. Pass its ID to subsequent Responses API requests to persist state across sessions, devices, or jobs.
Can I manage conversation state myself?
Yes. A text-generation request is independent, so an application can supply prior messages and response output as input on the next turn. It must then own history selection, privacy, retries, token use, and correct customer identity.
What should I test in a support conversation?
Test normal follow-ups, identity or permission changes, outdated policy wording, missing evidence, a conversation that must hand off, and an action that must remain held. Inspect state and the final channel outcome separately.