What the documents look like
On a Shopify standalone store, payment, shipping and fulfillment services are configured by the merchant, and the platform does not operate a unified automatic return process. That difference shapes the document set used in store service and internal training: order details, shipping templates, shipping labels and refund records. These materials update per order and per day. In one conversation, a service agent often needs to trace order status, fulfillment progress and the refund stage across several turns.
The governing constraint for multi-turn prompts is that the model answers only from the context carried into the turn and from knowledge base content. The prompt must state the material scope, the answering task and how missing evidence is handled, so the model does not write in business facts that the source does not contain. History depth, question optimization, model context length, reply ceiling and reply format each need separate checking against the actual configuration rather than assumption.
Constraints at the multi-turn prompts step
For history, check how many prior turns are actually carried in, and distinguish a new conversation from a continued one, because the input differs between them. For question optimization, where a knowledge base supports continuous conversation, check reference resolution and question expansion; short questions do not automatically qualify. For model and length, check the context length the model supports and the reply ceiling setting, then exercise them with a long document combined with follow-up questions. For reply format, choose the format the downstream node needs; when json_schema is selected, the corresponding format requirement must be filled in and the returned structure checked.
When a workflow reaches an interactive node, the interface returns the display configuration only, containing type and params; internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs and nodeResponseId are not returned. A waiting state and a recorded state are explained by the documents; automatic judgment or snapshot guarantees are not assumed.
Hypothetical paper exercise sample. Source text for checking: "Order A was created on 10 March 2026, shipping template B applies, the shipping label has been generated, and the refund record is empty; in service conversation C the customer asks about the shipping time." Draft sentence to be judged: "Order A has been shipped and the refund has been processed." The checking scope is limited to that order detail and that refund record, and the authorization boundary is the store service agent's query permission. Judgment: the draft sentence does not agree with the source text; neither the shipped status nor the refund status is supported.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason for the choice and comparison method |
|---|---|---|
| Memory turns | Hypothetical starting point of 4 turns | Service scenarios keep a small amount of history; compare how well follow-up references are restored at different turn counts |
| Reply ceiling | Hypothetical starting point of 800 tokens | Order explanations need room; compare truncated output against complete output |
| Temperature | Hypothetical starting point of 0.2 | Service question answering needs stability; compare repeated answers to the same question |
| Reply format | Default text | No downstream node reads a fixed structure; compare whether the returned structure meets the downstream need |
| Thinking configuration | Default | A simple order follow-up does not need high thinking strength; compare response time and answer quality |
| Multimodal recognition | Off | This sample has no image or audio input; compare whether enabling it introduces unrelated content |
The thinking_budget field is a thinking budget and must not be repurposed as a citation token limit. A relevance score is not a category, entity or permission filter, and retrieval does not perform authorization. Where several knowledge bases use different vector models, they cannot be jointly associated; check the identifiers first, exclude those that do not match, and record what is actually observed.
Three common errors
- Treating retrieval similarity as a permission or entity filter, expecting a low-scoring result to exclude an unrelated order. The input to check is the query and the knowledge base identifier; compare the returned
scoreanddatasetId; observe whether records for other orders are still returned. - Treating the display configuration of an interactive node as an executed action, reading a
userSelectoption as a completed choice. The input to check is theinteractivetypeandparams; compare themessagescontent of the following request; observe whether the choice result still has to be submitted by a person. - Reading the material scope in the prompt as permission to complete business facts automatically. The input to check is the draft sentence and the source text; compare the field values in both; observe whether the draft sentence states a shipped or refund status that the source does not carry.
How to verify the setup
- Check one: input the source text and the draft sentence from the hypothetical sample above, and compare the shipped status and the refund record fields in the draft sentence. The condition is met when the draft sentence does not claim a status the source does not carry; it is not met when "has been shipped" or "has been processed" appears.
- Check two: input an empty result
[]together with the downstream handoff design, and compare whether the downstream node handles the missing evidence. The condition is met when the downstream output keeps a pending-verification marker; it is not met when the downstream writes in business facts. - Check three: input two knowledge base identifiers that use different vector models, and compare whether the identifiers match. When the identifiers differ, record them as not jointly associable and exclude them; when the identifiers match, then check the actual return. No conclusion about missed recall or redundant results may be drawn from this comparison.
A pending request is not an approval, an offered option is not an execution, and an unsigned termination is not a completed termination. Where a field is not provided in the source, its value remains unknown; where only evidence of a related stage exists, the specific fact remains unsupported and pending verification.