A Conversation property is a property type on the work item that holds a live two-way thread with someone outside the thunk: outgoing messages, incoming replies, and the history of that exchange. A Text or File property holds a static value. A Conversation property holds the thread.

Many workflows need more than a single outbound message. A support ticket may need clarification. An enrollment may be missing a document. A chat with an end user may span several steps. In each case the AI agent needs a structured place to conduct and track that exchange. A Conversation property provides it.

Each work item has its own instance of the property, so threads from different work items stay separate. A reply on one work item is never mixed with another.

This article is the shared concept and the settings that apply no matter which channel the property uses. For what is different on each channel:

To start new work items from email sent to the thunk's own address, that is a different path: Send requests to your thunk by email.

Add a Conversation property whenever the workflow has back-and-forth with someone outside the thunk: a customer, a supplier, a candidate, an end user in chat. Customer support, sales outreach, collecting documents, and a hosted chat app all need one.

The Conversation property is the whole thread. Every message the agent sends and every reply that comes back is recorded there, in one place, where people reviewing the work item can follow it. Do not add separate properties for the individual messages, drafts, or replies:

Properties for what the conversation produces (a meeting time, a decision, a collected document) stay separate.

A chat app already has a conversation input, often named EndUserConvo. You do not add a second one unless a later step truly talks to a different party.

Open the property in the workflow structure and set Channel. That is how the thread is delivered:

The conversational REST API uses the same conversation as the hosted Chat UI. Changing the channel does not always clear values you already saved for a previous channel.

These settings live on the Conversation property. They apply across channels unless a channel article says otherwise. Open the property in the workflow structure to set them.

Closed work item reply is not sent when the work item finishes. It is sent only if someone messages after the work item is already closed — for example after End conversation, after the workflow ran to its last step, or after inactive work was auto-finished. See Data retention (Auto-finish inactive work items).

Other settings appear only on some channels: Form responses and One-time form submissions on Email and Thunk Chat UI; Step error message on a chat app's end-user conversation. Those are in the channel articles.

Within step guidance (AI Instructions), the AI agent is directed to communicate through a named Conversation property. It uses the property to send messages, read incoming replies, update other workflow fields from those replies, and decide when the conversation has reached its concluding condition.

Keep step guidance focused on what to do in that step (when to send, what to ask, when to conclude). Put standing tone and language rules on the Conversation property as Message writing instructions.

The conversation must be listed under that step's Output properties for the AI to send on it. Listing it under Input properties lets the step read the thread without sending. On chat workflows, new steps include the end-user conversation in both automatically; remove it from Output properties on a step that should work quietly. See AI Instructions.

A step that uses a Conversation property typically has three parts in its guidance:

All three parts should be specified. If the concluding condition is missing or vague, the AI agent may close the step before a reply has been received and acted on.

The concluding condition should be a clear, verifiable statement. Four typical patterns:

All-requirements-met — used for document collection where partial compliance is unacceptable.

"Do not finish the step until we have all the information we need. When all required documents have been received and no gaps remain, the conversation and step can be concluded."

Single-response — used for simple information requests where one reply is sufficient.

"Wait for a response before proceeding. Once the candidate replies with a resume URL, record it and finish this step."

Time-bounded — used for clarification requests where the workflow should not block indefinitely.

"Wait for a clarifying response for up to 12 hours. If no response is received, proceed with the information currently available."

Explicit stop — used for high-stakes steps where the AI agent must not proceed until a specific event occurs, regardless of elapsed time.

"Do not finish this work. Wait for any incoming message that clarifies the error codes. Do not conclude until a response with requirements has been received."

A step that describes what to do when a reply arrives but does not explicitly instruct the AI agent to wait may result in the agent concluding after sending the initial message. An explicit directive prevents this. Sending messages must also allow waiting, and the conversation must be listed under that step's Output properties — otherwise the AI cannot wait for the reply even when the directions say to.

Not sufficient: "Email the candidate to request their resume." (No wait instruction — the agent may conclude after sending.)

When a step spans multiple rounds of back-and-forth, instruct the AI agent to maintain a running summary of the conversation. That gives the agent context for each new incoming message and gives humans reviewing the work item a clear picture of where things stand.

For example: "Always maintain a summary of the conversation as a brief record of where things are at. For example: 'Message sent to [party] on [date] requesting [items]. Response received on [date] with [attachments]. Gaps remain in [field].'"

Update the summary after every inbound message.

A work item can have more than one Conversation property, each a thread with a different party. A compliance review may require documentation from both the sender and the recipient of a transaction, with each party tracked in a separate Conversation property.

Each Conversation property is configured independently and tracked independently. Progress in one thread does not depend on the status of another. Handle each party's conversation in a separate substep so the concluding conditions and summaries stay distinct.

A hosted chat app and the conversational REST API need exactly one conversation input. Extra Conversation properties on that work item are for other parties, not a second chat channel. See Set up the hosted Chat UI for your thunk.

A custom tool can also send on a work-item conversation. See How to build a tool that uses a conversation.