Actions
Controlled follow-through, so what was agreed in a conversation becomes a change in a system.
Actions are the execution layer. Summaries and signals turn a conversation into structured intelligence; actions turn that intelligence into a change somewhere: a record updated, an owner assigned, a process started, a message sent.
What they are used for
- Creating or updating records in a system of record.
- Assigning owners, setting dates, routing work to a team.
- Starting a downstream process in a repeatable way.
- Publishing a structured output to an approved internal channel, with its context and provenance.
- Attaching conversation-derived context to an object so the next person has it.
Where they sit
Actions are the end of the pipeline, not a standalone feature.
- Conversations provide the evidence.
- Signals capture the interpretation.
- Knowledge supplies durable context.
- Tools ground and validate it.
- Actions carry out the follow-through.
The order matters. An action should be driven by evidence and structured interpretation rather than by inference over a transcript.
What makes an action safe
Clear intent. An explicit operation, not free text open to interpretation.
Scoped context. Executed with a bounded envelope: the organization, the person, the agent version, the conversation, the records and the signals involved.
Policy and permissions. Constraints by record type and field, approvals where required, and role-based control over who can start, approve or run one.
Safe repetition. No duplicates, retries that do not double-apply, failures that degrade rather than corrupt.
Provenance. Logs that link the action back to the conversation and the signals behind it.
When they run
- In session, while the intent is fresh, under explicit permission.
- After the session, once summaries and signals exist and have optionally been reviewed.
- Assisted, where the agent proposes and a person confirms.
- Gated, where an approval is required before anything happens.
The gated case is the common one in practice, and it is worth designing for: an automation that stops and asks a person is usually better received than one that acts and explains later.
Where this lives in the product
Actions are strung together as automations in the console: a trigger plus an ordered chain of actions, built from a template. Their runs, and the approvals they pause on, are readable in the console and on the phone. See Automations on mobile for the full set of action labels and run statuses.