A Conversation property is a property type in the workflow state schema that tracks a two-way communication thread between an AI agent and an external party. Where a Text or File property holds a static value, a Conversation property holds a live, evolving exchange: outgoing messages, incoming replies, and the full history of that thread, all associated with a specific work item.
Many workflows require more than a single outbound message. A support ticket may need clarification before it can be resolved. An enrollment application may be missing documentation that must be requested from a provider. A compliance review may require collecting identity documents across multiple rounds of back-and-forth. In each case, the AI agent needs a structured place to conduct and track that exchange. A Conversation property provides it.
This article covers the Email channel.
Email Channel Configuration
Each Conversation property configured with the Email channel tracks the conversation as a distinct email thread per work item. Four behavioral settings control what the AI agent is permitted to do within that conversation.
Form responses: When enabled, the AI agent can send structured forms embedded in outgoing emails to collect structured replies. This is useful when the response requires the external party to select from defined options rather than compose a free-form reply.
File attachments: When enabled, the AI agent can attach files to outgoing messages. Common uses include attaching a policy document, a letter draft, or a form for the recipient to complete and return.
AI messaging: When enabled, the AI agent can send messages and reply to incoming messages autonomously as part of step execution. This setting must be enabled for any step where the AI agent is expected to initiate or continue a conversation.
Disable replies: When enabled, the AI agent can send messages but any incoming replies are ignored. This configuration is appropriate for one-way notifications where no response is expected or acted upon. A confirmation sent after a case is closed is a typical example.
In addition to these four settings, each Conversation property can be configured with:
From Display Name: the sender name that external recipients see. If left blank, messages appear from the account's default display name. A team or role name (e.g., "HR Support Team", "Compliance Review") is appropriate in most cases, since messages are sent on behalf of a workflow rather than an individual.
Message Signature: text appended to every outgoing message sent through this property.
Instructing the AI Agent
Within step guidance (AI Instructions), the AI agent is directed to conduct communication through a named Conversation property. The agent uses the property to send messages, read incoming replies, update other workflow state fields based on the content of those replies, and assess whether the conversation has reached its concluding condition.
Because each work item maintains its own instance of the Conversation property, threads from different work items are kept separate automatically. A reply from one submitter is associated with their work item only, not with others in the same batch.
Structuring a Conversational Step
A step that uses a Conversation property typically has three parts in its guidance:
Initiating action: what the AI agent does first, such as sending a request or checking existing data before deciding whether to reach out.
Processing incoming messages: what the AI agent does when a reply arrives, such as verifying a document, extracting information, or updating fields.
Concluding condition: the explicit rule for when the step is allowed to close.
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.
Sending a Form
When Form responses is enabled, the step instructions can direct the AI agent to include a structured form in the outgoing email. The form is defined as a JSON schema directly in the step instructions:
{"type":"object","properties":{"Status":{"type":"string","enum":["Completed","Pending","Not Started","Cancelled"]}}}
Replace the property name and enum values with the options relevant to the workflow. The three-part step structure applies in the same way:
Initiating action: instruct the AI agent to send the email with the form attached, using the JSON schema above.
Processing incoming messages: specify how to map the submitted form values to workflow state properties. For example: "When the user submits the form, map the selected status directly to the
ActionItemStatusproperty."Concluding condition: base the condition on the form response received. For example: "Only finish this step if
ActionItemStatusbecomesCompletedorCancelled." This keeps the step open if the recipient submits a value that requires further action.
Concluding Conditions
The concluding condition is the most important part of a conversational step. It should be a clear, verifiable statement. Four typical patterns are:
All-requirements-met: used for document collection workflows where partial compliance is unacceptable. See the sample Thunks "Unblock Payment Transactions via Partner Review" and "Process Patient Support Program Applications" for examples of this pattern applied to multi-party document collection.
"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. See the sample Thunk "Manage Application Intake Process", where the extraction step holds open until the candidate replies with a resume URL.
"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. See the sample Thunk "Process Support Tickets", which waits up to 12 hours for a customer clarification before proceeding on available information.
"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. See the sample Thunk "Unblock Payment Transactions via Partner Review", where the partner requirements step will not conclude without a confirmed response from the partner.
"Do not finish this work. Wait for any incoming email that clarifies the error codes. Do not conclude until a response with requirements has been received."
Preventing Premature Closure
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, before any reply is received. An explicit directive prevents this.
✅ "Do not finish this step without receiving a response that includes the requirements."
✅ "Once the conversation is initiated, wait for a response. Do not complete the step."
❌ "Email the candidate to request their resume." (No wait instruction — the agent may conclude after sending.)
Maintaining Conversation State
When a step spans multiple rounds of back-and-forth, the step guidance should instruct the AI agent to maintain a running summary of the conversation. This 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: 'Email sent to [party] on [date] requesting [items]. Response received on [date] with [attachments]. Gaps remain in [field].'"
The summary should be updated after every inbound message.
Multiple Conversation Properties
A work item can have more than one Conversation property, each representing a thread with a different party. This is common in workflows where the AI agent must collect information from multiple counterparties independently. For example, 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. Each party's conversation should be handled in a separate substep so that the concluding conditions and gap summaries remain distinct.
One-Way Emails
For one-way notifications where no response is expected or acted upon, enable the Disable replies setting. This allows the AI agent to send through the Conversation property while ignoring any incoming replies.
Examples in the Sample Library
The following samples use Conversation properties to manage email threads within their workflows.
Manage HR Support Tickets: maintains separate conversation threads for employee clarification requests and escalations to department owners, each tracked independently per ticket.
Process Support Tickets: conducts a clarification conversation with the customer before drafting a response, with a time-bounded wait before proceeding on available information.
Process Patient Support Program Applications: manages parallel threads with the prescribing provider and the patient, each in a separate Conversation property on the same work item.
Unblock Payment Transactions via Partner Review: runs three independent conversation loops per transaction: one with the partner to confirm review requirements, one with the sender, and one with the recipient for document collection.
Manage Application Intake Process: emails candidates to request a missing resume and holds the extraction step open until a response is received.
Automating Expense Receipt Submission: contacts the submitter when a receipt fails the initial integrity check, waiting for a response before continuing.