Build Your App
Plan Assistant Actions
Design tools that are easy for the model to use and useful for your audience.
A tool is one action your assistant can take on the user’s behalf. Good tools feel obvious to the end user and predictable to the model.
Start With The User Request
Do not begin with your internal systems. Begin with the question or task the user actually has.
Strong starting points:
- “Show me the best plan for a team of 20”
- “Find the right case study for fintech prospects”
- “Check the status of my onboarding request”
- “Collect the details needed for a demo follow-up”
Weak starting points:
- “Access CRM”
- “Run internal workflow”
- “Fetch all account information”
Common GTM Tool Patterns
| User goal | Good tool pattern | Typical output |
|---|---|---|
| Find the right offer | search or recommend options | cards, carousels, tables |
| Understand differences | compare plans, features, or packages | comparison table, summary |
| Get a clear answer | answer a narrow question from trusted content | markdown, accordion |
| Move to the next step | collect information or confirm intent | form, confirmation |
| Prove impact | show metrics or progress | charts, metric cards |
What Makes A Tool Easy For AI To Use
- the name clearly describes the action
- the description explains when to use the tool
- parameters are limited to the inputs that genuinely matter
- the output has a single job, such as browsing, comparing, or confirming
If you need the model to guess too much, the tool definition is too vague.
Keep The Scope Narrow Enough To Be Reliable
One of the easiest ways to make an AI app feel polished is to keep tools focused. Split tools when:
- one tool would require very different inputs for different jobs
- the output format changes completely depending on the request
- one audience needs discovery while another needs transaction or follow-up
Tool Anti-Patterns
A Simple Planning Workflow
- list the top questions users ask
- group those questions into two to five actions
- define one tool per action
- assign the best response format for each tool
- test with real prompts before adding more scope
Before You Publish
- each tool solves one clear job
- descriptions are written for model behavior, not for a landing page
- parameters are minimal and understandable
- the chosen widget matches the decision the user needs to make next