Prepare state and ask precise questions

Supply evidence, then ask one bounded question

“Handle this email” is broad. Ask instead: “Choose one queue from the list using the message; choose other when evidence is insufficient.” State should contain the needed evidence, while question instructions define the decision.

{
  "message": "My parcel has not arrived. Can you check delivery?",
  "order": {"status": "shipped"},
  "allowed_queues": ["shipping", "refund", "billing", "other"]
}

Do not dump an entire CRM into every call. Missing information should remain missing rather than becoming an assumed fact.

Three repeatable checks

Exclusivity: what happens when a customer asks about shipping and a refund? Define priority explicitly, detect multiple intents, or request review.

Fallback: allow other or insufficient_evidence when no option fits. Your application must know how to handle it.

Testability: a human should be able to label each decision. Define terms such as “important” or “high quality” before using them as a rubric.

A batch is not a chain of reasoning

Questions in a request are evaluated independently against shared state. Do not refer to an earlier question's answer. For dependent decisions, make a second call and explicitly pass the validated first result.

Preparing Chinese inputs

Retain relevant source text, abbreviations and context. Compare Chinese instructions with a tested bilingual formulation on the same held-out set. Do not assume translation into English always helps; measure errors, version and cost.

Exercise

Prepare three redacted emails: clear shipping intent, multiple intents, and unrelated text. Label expected outcomes before running the same questions. Investigate failures rather than showing only successful examples.