Intent series

Overview

Intents can be chained into series of two or more that work together in service of a larger objective. Series provide structure to multi-step flows and allow the system to validate that each step is appropriate given the preceding context.

Because each intent has a declared slug and optional trust/capability constraints, validators can enforce that trust intents (e.g. ConfirmDestructiveAction, ConfirmTransaction) are only used where the flow warrants them, and that sensitive steps (e.g. payment, PII) are preceded by the right confirmations or disclosures. Series also support layout budgeting and cognitive-load checks: agents can stay within attention and interaction limits by choosing series that fit the context.

For the full set of intents and their parameters, see the intent library.

Examples

Checkout

Collect details, confirm, then pay and confirm the transaction.

Destructive change

Edit with a final confirmation gate so the user can back out.

Guided choice

Explain context, present options with rationale, capture consent or acknowledgment if needed, then record the choice.

Scheduled send

Compose a message, pick when it should send, confirm, then schedule.

Onboarding or preference capture

Gather consent and preferences before continuing, with clear disclosure.

Branching and errors

A series can include steps that handle failure or choice: after CollectPayment(...) or ConfirmTransaction(...), a failure path might emit ShowError(error, taxonomy) and then offer PickOne(options) (e.g. retry, change method, cancel). The UI‑IR can represent these branches explicitly so that agents and validators reason about both success and error flows without inventing ad-hoc patterns.