A model can produce intermediate and final messages
A museum might use a Responses-powered application to draft a concise exhibit label and then request a curator-oriented revision. Some API responses expose an assistant message phase that labels an output message as commentary or final_answer. Those labels describe how the message functions in the model interaction; they are not editorial approvals. A deployment that extracts the first assistant text item and publishes it can select intermediate material instead of the final candidate. Define a rule that the public-facing handoff uses the intended final-answer message, followed by source verification and human review. An API message type alone is not permission to publish.
Read phase as part of the message structure
In the documented Responses output message schema, phase is an optional field that can be commentary, final_answer or null. The phase applies to assistant messages, not user messages. A consumer should inspect each output item’s type and role before interpreting its phase; not every output item is ordinary text. Tool calls, reasoning items and other structures should not be concatenated into an exhibit label by guesswork. The correct parser has explicit handling for absent phase values, rather than pretending a null value means the message is final. Keep the original item sequence available in the private workflow ledger.
Understand what commentary does not promise
Commentary can represent an intermediate assistant message that is not the final response to a user-facing task. Its presence does not authorize disclosing private reasoning, bypassing factual review or showing provisional text to visitors. In a hypothetical label workflow, a commentary message might indicate that a source lookup or clarification is underway; a later final_answer supplies a complete draft for editing. The application should not turn the commentary label into a public artifact name or use it as a quality score. Only expose text that meets the approved audience, data and content policy for the requested task.
Treat final_answer as a candidate, not a release approval
The final_answer phase tells the integration which assistant message is intended as the final answer in that model interaction. It does not verify an accession number, object date, donor consent or restoration claim. A label marked final still requires every factual assertion to be checked against the museum’s authoritative record. Place a separate editorial approval step after the phase-aware extraction. Where a response includes several output items, capture the relevant message ID or sequence and avoid appending unrelated tool material. This separation prevents a technical completion signal from being mistaken for the curator’s final sign-off.
Preserve phase during manual continuation
OpenAI’s reference notes that for models such as GPT-5.3-Codex and later, follow-up requests that resend assistant messages should preserve and resend the phase on those messages. Dropping the value can degrade performance. That instruction concerns the representation of previous assistant messages in a continued interaction; it is not a suggestion to fabricate phase values for old messages. If an application reconstructs conversation history manually, serialize the documented content and phase consistently. When an output lacks a phase, handle the absence explicitly instead of silently stamping every assistant item as final_answer.
Separate continuation state from a new prompt
Applications may continue a Responses interaction using supported conversation state mechanisms, or reconstruct a context from prior items when appropriate. Those are different integration designs. In the latter case, preserving the original assistant-message phase helps retain the distinctions the API exposed. Do not treat the field as a durable, independent conversation store or a replacement for the instructions that govern the current request. The project should still retain its own source references, approved task description and audience rules. If sensitive archival text would be resent, recheck data-minimization requirements before making the request.
Compare three message-handling outcomes
A useful teaching example has one assistant message labeled commentary, a later assistant message labeled final_answer and a reconstructed history where phase metadata was dropped. The first is intermediate, the second is the candidate for editorial review, and the third is a risky continuation representation that should be corrected. This is a logical comparison, not a measured claim about output quality. The diagrams avoid synthetic model scores and instead show what the parser keeps or loses. In production, record the actual message fields only within an approved audit environment and do not post hidden or private interaction content as screenshots.
Implement a phase-aware extraction rule
Begin by validating the API response and enumerating output items. For each assistant message, retain its phase, status where present, and content parts as structured data. Select only the appropriate final-answer content for the next editorial stage; treat commentary as a separate message class. If the response shape is unexpected or phase information is insufficient to identify the intended text safely, hold the job for inspection. The app should never assume that the first output array element is a complete, approved label. Keep a reference to the original request and the output selected for review.
Verify the source and user-facing audience again
An application can correctly preserve phase but still send an incomplete, misleading or confidential final label to the public. Require a source checklist and a review of redaction, permissions, accessibility and editorial style. A curator should be able to see which final-answer item they approved without needing access to unrelated intermediate material. If a later revision changes a source fact, create a new editorial revision and do not reuse the old sign-off. The output phase is one part of a traceable handoff; it is never a substitute for the archive’s evidence and approval workflow.
Audit changes to the continuation implementation
Before shipping a parser change, exercise it on synthetic conversations containing commentary, final_answer, null phase and non-message output items. Confirm that the application preserves phase only where the documented schema supports it, rejects unsafe ambiguous handoffs and does not publish intermediate content. Re-run the checks when moving between models or changing the conversation-state mechanism. This guide uses OpenAI’s API reference and fictional museum-label examples, not live model measurements. The useful outcome is clear separation of interaction semantics, editorial review and public publication—not a claim that any phase label proves an answer is true.
How We Research
We prepared this November 11, 2026 documentation-based guide using OpenAI Responses create reference; OpenAI Responses resource types; OpenAI Responses conversation-state guide. We cross-checked the exact API field or environment variable against the official reference, then examined practical distinctions such as scope, errors, authentication, version selection and application-side review. Scenarios use fictional museum records and synthetic labels; diagrams depict concepts rather than captured interfaces or measured service results. We did not access a private API project, execute production changes, inspect protected archive objects, or run GitHub Actions. Service behavior, permission boundaries and API versions can change; consult current primary documentation and your organization’s approved policies before implementing a workflow.
Frequently Asked Questions
OpenAI documents commentary and final_answer, with phase also permitted to be null or absent in the message representation.
No. Treat it as a different interaction phase; select the intended final answer and still apply the editorial release checks.
No. It labels an assistant output, not the factual correctness, rights clearance or publication status of the content.
The OpenAI reference recommends preserving and resending phases for relevant later-model continuation workflows when assistant messages are passed along.
Do not fabricate unsupported metadata. Handle missing fields explicitly and use a safe review path if the intended handoff cannot be determined.