What actions are and what an AI agent can do with them

Actions let an AI agent do things, not only say them. That is the difference between deflection and service.

Actions let an AI agent do things, not only say them. That is the difference between deflection and service.

What an action is

A defined call to another system, made mid-conversation. Look up an order, check a booking, create a record, change an appointment.

The agent gathers what the action needs from the customer, calls it, and uses the result in its reply.

Four kinds, and one of them is borrowed

Standard actions are not available directly in an AI agent; you reach them through an action flow. Do not go looking for one in the agent's own list.

You attach and manage them from the Actions section in the AI agents workspace, while custom actions themselves are defined centrally in Admin Center.

Why they change the value

Without actions, an AI agent can only tell people what is written down. "Where is my order" gets a policy answer rather than their order.

With one, it answers the actual question. That is the difference between customers tolerating the agent and preferring it.

Start with reading, not writing

Lookups are low risk: the worst outcome is no answer. Actions that change something can go wrong in ways the customer notices, so earn the confidence first.

Order status, delivery date, appointment time. Those three cover a large share of contacts in most businesses.

What an action leaves behind

The result does not have to disappear into one reply. Save it as a session parameter and it stays available for the rest of the conversation, which is how the agent behaves differently for one customer than for another.

That matters because of a trap in the word segment. A segment in the AI agents workspace evaluates session parameters, not fields on the customer's profile. A custom user field holding, say, a support tier does not reach a segment by itself: the value has to arrive in the session first, from chat or widget metadata or an API integration, and then be saved by a Get User action. Build the segment on the field directly and nothing matches, with no error to tell you why.

Check that the parameter exists and that its value is spelled the way the segment expects. And on email AI agents, apply the segment at the use case level rather than inside a procedure.

This is a different thing from the user segments that decide who may read a help centre article, which share only the name.

Every action needs a failure path

The system is down, the number is not found, the customer cannot be identified. Decide what happens in each case, because these are not rare.

Identity comes first

Anything showing personal data needs to establish who is asking. Work out what proves identity in your setting before building an action that reveals anything.

They need somebody technical

Actions are calls to systems with credentials and error handling. That is development work, and it is worth scoping properly rather than treating as configuration.

Two numbers set the boundary of what is feasible: an action times out after ten seconds and accepts a response of up to two megabytes. A system that cannot answer inside that window needs work on its side, not on yours.

See also

• Creating a custom action
• Testing actions
• Creating generative procedures
• Connecting actions to auto assist