Consequential actions and human approval
Reading, drafting and executing transactions have different risks.
What you will learn
- Explain: the model proposes, the tool executes
- Apply the idea in an example: Consequential actions and human approval
- Recognize limitations and verify the exercise outcome
Reading, drafting and executing transactions have different risks. Separate a proposal from consequential execution.
This is a conceptual or external lab. It does not assume the application exposes every control described.
How it works, step by step
The model proposes, the tool executes
Tool calling produces a call request with a name and arguments. The application validates the schema, permissions and limits before execution. The result returns to context for the next step. For example, get_product_stock takes a SKU and returns a quantity; its description should explain that it does not reserve products. Distinguish empty results, validation errors, missing access and timeouts. Valid JSON does not prove the arguments are correct or the action is authorized. For external effects, also consider duplicate execution.
Check access before use
Permissions must be enforced by servers and the data layer. Do not let the model decide whether a user may see a document. Filter sources before they enter context, not after generating the answer. Use minimal-access credentials, keep them out of prompts, screenshots and browser code, and rotate exposed keys. A widget domain allowlist does not replace API authentication. Authentication identifies you; authorization determines the operations and data you can use. Test denied access too.
Errors need explicit paths
A timeout differs from a permission error. Retry only transient errors, with bounded attempts and increasing delays. An operation with side effects may execute before its response is lost; retrying without an idempotency key can duplicate the effect. Streaming shows progress but does not guarantee completion. Checkpoints may allow failed stages to resume within runtime limits. Store the run identifier, stage, duration and error while removing secrets from logs. Measure slow paths as well as averages.
The visual map
Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. Human approval is an application integration concept; a prompt asking for approval is not enforcement. On smaller screens, scroll horizontally to follow the entire diagram.
A complete example
“Can you cancel the order?” may start with reading and preview. Execution must confirm identifier, effect and authorization; a model response is not user approval.
Try it yourself
- Draw a cancellation flow with preview, approval and duplicate-effect protection.
- Record the input, source and expected outcome before running the experiment. Use only the fictional data in the example.
- Follow the diagram stages. At every step record what information is received and produced; do not confuse intermediate output with the final outcome.
- Repeat after removing necessary information or making the input ambiguous. Check whether the system clarifies, stops or invents an answer.
- Compare with the explained solution. Keep the configuration, date, result and an explanation for differences. Change one thing and retest.
An explained solution
The action does not execute without required control; audit separates proposal and execution. A successful exercise lets you show the connection between input, stages and outcome. When information is missing, a cautious answer is more useful than invented details. Compare more than style: check conditions, sources and operations too.
When it helps and what can go wrong
This is an architectural example; it does not assume an implemented UI approval control. Choose this approach when it improves a measured need. Keep a simple baseline and compare outcomes using identical inputs. One successful example does not establish reliability in every situation.
Check your understanding
Who executes a call proposed by the model?
The application or host service after validation. The model does not automatically gain unrestricted access.
Why is removing a private source after answering too late?
The data has already entered model context and can be disclosed.
What outcome should this exercise produce?
The action does not execute without required control; audit separates proposal and execution.
Words to remember
- Tool calling: A structured request to use an external capability.
- Autorizare / Authorization: Checking the right to access an operation or resource.
- Idempotency: Controlled repetition without duplicating an effect.
Sources and your next step
To prepare: S02 — Permissions and protecting data