Straight answer: standard actions are the pre-built things an agent can do without you writing anything, and they divide cleanly into ones that read, ones that write, and ones that generate text. The read actions are safe to enable broadly. The write actions are the ones to audit line by line, because a standard action’s convenience is exactly what makes it easy to grant without thinking about what it can touch.
The categories
Read actions. Finding records, retrieving details of a record in context, querying related data, answering from knowledge. These return information for the agent to restate. The risk is not damage, it is exposure: whatever the action can read, the agent can quote.
Write actions. Creating and updating records, logging activity, posting to a feed. These change the org. A wrong one is not a bad sentence, it is bad data, and bad data created by an agent is harder to trace than bad data created by a person because the audit trail names the running identity rather than the requester.
Generation actions. Summarising a record, drafting an email, generating text for a field. Output is text for a human to read or edit. Risk sits between the other two: nothing is written directly, but the text may be sent onwards without careful review.
Navigation actions. Opening a record, starting a flow, moving the user somewhere. Low risk, and worth enabling because they make the agent feel connected to the application.
Action names and what ships in each release change, and what is available to an employee-facing agent differs from a customer-facing one. Check the current reference, not a list from an article.
Which ones write
Do not work this out by name. Names are chosen for the interface, and an action whose name sounds like a lookup may create a record as a side effect.
Work through the enabled list one at a time and record three things for each: does it write, what objects does it touch, and what identity does it run as. That last one is the one that catches people, because an action running in system context reaches records the person talking to the agent cannot see, and nothing in the configuration screen warns you.
An example. An action that logs a call sounds harmless. It creates a record with a timestamp, an owner and a related record, all chosen by a model from a conversation. Three weeks later a manager runs an activity report and the numbers are wrong in a way nobody can explain.
Standard versus custom
Standard actions are fast to enable and arrive with descriptions, inputs and outputs already written. The description matters more than it sounds: it is what the agent reads when deciding whether to use the action, and writing a good one is genuinely difficult.
The trade is control. You do not choose what a standard action queries, what it returns, or how it phrases a failure. Where the returned text is shaped for a generic case and yours is specific, the agent’s answer inherits the mismatch.
The pattern that works: standard actions for reads and navigation, custom actions for anything that writes. A custom write action lets you validate, handle errors, return an unambiguous confirmation string, and log the requester.
Enabling deliberately
Three habits worth adopting before an agent goes anywhere near production.
- Start from empty. Enable nothing by default, then add each action because a specific requirement needs it. Capability granted for completeness is capability nobody has thought about.
- Scope actions to topics. An action available in every topic can be invoked from any conversation, which is broader than anyone intends. Attach it where it belongs.
- Test what fires, as well as what answers. Run a set of conversations and check which actions were invoked, including for questions that should not have triggered anything. An action firing when it should not is a failure even when the reply reads well.
Also decide what the agent tells the user when a write happens. For anything consequential, it should state the specific values and wait for confirmation before the action runs.
Frequently asked
Can I edit a standard action? Generally no, though some accept configuration. Where behaviour must change, build a custom action rather than fighting the standard one.
Do standard actions respect sharing? It depends on the action, and the answer is per action rather than a property of the platform. Look each one up rather than assuming they are consistent.
How does the agent choose between two similar actions? By description. Two overlapping descriptions produce inconsistent selection, and the fix is editing descriptions, not the instructions.
Is there a read-only mode? Not as a switch. You get it by enabling only actions that read, which is why the action inventory is the control.
