Durability and recovery

What survives a restart or platform update — conversations, schedules, queued work, and pending approvals — and what happens to a reply that’s mid-stream when an update lands.

Your agent keeps working across restarts and platform updates. Conversations, schedules, queued work, and pending approvals are all stored safely, so an update or a hiccup doesn’t lose your data or your users’ place in a conversation. This page describes what you can rely on.

What survives a restart or update

Thing	What you can rely on
Conversations & transcripts	Fully retained. The next message on any channel — widget, web, IM, email, API — picks up where the conversation left off. Conversations span restarts and updates.
Schedules	Runs that came due during downtime fire shortly after the platform is back. Missed occurrences collapse into a single catch-up run, and a run never fires twice. See Schedules.
Pending approvals & questions	A confirmation, form, or question your agent posed before an update can be answered after it. The answer reaches your agent on its next turn.
Queued work (file ingestion, CRM sync)	Recovers automatically and resumes where it left off. See CRM sync.
A2A tasks	Task state is retained; callers can re-query a long-running task by its id. See A2A.
Memory	Retained permanently until you erase it. See Memory.
Agent configuration	Retained, with connector credentials encrypted. Configuration edits take effect without a restart.
Billing	Every charge is recorded reliably — your balance and your usage history always agree.

Updates don’t drop your agent

Platform updates roll out with no downtime, and an update never drops an in-flight conversation. A new version only starts serving traffic once it’s fully ready.

If a streamed reply happens to be writing at the exact moment an update takes over, the user may see that one reply end early. Nothing said before it is lost, and the user’s next message continues the conversation normally.

This is safe because:

• Conversation history is saved after every reply, so nothing the user or agent said before an interrupted reply is ever lost.
• A resent request continues from the full history — the user’s client retries and the conversation carries on as if the interruption never happened.
• Approved actions aren’t repeated. An email or connector action that was already sent isn’t sent again just because a turn was retried — see Tool execution and reliability.

Pending approvals resume across turns

When your agent asks for something it can’t get in the same turn — a confirmation, a form, a question, a handoff acknowledgment, or a missing tool parameter — it saves that request and ends its turn. The user can respond minutes, hours, or an update later (up to 48 hours), and your agent picks up the answer on its next turn. An action approved once runs once, no matter how many times the request is retried.

This is how long-running, human-in-the-loop flows work: a conversation that pauses on a human decision costs nothing while it waits and survives any number of restarts in between.

Where to go next

• How a turn executes — the limits that bound every turn.
• Tool execution and reliability — why an approved action runs at most once.
• State and sessions — how each channel keeps its own conversation.
• Schedules — the scheduler described above.