Handle conversation state, corrections and human takeover
The short answer
A support conversation keeps changing while the agent works. Every run needs to know which message it started from, who owns the case right now and which actions have already completed. Check those facts again right before any external action or public reply.
Write a control table
Start by deciding who is in charge of a conversation at any moment, and what each party may do. Without that, a teammate and the agent will eventually reply on top of each other. The table below is a simple starting point with four control states. Treat public replies, internal notes, translations and tags as separate permissions, because a team may want the agent to keep tagging or drafting notes after a person has taken over, but never to post publicly.
| Control state | Public AI replies | Other work | How it changes |
|---|---|---|---|
| AI owns the case | Allowed after final eligibility checks | Only explicitly permitted tools and metadata actions | Human takeover, pause or completion |
| Human owns the case | Blocked | Internal assistance only if the team enabled it | An explicit return-to-AI action |
| Paused | Blocked | Reconciliation and operational logging may continue | An authorized resume after the cause is resolved |
| Closed | No automatic new answer | Outcome observation and retention jobs | A reopen event is assessed under the current policy |
Make the transitions explicit too. Handing a conversation back to the agent after a person has worked on it should be a deliberate action by someone allowed to do it, not something that happens because a timer ran out. Only add an internal-assistance mode, where the agent helps teammates without speaking to the customer, if your team actually needs one.
Use message versions to reject stale work
Give each accepted change to a conversation a version number or another reliable ordering marker. When a run starts, it records the version it’s working from. Before it takes an action or sends a reply, it compares that version with the conversation’s current state. If the customer has written again, the run’s work may be stale: a correction can invalidate details the agent collected, the sources it picked and any action it was about to take. In the Northstar case, the ORD-204 answer is discarded and the agent starts again from ORD-205.
Don’t handle a burst of messages by keeping only the last one. “It’s order 204” followed by “and it arrived damaged” needs both messages to make sense. A short collection window, where the agent waits a moment for the customer to finish typing, can help, but it adds delay to every reply and needs a firm upper limit. Preserve the arrival order, the helpdesk’s message IDs and every correction the customer made.
Where two workers could pick up the same conversation, give one of them exclusive control for a limited time, using a lease (a lock that expires on its own) or something equivalent. A crashed worker must not hold the conversation forever, and a worker whose lease has expired must not be able to commit a late result. Check an ownership token at the exact point where your application commits an effect, such as sending a reply or calling a tool, not only at the start of the run.
Keep history useful and bounded
Store facts and confirmed action results separately from any free-form summary of the conversation. A summary is helpful for reading, but it can drop the reason a refund was denied or make a tentative statement sound final. Keep the relevant original messages and source IDs available, so anyone reviewing the conversation can check what was actually said.
For a long conversation, the agent needs the current request, any unanswered questions, the customer’s verified identity state, the procedure it’s in the middle of and the results it has confirmed. It doesn’t need the full ticket, email signatures and repeated quoted replies in every model call. Sending everything raises cost and makes it easier for an old detail to leak into a new answer.
Customers change topic mid-conversation. When that happens, decide whether to pause, finish or abandon the procedure that was underway. If the customer later comes back to the earlier topic, the agent should pick up from the recorded state. It must never repeat a completed write, such as a second cancellation request, just because the subject came up again.
Language and attachments change the evidence
A short greeting like “Hi” or “Hola” is weak evidence of which language a customer wants. Respect an explicit language preference first, then go by the customer’s first substantive message. Test questions that mix languages, and check what happens when a conversation is handed to a teammate who works in a different language. Order numbers, amounts and dates must come through translation with exactly the same meaning.
Attachments need a fetch policy that runs on your server. Check where the file link points, follow redirects carefully, confirm the file type and enforce a size limit while downloading rather than after. Never pass your helpdesk credentials to another host. Text read from an image or PDF may be wrong, and it may contain instructions planted by an attacker, so treat it as customer-supplied content. If extraction fails or is uncertain and the detail matters to the answer, say so and ask the customer for it.
Delayed work must recheck its conditions
Scheduled jobs, such as a follow-up message or an auto-close after a day of silence, were valid when they were created. That doesn’t mean they’re still valid when they fire. Store each job’s purpose, the conversation version it was based on and when it expires. When it runs, check ownership, new messages and current settings again before doing anything.
Canceling the job when conditions change is useful, but it isn’t enough on its own. A job may already be running when the cancellation arrives. The check at execution time is the final safeguard. When a job decides not to act, log the reason, so your team can tell an intentional stop from a broken scheduler.
Ask AI to explain this guide
Build decisions and checks
Use these decisions to turn the worked case into your own implementation. A check is complete only when you have evidence for the stated result.
Route the message to the correct configuration
Required. A mismatched brand, inbox or environment can load the wrong policy and data.
Build. Tie each trusted helpdesk workspace and channel to an approved agent configuration. Keep test and production separate. For one company, a single configuration may be enough. Record which configuration version handled each turn.
Check. An unknown workspace can't fall back to a default customer account. A test event can't reach production tools.
Keep useful history
Required. A follow-up like "the second one" needs context, but unlimited history adds cost and risk.
Build. Keep message order, the items the customer referred to, verified identity and task progress. When you trim history, keep the important facts. Leave out signatures, repeated quoted emails and unrelated private notes. Define when memory expires and when it resets.
Check. Test pronouns, corrections, repeated text, long threads and returning users. Check that private facts never carry over between accounts.
Handle rapid messages and human takeover
Required. A customer can correct their order number while the agent is still preparing an answer for the old one.
Build. Track which message version each run is using. Combine a quick burst of messages where it makes sense. Cancel or discard stale work, and check again before every write and final send. A human takeover must stop pending replies and scheduled follow-ups. Keep an explicit control table for AI ownership, human ownership and pause, and add an internal assistance mode only if you need one. Define separately which public replies, notes, tags and translations are allowed. Handing a conversation back to AI is an authorized step. When delayed work runs, it must recheck ownership, the latest message, current settings and expiry.
Check. Send a second message and a human reply mid-run. No outdated answer or action goes out. An old follow-up or auto-close job does nothing once its conditions no longer hold. Internal assistance can't send a public reply by accident.
Handle language and attachments
When it applies. A short greeting, a mix of languages or an image can change what the agent has to understand.
Build. Set rules for which language to reply in. Keep names, amounts, product codes and dates exactly as written. Retrieve source content across languages where needed. Fetch protected attachments with server credentials and validate their type and size. Treat text read from images (OCR) as uncertain evidence. Check the attachment host and network destination at every redirect, and never send credentials to a different host. Enforce size limits while streaming, and treat a failed extraction as missing evidence.
Check. Test language switches, image-only messages, unreadable files, expiring URLs and ambiguous dates. When the evidence isn't enough, the agent asks for more detail.
Ask AI to apply these decisions
Templates and examples
Every file uses synthetic data. Adapt it to your own policies and test it somewhere safe before it touches customers.
- conversation-state.csvSpreadsheet worksheet (CSV)
- event-policy.csvSpreadsheet worksheet (CSV)
Keep it working
Launch is the start of the work, not the end. These are the recurring jobs this part of the agent needs, and who usually owns them.
| Cadence | Owner | Work |
|---|---|---|
| On change | Engineering | Audit new inboxes, brands and configuration changes. |
| Weekly | Engineering | Review failures in long threads and how much memory is retained. |
| Weekly | Engineering | Check stale-run counts, takeover failures and double replies. |
| Weekly | Support lead | Review errors by language and attachment type. Keep translated handover and outage messages up to date. |
Test your decision
A customer correction arrives after a business action has completed but before the reply is sent. Should the old action record be deleted?
Show the expected decision
No. Keep the confirmed result. Stop the stale reply, work out what the customer now needs and explain or transfer the case according to your policy. Undoing the action is a new, separately authorized operation, not an edit to history.
