Reply and triage an inbox

Inbox help often combines triage and reply drafting, but they are different tasks. Triage predicts what a message is about and what should happen next. Reply drafting proposes words to send. A wrong triage label may hide an urgent message; a wrong reply may create a commitment or disclose information.

Keep the steps separate:

1. inspect the message and thread context;
2. classify category, urgency, and needed action;
3. identify uncertainty or escalation conditions;
4. decide whether a reply is appropriate;
5. draft from approved facts;
6. review before any send action.

This separation makes errors easier to detect and prevents a confident draft from disguising a weak classification.

Categories should map to real actions, not merely describe topics. “Project,” “customer,” and “miscellaneous” may not tell anyone what to do. Better operational categories could be:

• reply today: sender needs a response within the stated or established service window;
• review and decide: message asks for approval, judgment, or a commitment;
• delegate: a named owner can handle it;
• schedule: request belongs on a calendar or task list;
• reference: useful information with no action;
• escalate: legal, security, safety, harassment, financial, executive, or other defined risk;
• uncertain: context is missing or classifications conflict.

Define urgency from evidence. A subject line containing “URGENT” is not enough. Use stated deadlines, sender role, customer impact, safety or security indicators, and blocking dependencies. Tell the model not to infer urgency solely from emotional language.

Every scheme needs an uncertain path. Forcing every message into a confident label turns ambiguity into hidden error.

Instead of requesting only a category, request structured reasoning:

Category:
Urgency: low | medium | high
Requested action:
Stated deadline:
Suggested owner:
Evidence: quote up to two short phrases
Uncertainty:
Escalation flag:

Evidence makes review faster. If the model labels a message “high urgency” but cannot point to impact or timing, the reviewer can challenge it. Quoted evidence must remain short and should not be copied into unrelated systems if the email is sensitive.

Structured output also supports evaluation. You can measure label accuracy separately from deadline extraction or owner suggestion.

Replies depend on thread state. The latest message may say “That works,” while the proposed date appears six messages earlier. A quoted section may contain an obsolete amount. Recipients may have joined or left the conversation.

When permitted, provide only the necessary thread and clearly distinguish:

• newest message;
• prior confirmed decisions;
• unresolved questions;
• superseded information;
• people currently included;
• attachments that are referenced but unavailable.

Tell the model to flag missing attachments and inaccessible links. It should not pretend to have read them. If the thread is long, first create a private working summary of decisions, obligations, and open questions; verify that summary before using it to draft.

Once triage is verified, reply generation should begin from an explicit summary and a clear statement of what the sender is allowed to say.

Draft with response boundaries

A reply prompt should specify what the sender is authorized to say. Include approved facts, allowed commitments, unavailable decisions, and questions that need escalation.

For example:

Draft a reply acknowledging the request and confirming that I will review it by Thursday. I am not authorized to approve the budget or promise a launch date. Ask whether the quoted amount includes tax. Keep the reply under 100 words and do not mention internal discussion.

This boundary prevents the model from being “helpful” by completing a decision you did not make.

For routine scheduling, acknowledgment, or status replies, templates can reduce effort. Still check recipients, dates, time zones, and attachments. Routine repetition is exactly where automation bias grows: people stop noticing small errors because most suggestions are acceptable.

Summarize before replying

For a complex email, use a two-stage prompt:

1. “List the sender’s explicit requests, deadlines, assumptions, and unanswered questions. Separate quotes from inference.”
2. After verification: “Draft a reply addressing only items 1, 2, and 4 with the approved facts below.”

This prevents the model from jumping straight to prose. It also reveals when you do not yet know enough to respond.

Watch for hidden requests. A sender may report a problem without explicitly asking for help. The model can suggest a likely need, but it should label that as inference: “Possible implied request: confirm whether support will investigate.” Your response can ask rather than assume.

Some messages should not receive an AI-drafted substantive reply. Define escalation rules for:

• threats, self-harm, safety incidents, or harassment;
• suspected phishing, credential requests, or malicious attachments;
• legal demands, subpoenas, or regulator contact;
• account, payment, payroll, or identity changes;
• health or highly sensitive personal information;
• media inquiries or executive impersonation;
• requests beyond the sender’s authority.

AI can help route such a message under an approved process, but it should not improvise advice. A safe acknowledgment, if policy permits one, should come from a reviewed template.

Do not judge triage only by overall accuracy. If 90% of email is low-risk reference material, a system can look accurate while missing half of urgent cases. Track errors by category:

• urgent messages incorrectly deprioritized;
• sensitive messages sent to the wrong queue;
• routine messages unnecessarily escalated;
• deadlines extracted incorrectly;
• owners suggested without authority;
• drafts that introduce unsupported commitments.

Test with ambiguous messages, forwarded threads, sarcasm, multiple requests, changed deadlines, and absent attachments. Include examples where uncertain is the correct answer.

Start with suggestions and human review. Consider more automation only after representative evaluation, monitoring, and a clear recovery path exist. Automatic sending carries a much higher burden than automatic labeling because the external action is harder to undo.