The prescription-refill topic must never approve a refill if the patient has not been seen by a vet within the group's required window. A specialist stores that window as a reusable variable and references it in a filter on the refill action. Why is this preferable to writing the number into the topic's instructions as plain text?
Select an answer to reveal the explanation.
Short Explanation
Hard-coding the window into an instruction is like writing the clinic's return policy on a sticky note the model might lose; a variable feeding a filter is the policy carved into the front desk itself. One update, everywhere, no way to argue with it.
Full Explanation
A variable centralises the required-visit window as a single reusable value, and binding a filter to that variable means the refill action is deterministically blocked whenever the condition fails, regardless of how persuasively the request is phrased. That gives two benefits at once: a single point of maintenance when the group's policy window changes, and a rule the model cannot be talked past. Letting the model choose a different window per conversation is the opposite of what this control is for; refill safety windows are exactly the kind of rule that should never flex based on a sympathetic story, which is why it is structural rather than instructional. The variable and filter have nothing to do with the Agent User's permission set, which is a separate, object-and-field-level access control that still must be configured correctly on top of this rule. The Einstein Trust Layer masks sensitive data in prompts and responses; it does not evaluate business-rule thresholds, and confusing the two is a common trap. The adjacent fact worth knowing: filters can reference variables that are themselves computed or looked up, not just static constants, which is what lets one variable serve multiple topics consistently.