A Follow-Up That Sounds Correct Can Still Violate the Rule
A visitor asks a library assistant for the nearest community legal-help clinic, then asks whether an appointment is guaranteed and whether their personal circumstances should be sent in advance. The assistant should remember the earlier location request, but it must not reinterpret a general referral as professional advice or expose personal details to a third party. The Responses API can chain turns using previous_response_id so the next response has earlier context. Context continuity, however, does not mean that the policy instruction for this turn remains in force. Build the referral system as a sequence of auditable requests, with a fresh safety and source policy applied to every turn.
Choose a State Pattern Before Writing Application Code
OpenAI documents several approaches: send the previous output items yourself, use a persistent Conversations API object, or pass previous_response_id to link the new response to its predecessor. A simple referral chat may use the linked-response approach when that meets the application’s retention and control requirements. A workflow that must edit history, delete selective material or operate without server-side state may need manual context management instead. Do not treat the three approaches as interchangeable. In a test plan, record which state mechanism was chosen, which identifier represents the current turn and what happens when a chain can no longer be resumed.
Resend Top-Level Instructions on Every Turn
The key documented distinction is that previous_response_id does not carry the previous response’s top-level instructions into the next request. If the library assistant must never confirm an external appointment or disclose a patron’s case notes, repeat those instructions in each call. Keep an application-owned policy version alongside the request; do not ask the model to recall the policy from a prior conversation. A practical instruction says that the assistant can suggest contact details from an approved directory but cannot represent a referral as an appointment. Confirm the requested response actually used the current instruction payload, not merely a previous response ID.
Treat Policy Changes as an Explicit Branch Point
Suppose a volunteer directory changes between the first and second turn. The prior response may include a clinic that no longer accepts walk-ins. Link the user’s request for convenience, but recheck the directory and any effective-date rule before repeating a phone number or hours. Include a current-source reference and a retrieved timestamp in your own application logs, keeping private user text out of general analytics. If the new edition contradicts the old answer, explain that the listing has been updated instead of quietly continuing the obsolete claim. A model remembering a fact does not establish that it is still true.
Separate Linked State From Durable User Records
Response objects are stored by default for a documented period, while Conversations API objects follow different persistence semantics. The store setting can disable default response storage for supported requests, but a developer should review what this means for state reuse before mixing it with previous_response_id. Do not promise that chaining automatically deletes earlier information. Put patron consent, case notes and appointment confirmations in an approved records system rather than assuming a model conversation is a secure case-management database. Choose a minimal retention period and verify the actual API behavior for your account and compliance obligations before processing sensitive inputs.
Compare Three Follow-Up Paths Without Inventing Results
Consider a training case with three hypothetical states. In the first, the application sends the new question with only its text, so it may lack the previous referral context. In the second, it supplies previous_response_id but forgets current top-level instructions; the conversation remains related, yet the rule enforcement is not intentionally renewed. In the third, it links the turn, resends the approved instructions and verifies the current directory entry. The third is the design target, not a measured model outcome. A comparison diagram should show the chain pointer, the separate instruction document and the independent lookup, rather than suggesting that one API flag guarantees accuracy.
Budget for the Whole Chain, Not Just the Last Message
OpenAI states that earlier input tokens in a chained response are still billed as input tokens. A short follow-up does not necessarily imply low cost when the chain has accumulated extensive prior content. Watch input and output usage, latency and context-window limits on the actual model. For long sessions, define an explicit process for resetting a chain or preparing a reviewed summary, while carrying over the rules separately. Do not silently drop effective dates or referral restrictions during condensation. A cost dashboard should distinguish model usage, directory lookup costs and human review effort instead of reporting an invented savings rate.
Test Failures, Forks and Ambiguous Questions
In a staging environment with invented patron identities, test a successful continuation, an invalid response ID, a policy revision and a user who changes topic. Also test a branch from an earlier response ID rather than the latest one. The application should be able to reconstruct which previous response each answer was linked to and identify the instructions used for that turn. When the chain cannot be resolved, the safe choice is to restart with necessary verified context, not fabricate a remembered conversation. Treat requests involving medical, legal or financial decisions as referrals to qualified human help, not automatic conclusions.
Release Only a Referral That Can Be Audited
A reviewer should be able to answer four questions: what the visitor asked in this turn, which prior response was linked, which current instructions were supplied, and which directory entry was verified. Store a minimally necessary audit record with timestamps and source versions; redact sensitive text. Log when the assistant explicitly says an appointment has not been booked. Add an escalation path for unavailable sources or uncertain eligibility. This approach preserves the convenience of multi-turn conversation while keeping policy, consent and factual verification independent of the model’s memory of earlier prose.
How We Research
For this guide, we reviewed the official product documentation on November 8, 2026: OpenAI conversation state guide, OpenAI migration to Responses guide, OpenAI Responses create API reference. We checked the named setting or feature against its published behavior, mapped the documented constraints to the specific hypothetical scenario, and reviewed whether the topic duplicated titles in the LabFin WordPress inventory or prior B0267–B0274 ZIPs. No authenticated vendor service was run; we did not perform a benchmark, observe real customer data, verify third-party rights or claim operational outcomes. All illustrated records and comparisons are teaching examples. Confirm product documentation and security requirements again before implementing a workflow in a real organization.
Frequently Asked Questions
No. OpenAI explains that prior top-level instructions are not carried forward by the response link. Send the current rules again on each request.
No. It preserves context, not directory freshness. Verify location, contact details and eligibility against the current approved source.
Not necessarily. OpenAI notes that earlier chain input tokens are still billed as input tokens. Compare actual metered usage.
Use it when a durable conversation object fits your application. Review its retention semantics and access controls separately from linked response IDs.
Restart with essential verified context and the current instructions. Do not invent an earlier conversation or claim a referral was completed.