ZHOU AZ Contact ↗
Tool
Calling
UX
Trustworthy tool-calling UX starts before the tool runs.
Agents can look confident while doing the wrong thing.
A tool-calling agent may choose the wrong tool, pass an ambiguous argument, overstate a result, or hide a failed system response behind fluent prose. In finance, research, or transaction-like workflows, that breaks trust immediately.
The interface should treat tool calls as inspectable product events. A user should know what the agent is trying to do, which tool will run, what data came back, and what action remains under user control.
Every meaningful tool call needs a visible contract.
Before execution, show intent, tool name, target entity, expected output, and risk level. During execution, show progress as state, not as a generic spinner. After execution, preserve structured evidence in UI rather than only summarizing it in prose.
Failure states are also product surfaces. A good error says whether the problem was configuration, authentication, rate limit, unsupported chain, token mismatch, bad argument, unavailable API, or unsafe action.