What the documents look like
Amazon FBM fulfillment places fulfillment and return-address configuration with the seller rather than a platform warehouse, so the working materials are order pick sheets, shipment confirmation notes, return-address settings, and logistics tracking tables. Customer-service and logistics staff in store service and internal training align these materials with conversation records and check three recurring stages: carrier selection, tracking-number confirmation, and undelivered-complaint handling. The materials update per order and per day; that cadence describes how records are produced and does not imply batch synchronization or a real-time trigger.
For the multi-turn prompts step, the constraint comes from what each material is. An order pick sheet and a shipment confirmation note are business vouchers, a logistics tracking table is a process record, and a return-address setting is a configuration item. Inside a conversation these materials can serve only as objects of comparison. A retrieval hit or a completed form does not carry authorization, and it does not mean a shipment, refund, or claim has been executed.
Constraints at the multi-turn prompts step
A prompt needs to state the material scope, the answering task, and how to handle missing evidence, so the model does not write business facts that the materials do not contain. History handling requires checking which context was actually carried in and distinguishing a new session from a continued session. Question optimization applies when a knowledge base supports continuous conversation, where pronoun resolution and question expansion are checked; a short question does not automatically qualify. Model and length settings require checking the context and reply configuration against long documents and follow-up combinations. Reply format follows what the downstream step consumes; when json_schema is selected, the corresponding format requirement is filled in and the returned structure is verified.
Hypothetical paper exercise sample: an FBM seller's customer-service desk receives a ticket. The material text reads: "Order A was picked up by carrier Jia on March 12, and tracking number T has been entered in the logistics tracking table; the return address is set to warehouse Yi, effective March 10." The draft sentence to be judged is: "This order has been confirmed delivered and the ticket can be closed." The source states pickup and tracking-number entry only, and does not state delivery. The draft sentence exceeds the material scope and is unsupported.
Configuration and implementation checks
| Configuration item | Relevant setting on this page | How to check |
|---|---|---|
| Memory rounds | Retain a small number of history rounds to compare earlier ticket content | Compare the historyPreview actually carried in against the ticket materials |
| Reply cap | For this hypothetical exercise the starting value is set short because training replies need to be brief; compare against an untruncated reply | Observe whether the reply is cut off early |
| Temperature | Lower values are suggested for customer service and knowledge base Q&A | Compare reply stability across values |
| Reply format | Select json_schema when a downstream step reads a fixed structure, and fill in the format requirement | Check whether the returned structure matches the filled requirement |
| Multimodal recognition | Enable only when the model supports it and image input exists | Check model capability against input type |
| Hide AI output | Enable when a later node rewrites the result | Check final displayed content against node output |
Three common errors
- Treating a retrieval result as authorization. Input is a hit record from the logistics tracking table; the comparison object is the authorization status field; the observable result is that the hit record carries no authorization marker, so it cannot be used to execute a shipment or refund.
- Treating form completion as business execution. Input is the return-address setting form; the comparison object is the actually effective configuration; the observable result is that the form values were not written into the business system, so a return-address change is not established.
- Treating pending review as missing permission. Input is a ticket status of "pending review"; the comparison object is the operation-permission record; the observable result is that a permission record exists separately, so pending review does not establish missing operation permission.
How to verify the setup
- Input the hypothetical sample source text and the draft sentence; compare whether the draft sentence exceeds the scope stated in the source; the observable result is that the draft sentence contains "confirmed delivered" while the source does not state delivery, so the sentence is judged unsupported.
- Input a continuation request under the same chatId; compare the historyPreview actually carried in against the ticket materials; the observable result is that the number of rounds carried matches the materials, and a new session carries no history.
- Input a paper sample of empty result []; compare whether the downstream node design handles the empty reference; the observable result is that the downstream explicitly retains a missing-evidence branch, without claiming that a fabricated rule search necessarily returns [].