Start with the action, then choose the control
Belgavi's Book Store is fictional. Its catalog, orders and policy records in this guide are synthetic. Imagine an assistant that recommends books, explains the current returns policy and drafts a stock adjustment. These three jobs have different consequences. A poor recommendation can be corrected in the next message; an incorrect refund or stock update changes a durable record.
Write an explicit contract for each tool. A catalog lookup accepts a bounded query and returns public fields. A policy lookup returns a revision identifier and effective date. A refund draft records the order reference and proposed amount but cannot execute a payment. The execution service independently checks authorization and the approved amount. A persuasive model response never substitutes for that check.
Keep evidence and instructions in different channels
A customer review can contain text that looks like an instruction. A supplier note can request that the assistant ignore a refund limit. Both are untrusted content. Preserve their provenance and present them as evidence to interpret, rather than authority to change the task. Restrict each retrieval index to the audience that may read it: public catalog data belongs in the public assistant; internal stock notes do not.
When two policy revisions disagree, the assistant should identify the uncertainty and stop the affected action. Displaying a disclaimer does not resolve an inconsistent policy source. Keep the selected revision attached to the draft so a later approval refers to the same evidence.
Test the boundary by trying to cross it
Use synthetic cases with known expected outcomes: an injected review requests a price change; an expired policy contradicts the current revision; a public lookup requests an internal field; a retry repeats an approved refund. Check the service result and durable record, not just whether the answer sounds cautious. A denied action must leave no side effect.
For an uncertain timeout, query the operation ledger using the original idempotency key. Do not generate a new key and hope the earlier action failed. Record explicit states such as pending, confirmed, rejected and requiring reconciliation. A human can resolve the last state with the same evidence the system used.
Try a failure drill, then record the limitation
In the circuit-breaker mission, compare dependency failures with blocked requests and recovery delay. A smaller failure count alone is not success if healthy work stays blocked. In the backpressure mission, account for deferred and discarded work as well as queue length.
Those exercises are deterministic simulations. They do not establish that a real bookstore service meets an availability or safety requirement. Before deployment, run the same boundaries against actual tool implementations using synthetic records and collect the resulting evidence.
Further reading
The NIST AI Risk Management Framework Core provides a broader structure for organizing risk work. The bookstore controls and scenarios above are original educational examples, not a certification.