An agent that drafts an email and an agent that sends it can look almost identical in a chat window. Both accept a request and produce a reassuring answer. Only one has contacted a customer.
That difference shapes how I think about agent tools. A model can be wrong in either case, but the consequences depend on what the surrounding software allows it to do. Better prompts help. They cannot carry the whole responsibility for permissions, validation and recovery.
Look at the action, not the tool name
Labels such as “API access” or “database access” are too broad to tell you much. Reading a public price feed, changing an address and issuing a payment might all be API calls. They deserve different controls.
Before giving an agent a capability, I want to know what it can change, whose information it can reach and whether the result can be undone. Read-only access also needs boundaries: a tool that cannot edit anything can still expose information it should never have retrieved.
For local, reversible work, I want the agent to move without constant interruptions. For an action that reaches a customer, changes permissions or moves money, the allowed scope needs to be much more precise.
Separate preparation from commitment
The most useful place for a review is after the agent has done enough work to make the decision concrete. “May I update these records?” tells me little. A preview of the exact records, the proposed changes and the expected effect gives me something I can assess.
That suggests a simple division: let the agent investigate and prepare; give the final action a narrower interface. A draft can be revised. A proposed change can be validated. Sending, charging or publishing happens only when the conditions for that action are met.
Human approval is one possible condition, particularly for an unfamiliar or consequential action. In other cases, an explicit policy can authorise a limited class of actions. What matters is that the permission comes from the system, rather than from the agent deciding its own proposal looks reasonable.
Design for the second attempt
Tools fail in awkward ways. A request can time out after the service has already accepted it. If the agent simply tries again, one intended action can become two.
For a payment or booking, the receiving system should recognise a repeated request as the same operation. The agent also needs a way to inspect the outcome before deciding what to do next. A confident retry is not a substitute for knowing whether the first attempt succeeded.
I want tool responses to make those distinctions visible: completed, rejected, pending or unknown. Clear failure states are as useful as clear input schemas.
Keep authority outside the conversation
The agent can propose the arguments for a tool call. The application should still validate their shape, check the relevant permissions and enforce the business rules. A well-formed request is not automatically an authorised one.
These controls do not make an agent infallible. They make its mistakes easier to contain, inspect and recover from. That gives me a firmer basis for expanding its autonomy than another paragraph telling it to be careful.