What the documents look like
Site selection and store opening work happens before a store begins trading. The core objects are lease commitments and construction handover, not in-store supervision. The working materials are trade-area footfall, map POI data, historical store-type POS records, and landlord documents. The day-to-day paperwork is a site evaluation form, a letter of intent for lease, a renovation budget, and an opening schedule. These materials are updated irregularly, per store.
For operating reports and exception review, tool calling and plugins take fields from those documents as input, and the model decides whether to call a tool based on the tool description and the parameter descriptions. Because sources are scattered and each store has its own set, tool parameters must accept differences between stores, and the tool description must state the input conditions as well as the situations in which the tool should not be called. Retrieval and similarity scores do not carry permission or entity isolation, and a retrieval result does not constitute authorization.
A second consequence is that the review stage sits between documents and downstream action. A letter of intent that is unsigned, a budget that is pending review, and a schedule that has not been confirmed are three different states. Tool output can summarize what the documents say; it cannot convert an unsigned document into an effective one, and it cannot convert a pending review into an approval.
Constraints at the tool calls step
A tool consists of a tool description and tool parameters. For system modules the parameters are fixed; for plugins the parameters are configurable. Parameters carry two key values: the parameter description and whether the parameter is required.
The model combines the tool description, the parameter description, and the required flag to decide whether to call the tool. With a tool that has no parameters, the decision rests on the tool description alone. With a tool that has parameters and no required parameter, the tool can still be called even when the context holds no suitable parameter, and the model may fabricate one. With a tool that has a required parameter, the model may decline to call the tool when no suitable parameter exists, and a prompt can guide the user to supply it.
In advanced orchestration, dragging the connection point of the tool call node makes a diamond appear on the head of available tools, and that diamond connects to the diamond at the bottom of the tool call node. A connected tool automatically separates tool input from ordinary input, and its description becomes editable, which allows the call timing to be tuned. Adding many tools at once makes debugging harder, so the guidance is to select a small number and tune them before expanding.
By default, after the tool call node decides to call a tool, it returns the tool result to the AI so the AI summarizes the output. When no further summary is wanted, the tool call termination node is placed at the end of the tool flow. The termination node ends the current call: no other tool is called, and the AI is not called to answer based on the tool result. The custom variable node extends tool variable input, so nodes that are not treated as tool parameters, or that cannot be called as tools, can be described and then called through the tool call.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this trial | How to check |
|---|---|---|
| Tool description | State that input is the site evaluation form and letter of intent fields, and that the tool is not called when the material does not state signing status | Compare the description against whether the source text contains subject, object, and status |
| Required parameter | Set to "letter of intent signing status"; the tool is not called when it is absent | Check whether the request carries that field |
| Tool connection | Connect only the site evaluation form reader and the letter of intent reader | Check the connection points and the diamond on the tool head |
| Tool call termination | Place after the letter of intent reader | Observe whether the AI summary is still called |
| Custom variable | Add a "renovation budget approval status" description | Check the variable description against the actual request |
The starting point of a small number of tools is chosen because adding too many tools at once increases debugging difficulty; the comparison object is the call record produced when only one tool is connected. These values are hypothetical starting points for this page, not official defaults.
Three common errors
- Treating a parameter description as a guarantee of execution. The parameter description explains what the parameter means; it does not guarantee the tool will be called. The check takes the parameter description text as input, compares whether it is treated as a promise of execution, and the observable result is a call record in which the tool is absent.
- Treating a retrieval result as authorization. Retrieval returns material fragments; it does not indicate that approval has been granted. The check takes a retrieved fragment of the letter of intent as input, compares whether it is used to arrange renovation budget approval, and the observable result is a draft sentence stating that the document is effective.
- Treating a pending review as a lack of operating permission. Pending review only means the status is undetermined; it does not show that permission is absent. The check takes a pending-review marker as input, compares whether it is written as a lack of permission, and the observable result is a conclusion that goes beyond the source text.
How to verify the setup
Hypothetical paper exercise sample. The source material reads: "Party A: the expansion department of a chain headquarters; Party B: a property party. The letter of intent states a lease term of five years and a rent-free period of three months. The signing date is a hypothetical 10 March 2025, and the two parties have not yet signed." The draft sentence to be judged is: "The letter of intent is already effective, so renovation budget approval can be arranged on that basis." The source names the subject, the object, and the status, and it does not state an effectiveness clause. The draft sentence writes an unsigned state as an effective one, which is unsupported.
- Verification one. Input the hypothetical source text and the draft sentence, compare "not yet signed" against "already effective," and the condition is met only when the draft sentence is changed to "not yet signed, effectiveness pending verification."
- Verification two. Input a request in which the required parameter is missing, compare whether the letter of intent reader is called, and the call condition is met only after the request supplies the signing status.
- Verification three. Input the tool call termination node placed after the letter of intent reader, compare whether the AI summary is still called, and the condition is met only when the AI summary is no longer called. An empty result can be checked against the downstream design using the paper input [], without claiming that a fabricated rule retrieval necessarily returns []. Cross-model association is not available; check the identifier first and exclude those that do not match.