Overview
How might we show when the model reaches outside itself so people can trust how an answer was made?
When external tools shape the answer
- Agents that search, browse, run code, call APIs, or touch connectors mid-turn.
- Answers that depend on live data (prices, docs, tickets), not only model memory.
- Products where silent side effects (writes, sends, spends) must stay inspectable.
- Any surface that needs a trail from claim back to the tool that produced evidence.
When chrome would only clutter
- Single-tool products where the only verb is already obvious and chrome would clutter chat.
- Latency-critical mobile replies where each tool badge delays perceived completion.
- Background jobs users should not micro-manage; prefer a summary after completion.
States
Design the call lifecycle, not only a spinner that says “using tools.”
Calling
A tool is selected and parameters are set. The thread shows which capability is about to run.
Running
The call is in flight. Status is visible without dumping raw payloads into the answer.
Returned
A result arrives: summary, artifact, or error. Detail stays expandable for auditors.
Failed
The tool errored or timed out. People can retry or continue without a silent black box.
Synthesizing
The model turns tool output into an answer. Tool steps remain above or beside the reply.
Complete
The turn finished. Tool history stays available for verification after the fact.
Key UX elements
The parts that must be present for tool use to feel transparent.
Say which tool is running.
Search, Calculator, Browser: named capabilities beat a generic “working” spinner.
Show what was asked of the tool.
A human-readable query or expression, not a raw JSON dump in the chat.
Mark running versus done.
A spinner while live, a check when complete, so people know the trail is current.
Surface what came back.
A short result or artifact link. Keep full payloads collapsed until someone opens them.
Let people expand on demand.
Skimmers see the name; auditors open parameters and output without leaving the thread.
Synthesize after the trail.
The reply cites what tools returned. Do not hide the steps that produced the claim.
Anti-patterns to avoid
Silent tool calls that change data with no indicator in the thread.
Fake “Searching…” states when no tool actually ran.
Dumping raw JSON tool payloads into the user-facing answer.
No link from a tool step to the artifact it produced (file, citation, diff).
How products use it
| Product | Implementation |
|---|---|
| ChatGPT | Shows browsing, code, or connector tool activity during agentic runs. |
| Claude | Surfaces tool use (computer, search, skills) in the activity trail. |
| Cursor | Displays terminal, file, and browser tool steps while the agent works. |
| Perplexity | Makes search/research steps visible as the answer is grounded. |
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Tool Use" AI interface design pattern.
Pattern Definition:Frequently asked questions
What is the tool use pattern in AI UX?
Tool use UX shows when the assistant calls external capabilities (search, code, browsers, APIs) and summarizes what each call did, so users understand how the answer or action was produced.
Should every tool call be visible?
Consequential or unfamiliar tools should be visible. Tiny internal helpers can stay collapsed, but anything that spends money, contacts others, or mutates data should be inspectable.
How does tool use relate to plan & execute?
Plan & execute sequences steps for a goal. Tool use is how individual steps reach outside the model. Agents often show a plan first, then tool-call traces during execution.