Post-Conversation Processing

Give an AI Assistant one additional LLM turn after a conversation ends to run final tool calls, and understand which tools are available post-conversation.

Post-conversation processing gives an AI Assistant one extra LLM turn after the conversation has ended. Instead of finishing when the caller hangs up, the assistant is invoked one final time to perform wrap-up work — sending a summary, filing a ticket, or updating an internal record — using the tools available to it.

Typical uses:

• Writing a call summary to storage or a record after the call ends.
• Filing an internal ticket or logging the outcome of the call.
• Any final data capture that should not keep the caller waiting on the line.

---

How it works

When the conversation ends, the platform injects a system message into the conversation (“The conversation has ended. You may now perform any post-conversation tasks.”) and runs one additional LLM turn. The model sees the full conversation history plus its configured instructions, and can call the tools that are available post-conversation. If a tool call returns results that warrant follow-up, the model can call further tools in sequence, up to a small fixed number of iterations, before the turn ends.

The model’s tool calls and their results are added to the conversation’s message history. The final text the model produces in this turn, if any, is not stored as a conversation message and is not delivered to anyone — the turn is for executing actions, not for producing user-facing output.

Enable it with the post_conversation_settings object on the assistant:

Field	Type	Description
post_conversation_settings.enabled	boolean	Whether the assistant runs a post-conversation turn after each conversation ends. Defaults to false.

POST /v2/ai/assistants
{
  "name": "repro-20260917-receptionist",
  "instructions": "After the call, file a summary ticket.",
  "post_conversation_settings": { "enabled": true },
  "enabled_features": []
}

Post-conversation processing is a beta feature and is voice-only: the post-conversation turn runs for phone-call conversations.

---

Tool availability post-conversation

Not every tool the assistant has during a call is available once the conversation has ended.

Available post-conversation:

• Webhook tools, function tools, and other HTTP-backed tools attached to the assistant.
• Built-in data tools such as knowledge-base retrieval.

Not available post-conversation:

• Integrations and MCP server tools (Salesforce, Outlook, HubSpot, and every connector in the Integrations catalog). Integration tools are not offered to the model in the post-conversation turn at all, and a post-conversation model attempt to call one is refused. Integration actions in post-conversation instructions — for example “after the call, send a summary email via Outlook” — will not execute and will not silently succeed.
• Call-control tools (hangup, transfer, refer, and other telephony actions). There is no live call to act on.
• Client-side tools, which require a connected Voice SDK client.
• update_dynamic_variables — the conversation is over, so updated variables have nowhere to land.

If your assistant’s post-conversation instructions rely on an integration tool, that step will not happen. Configure a webhook tool that reaches your own backend (or a function tool) to perform the action instead, or trigger the action from the conversation.ended webhook in your application.

Designing post-conversation instructions

Because the available toolset is narrower than during a call, write post-conversation work into the assistant instructions only in terms of tools that survive the filter above. If the assistant’s only configured tools are excluded (for example, an assistant with nothing but transfer and hangup), the post-conversation turn has nothing to call — the turn runs and ends without performing any action.

---

Observability

Post-conversation processing inherits the assistant’s data-retention setting. With data retention enabled, the tool calls the model makes post-conversation and their results appear in the conversation’s message history alongside the trigger message. The turn itself is billed as LLM inference like any other model turn.