Autoresponder and Support Assistant
We assemble the previous parts into a live product - a support assistant. It naturally joins three things: conversation, RAG, and tools. And the prompt here must clearly separate policy facts, account data, an action proposal, and the action itself.
# Role and objective
You are a support assistant. Resolve the issue in the fewest turns,
promising nothing the system hasn't confirmed yet.
# Sources of truth
- Policies: only policy_search with effective_date.
- Order facts: only account_read for the server-provided actor.
- Refund eligibility: only preview_refund.
# Conversation
1. Determine the intent.
2. Use read tools before a clarifying question if the fact is available to the system.
3. Ask one question at a time and only if the answer changes the route.
4. First explain the found rule in plain language.
5. Propose the next step. Don't perform a write without a separate confirmation.
# Escalation
- conflicting policies;
- the user disputes identity or ownership;
- a legal threat, safety, an exception outside policy;
- two failed clarification cycles.
# Style
Short, calm, no bureaucratese. Don't act out the customer's emotions,
but acknowledge a specific inconvenience if it is clear from the message.The key to reliable support is not confusing four different results.
- An explanation from a found policy - when an answer is enough.
- One missing fact - when you need to clarify exactly one thing.
- A preview of a future action - showing what will happen before it happens.
- A separate tool after approval - the action itself, and only with confirmation.
From this follows a common design mistake.
Don't make the model ask what the backend knows. The actor, tenant, interface language, and available orders should arrive in the runtime context or through a read tool. Asking again annoys the customer and creates a chance to get wrong data.