Skip to main content
A conversation stores messages and the relationships between them. It gives a client enough information to rebuild an interaction after a refresh or reconnect.

​
Message content

Messages contain user, assistant, system, or tool content. Their typed parts can represent text, files, tool calls, tool results, citations, errors, and other structured data. In a support conversation, a user message might contain a question and an attached file. The assistant message contains the answer, while the associated run records the execution that produced it.

​
Branches and selection

Messages are connected through parent-message links. Editing an earlier prompt or regenerating an answer can create an alternative path through that history. Branch selection determines which path the client displays. This lets the client show one coherent thread while retaining the alternatives. A branch changes the selected conversation path; it does not replace the execution history of earlier runs.

​
Participants and read state

Participants identify the people and roles attached to a conversation. Read state records a reader’s position and unread count. These resources support collaboration without changing the message content. Project membership does not automatically grant access to every private conversation. Access control explains that distinction.

​
Input requests

An input request asks a person for structured information during execution. It has its own response lifecycle, separate from ordinary chat messages. For example, a support agent might need a person to supply missing information before continuing. The request remains part of the conversation state, while the run records that execution is waiting. The supported response and resume operations determine how work continues. See Runs and conversations for the complete interaction model and the Execution API for conversation operations.