← All guides

Embodied systems · Explore this field ↗ · Implementation · 4 min read

Avatar behavior state machines: make animation answer to service state

Give an embodied interface clear, interruptible states so its face, voice, and motion communicate actual service conditions instead of invented feeling or false progress.

A model to inspect

Avatar-service state contract

  1. 01Receive service event
  2. 02Check guard
  3. 03Set presentation state
  4. 04Publish text status
  5. 05Handle interruption

The renderer presents verified state; it does not invent it.

Original conceptual diagram · not a live trace or measured result.
01

Start with service truth

List the facts the experience can establish: input available, listening active, speech captured, response preparing, output playing, action awaiting confirmation, job pending, handoff offered, error known, and session ended. Map presentation only from those facts. “Thinking” may mean a request is processing; it must not imply comprehension, concern, or hidden human attention. A pulsing idle animation should never be the sole evidence that work continues.

SCXML is a W3C state-machine notation for control abstraction. You need not adopt SCXML to take its discipline: enumerate states, events, transitions, guards, and final states. A behavior brief written as adjectives—friendly, engaged, reassuring—cannot resolve an interruption or an error race.

02

Make one layer authoritative

Choose an authority for each observable: the speech engine owns playback events; the conversational service owns response readiness; the action service owns pending and completed operations; the renderer owns only how those verified events are presented. The avatar must not declare an action complete because its animation timeline reached a flourish. Likewise, a language response must not command the renderer into “listening” if the microphone permission is absent.

Use an event contract that includes event ID, source, session scope, timestamp, and supersession rule. A late speech_started event from an old turn should not pull the character back into speaking after the user has interrupted or started a new task.

03

Design interruption as a transition

Barge-in, stop buttons, keyboard input, loss of audio focus, navigation, and a new user turn should all reach a defined interruption transition. Stop or fade output according to the channel policy, cancel only the presentation work that is safe to cancel, and inspect any underlying operation rather than assuming it stopped too. Update captions and nonvisual status at the same time.

Worked example, hypothetical: the avatar is reading an answer when the user says “stop.” The system transitions from speaking to interrupted, stops audio and lip sync, preserves the answer as readable text, and displays the next allowed input. If it was reporting a background job, the job remains running unless the user separately requests cancellation and the service confirms it.

04

Avoid fake affective claims

An avatar can be warm in tone, use restrained motion, and acknowledge inconvenience without asserting internal emotion. Avoid lines and gestures that claim to be worried, relieved, watching, remembering a relationship, or personally deciding a case unless those statements are literally true and appropriately disclosed. Do not use eye contact, nodding, or a sympathetic posture as a substitute for a clear consent, error, or handoff status.

This is especially important when embodiment adds social pressure. Give users a text path, captions, reduced motion, and an explicit way to mute or hide the character. The service should remain understandable when the avatar is absent.

05

Publish state accessibly

Status changes need a text equivalent that can be perceived without watching the animation. WCAG’s status-message understanding material explains the need for programmatically determinable status updates that do not move focus. Use this to review states such as listening, processing, action pending, interruption, and failure. Avoid overwhelming assistive technology with every idle movement; announce meaningful service changes once.

The visible state label, caption state, and accessible status should share the same event source. If the avatar is silent but a live region says “speaking,” fix the event contract rather than adding a cosmetic delay. Accessibility is a check on truthfulness as well as a separate interface requirement.

06

Review event races before polish

Test mic permission denial, silence timeout, user interruption during speech, response arrival after a new turn, a tool error during an optimistic animation, job completion after session end, network reconnect, and handoff acceptance. Capture the event sequence and confirm that the final state reflects the last valid event. Keep a transition table with allowed sources and guard conditions.

Success criteria: no animation is the only status channel; a user can interrupt output; consequential service state comes from its owning service; and emotional presentation does not assert unverified mental states. A state machine will not make an avatar trustworthy by itself. It makes contradictions reviewable before they become performance.

Take it into the review

Avatar authority matrix

StateAuthoritative eventPresentationAccessible status
listeningmic activeattentive idleListening
thinkingrequest pendingneutral processingPreparing response
speakingplayback startedlip syncSpeaking
interrupteduser stop eventmotion stopsResponse stopped
action pendingjob acceptedno success gestureRequest processing

A starting artifact to adapt to your service—not a ready-made policy, compliance certificate or test result.

Primary reading

Sources and limits

These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.

  1. W3C State Chart XML (SCXML)
  2. WCAG 2.2 Understanding Status Messages
  3. WAI-ARIA 1.2

What the sources establish

State Chart XML: State Machine Notation for Control Abstraction

SCXML defines a general-purpose state-machine notation for control abstraction.

Limits: It does not prescribe animation behavior, emotional presentation, or conversational policy.

Checked 2026-09-19 · W3C · source publication date not established.

Open original source ↗
Understanding Success Criterion 4.1.3: Status Messages

The WCAG understanding document explains status messages that can be programmatically determined without receiving focus.

Limits: It does not specify an avatar state chart or validate any implementation.

Checked 2026-09-19 · W3C Web Accessibility Initiative · source publication date not established.

Open original source ↗
Accessible Rich Internet Applications 1.2

WAI-ARIA defines semantics that can communicate roles, states, and properties to accessibility APIs.

Limits: ARIA semantics do not guarantee that the underlying service state is accurate.

Checked 2026-09-19 · W3C · source publication date not established.

Open original source ↗

Procedures and worked examples are editorial synthesis. Preparation/review dates are not claimed historical publication dates.

Find your next good decision.

Start typing to explore the guides.

76 sourced guides · Escape to close