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 — This is built in rather than an action. When the AI can't answer (and lead capture is on, as it is by default), the widget offers the visitor an "or talk to a human now" link; taking it stops the AI on that conversation and alerts you, and the whole conversation is already in your inbox, so you don't start cold.
How an action is defined
Each action has a name, a description the model reads to decide when to use it, typed input parameters, and the request it sends: a GET or POST to an endpoint URL on your API, with optional headers and a JSON body. 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 agent's Actions tab without touching your codebase. Toggling an action inactive means the agent stops calling it immediately — useful during a schema change, an API outage, or while you try a new action with its Test button before the agent can use it.
If you disable an action the agent was relying on, it answers only from your sources; when they don't cover the question, it says it doesn't have that information and offers to connect the visitor with your team.
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 50 most recent runs under Recent runs on the agent's Actions tab, each with its status, the action's name, the inputs it was given, the HTTP status and how long it took. To see what your API sends back, run the action with its Test button. 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 each run's inputs and whether those calls made sense.