Judge an AI agent by the tools it can call
Before an AI agent touches business records, inspect its tools: narrow permissions, validated inputs, safe retries and approval tied to the exact action.
By 
Paul. AI and agentic engineering
The most revealing part of an AI agent proposal is its tool list. A demonstration shows what the model did once. The tool list shows what the application allows it to attempt again, including when the request is misunderstood or external content is misleading.
A business integration should treat each proposed tool call as input from an untrusted caller. That means checking permissions and business rules outside the model, keeping actions narrow and requiring human approval where an irreversible action could harm the business. Better model performance can improve usefulness. It does not replace those boundaries.
The capability and the authority are separate
Anthropic announced general availability of Claude tool use on 30 May 2024. The feature made model-directed interactions with external tools a supported offering. That historical milestone should not be mistaken for evidence that any particular business integration was ready to operate unattended.
For client tools, the current tool-use documentation distinguishes the model's request from execution by the application. The model produces a proposed call; application code carries out the operation and returns a result. The business therefore has a place to enforce its rules before anything changes.
Treat that point as the real permission boundary. A prompt saying “only refund approved orders” is an instruction to the model. A server checking the authenticated user's refund permission and the order's current status is an enforceable control. Both may be useful, but they have different jobs.
Name tools after business actions
Consider a hypothetical order assistant. A tool that accepts arbitrary database statements gives the model broad discretion. Separate operations such as finding an order, preparing a refund and executing an approved refund make the intended work easier to inspect.
Narrow naming alone is insufficient. The implementation must derive the company and acting identity from authenticated context, rather than trusting a company identifier supplied by the model. It must check that the order belongs to that company. A validly formatted order number says nothing about the caller's right to use it.
Read tools need boundaries too. Returning an entire customer history may disclose much more than answering an order-status question requires. Limit the fields and records returned to the task, and decide which returned content can be passed to the model provider. Read-only access reduces some consequences; it does not make confidential data public.
External text also belongs on the untrusted side of this boundary. A note in an order might contain instructions aimed at the assistant. It should remain order data. The application's permission checks must still apply if the model interprets that note as an instruction.
A retry must not create a second transaction
A timeout leaves an awkward ambiguity: the operation may have succeeded even though the agent received no result. Repeating a refund or customer email can then duplicate the business action.
For writes, define a stable business operation identifier and record its outcome. A repeat request for the same operation should return the existing result where the underlying integration permits that guarantee. The identifier must survive a retry; generating a new one for every attempt defeats the purpose.
Do not promise exactly-once execution across unrelated systems merely because one local function remembers an identifier. A remote service can commit a change before the local application records success. The design needs a way to reconcile that uncertain outcome, or to stop and ask a person rather than issuing another write blindly.
That is a useful acceptance scenario for an agent supplier: describe what happens when the connection fails after the external system accepts the action. A credible answer names the system of record and the reconciliation step. A second cheerful completion message is not evidence that the business action happened once.
Approval needs an exact object
“Ask before sending” leaves important details unspecified. A person should see the recipient, content and relevant business consequence of the action they are approving. The application should bind approval to those exact details.
If the model changes the recipient or amount afterward, the earlier approval should no longer authorize execution. If the underlying order changes, recheck whether the approval still applies. Expiring approval and checking current state reduce the chance of executing an obsolete instruction.
Not every write needs the same ceremony. Saving a reversible internal draft can reasonably use a lighter path than transferring money or sending confidential information outside the company. The policy should follow the consequence and the ability to recover. Reversibility also has limits: deleting a sent message does not erase what a recipient has read.
Keep evidence without building another data leak
Record enough to reconstruct who requested an action, which tool was called, what permission decision was made and what result was confirmed. Connect the approval to the operation identifier. Separate proposed calls, rejected calls and successful changes so that an operator can tell them apart.
Avoid copying every document or secret into the audit log. Limit access and retention according to the sensitivity and purpose of the record. An audit trail that exposes the same customer data to more people creates another problem to maintain.
The strongest counterargument is delivery speed. A prototype may show value before a full permission model exists, and an internal draft assistant can be useful with limited safeguards. Keep that prototype in a limited environment with limited authority. Expand its authority only when the application can explain failures as clearly as successes.
When assessing AI agents, request the tool catalogue and walk through a rejected request, a repeated request and an approved irreversible action. Those are design requirements to verify in the project. They reveal whether the proposal has a business control system behind its conversational interface.