Identify where the operation executes
Anthropic’s tool-use overview distinguishes client tools executed by the application from server tools executed by Anthropic. For a user-defined client tool, the model returns a structured request and the application runs the operation before returning its result. This separation provides a place to enforce business controls independently of the model’s proposed arguments.
Read the connected system’s operation as carefully as the tool description. A function called “update supplier” may change contact information, payment instructions or many fields at once. The name alone does not establish the authority or review required. Document the effect, target identity and supported failure behavior before putting that function into a task.
Give each tool one understandable effect
A narrow operation is easier to authorize and investigate than a general instruction to complete a process. Separate retrieving a supplier, preparing a proposed change and applying an accepted update. Use stable record IDs for execution, while leaving human-readable names in the interface. A similarly named organization should not become the target of a guessed update.
A requested action is not an accepted effect.
- Propose
- Tool and arguments
- Authorize
- Identity, scope and version
- Execute
- Supported target operation
- Confirm
- Stored result and outcome
| Evidence | Meaning |
|---|---|
| Propose | Tool and arguments |
| Authorize | Identity, scope and version |
| Execute | Supported target operation |
| Confirm | Stored result and outcome |
The application enforces authority and confirms the accepted target effect.
Validate arguments in application code and check the acting identity’s permission for the particular operation. Keep secrets and authorization tokens in the execution environment rather than asking the model to carry them in its prompt. The model can explain a request; it should not be able to approve its own request or enlarge the permissions attached to it.
Work through a supplier-address correction
In this example, an email says a supplier’s service address has changed. The assistant finds the supplier record and prepares a proposed correction with the message as evidence. The buyer checks which supplier site is affected and whether the change is appropriate. An accepted address correction does not authorize unrelated payment-detail changes mentioned in the same email.
| Operation | Effect | Required check |
|---|---|---|
| Read supplier | Retrieve the permitted record. | Identity and record access. |
| Prepare correction | Store a proposed address and source. | Supplier site and evidence relationship. |
| Apply correction | Change the accepted address field. | Named authorization and current record version. |
The final operation should refer to the approved proposal and its target version. If another person has changed the record since review, return the conflict for reconciliation. The earlier approval applies to the reviewed version, not the newer record.
Make completion an observed result
Store the requested operation, its permitted scope and the target’s response with a correlation identity. A network timeout after a write is uncertain: the target may already have accepted the change. Inspect the actual record or supported operation status before repeating it. A generic retry can create duplicate records or apply an effect twice.
- Confirm the request passed the application’s authorization checks.
- Execute through the target’s supported interface.
- Reconcile uncertain responses before repeating a consequential operation.
- Record the accepted target identity and version.
- Show the result to the user beside the affected record.
Test the boundary, including denied work
Use an approved test environment with an ordinary request, an ambiguous supplier and an out-of-scope change. Verify that the execution layer stops the latter even when the model proposes plausible arguments. Inspect what the user sees: completed read work can remain useful while a write waits for authority or clarification.
Also test revoked access and a changed target version. Keep the expected outcome for each case in the acceptance record. Scope a pilot with Trion around one permitted effect and its required human decisions.
Keep the tool contract current
When a connected API or tool definition changes, review its effects again. An added field can alter the scope of an update without changing the function’s name. Assign an owner for operation definitions, access changes and reconciliation.