An Action lets the agent call something in your system — look up an order, check a subscription — and use the result in its answer. Instead of responding with generic text, the agent can reach out to your tools in real time and come back with specific, accurate information.
What this means in practice
Most AI assistants work from a fixed snapshot of knowledge. They can answer questions about things they were trained on, but they can't check what's happening right now in your systems.
Actions change that. When a visitor asks "where's my order?", an agent with a tracking action doesn't guess — it calls your order API, gets the live status, and tells the visitor exactly where things stand. The answer comes from your system, not from a language model's general knowledge.
This is the practical difference between an assistant that answers and one that gets things done.
Real-world examples
Order lookup — A customer types "has my order shipped yet?" The agent calls an order-lookup action with the order ID, gets back a carrier name and estimated delivery window, and replies with the specifics. No ticket needed, no hand-off to a support agent.
Account and subscription checks — A user asks whether their plan includes a feature they want. The agent calls an account-status action, confirms the current plan tier and renewal date, and answers the follow-up questions about billing without putting the user on hold.
Internal knowledge search — For technical questions, the agent searches your product documentation or internal knowledge base through a search action. Instead of a generic suggestion, the visitor gets the relevant section of your actual docs.
Conversation handoff — When an issue is too complex or the visitor explicitly asks for a human, the agent calls a handoff action that opens a support ticket or live chat session. The conversation history transfers automatically so the human agent doesn't start cold.
How an action is defined
Each action has three parts: a name, a description the model reads to decide when to use it, and typed input parameters. The description does most of the work — it tells the model when this action is appropriate, not just what it does. A lookup action for orders should say something like "use this to check order status when a customer provides an order number," not just "gets order status."
The inputs are defined with types and descriptions too. If an action takes an order ID, you specify that it's a string, whether it's required, and what format to expect. The model uses this to extract the right value from the conversation before calling the action.
The permission model
Every action has a run policy:
- Auto — the agent calls the action whenever it judges it appropriate, without asking first
- Confirm — before running, the visitor sees exactly what is about to happen and can approve or cancel
Read-only actions — checking an order status, looking up an account — are generally fine on auto. Actions that send messages, trigger refunds, update records, or do anything that can't easily be undone should use confirm until you've validated the behavior.
The confirm policy puts the decision in the visitor's hands without requiring a human agent to be involved. The agent proposes; the visitor approves.
Enabling and disabling actions
You can switch any action on or off from the Actions settings page without touching your codebase. Toggling an action inactive means the agent stops calling it immediately — useful during a schema change, an API outage, or when you're rolling out a new action and want to test it with a subset of traffic first.
If you disable an action the agent was relying on, it falls back to answering from its training context and will tell the visitor it can't access that information directly right now.
The audit trail
Every action run is logged — which action ran, what inputs were passed, what came back, how long it took, and which conversation triggered it. Nothing happens invisibly.
You can review the full history under Action Runs, filter by action name or date range, and inspect the exact payloads that passed between the agent and your system. When something returns an unexpected result, the audit log is the first place to check. It also helps when you're tuning an action's description — you can see exactly which conversations triggered it and whether those calls made sense.