Every Behavior in ABS carries an action field. The action determines which category the Behavior belongs to and, by extension, how target, content, and with should be interpreted.

Rendering diagram…

Action categories

The standard vocabulary is the set an implementation MUST recognize to claim v0.1 vocabulary support.

Communication

Information exchange between actors. These actions primarily use content:

Action	Meaning
`says`	A plain statement or message.
`asks`	A question expecting a reply.
`responds`	A reply to a prior `says`/`asks`/`calls`.
`informs`	Delivers information as a resolution, typically the outcome of a flow.
`greets`	Opens an interaction.
`clarifies`	Disambiguates a prior ambiguous statement.
`confirms`	Affirms a proposed action or piece of information.
`rejects`	Declines a proposed action or piece of information.
`suggests`	Proposes an option without asserting it as fact.
`shows`	Displays structured content (e.g. a list, a card, options) rather than saying it.

Execution

Invoking external systems, tools, or APIs. The target names the system; with carries parameters:

Action	Meaning
`calls`	Invokes an external system, tool, or API. Pair with a `responds` from `tool`/`external` to capture the return value.
`submits`	Sends a completed input (e.g. a form) to a target.
`retrieves`	Fetches data without side effects.
`stores`	Persists data.
`updates`	Modifies existing data.

Interaction

Acting on UI elements:

Action	Meaning
`selects`	Chooses among presented options.
`uploads`	Provides a file or attachment.
`downloads`	Retrieves a file or attachment.
`approves`	Grants explicit approval for a proposed action.

Delegation

Transferring control:

Action	Meaning
`hands_off`	Transfers the interaction to another actor, typically `human`.

Extending the vocabulary

Real deployments will need domain-specific actions (refunds, escalates, schedules, ...). Custom actions:

MUST declare which of the four categories above they belong to, since that category determines how target is interpreted (Specification §4, normative).
SHOULD be documented alongside the Session that uses them.
SHOULD be written as plain lowercase verbs consistent with the style of this table.

A custom action follows the same five-field Behavior shape as any standard action.

Actor/Action compatibility

The "typical actor" for each action is guidance, not a hard constraint in v0.1 — nothing in the conformance rules currently rejects an unusual pairing (e.g. tool performing says). Implementers who want stricter validation should layer additional constraints on top.

Design rationale

Keeping the action vocabulary small and category-based means:

Parsers don't need to know every action. They resolve target from the category alone.
Extensions are forward-compatible. Adding a new action to the Communication category doesn't break existing documents.
The spec stays readable. A product owner can glance at action: calls and know what's happening.

Vocabulary