watsonx Assistant Fundamentals and Architecture
What this domain tests
This domain checks whether you can explain how a watsonx Assistant is assembled and how a live request travels through it. Expect questions on the assistant resource, actions, knowledge, extensions, channels, draft/live environments and where state is stored.
Core rules
- An assistant is the top-level container. It owns actions, knowledge bases, extensions, environment settings and channel deployments.
- Runtime flow: a channel receives input, the assistant selects an action or dialog path, steps may ask questions, set variables, search a knowledge base, use a prompt or call an extension, then a response returns to the channel.
- Actions are goal-oriented flows; classic dialog uses intents, entities and nodes. Do not treat them as interchangeable.
- Variables have scope. Action variables are local to a flow; session variables persist for the conversation; environment settings belong to draft or live.
- Draft is for editing and preview; live serves production channels. Publishing is a deliberate promotion, not automatic.
- Knowledge retrieval and LLM prompts are optional capabilities invoked by steps, not automatic behavior for every turn.
Worked example
A web-chat user types “reset my password.” The assistant matches a reset-password action. Step 1 asks for the account email and stores it in an action variable. Step 2 calls a custom extension that checks identity. Step 3, only if the extension returns eligible=true, says a reset link was sent. Otherwise it routes to a support handoff. No LLM is needed; the path is deterministic and auditable. Reasoning: the action owns the goal, the extension owns the external check, and variables carry data between steps.
Traps
Assuming a knowledge base answers every question; confusing draft edits with live behavior; putting secrets in session variables; and forgetting that channel capabilities constrain response format.