3.3.1. Topic Architecture and Orchestration
💡 First Principle: A topic has two faces: the outside (name + description or trigger phrases — how it gets selected) and the inside (the node pipeline — what it does). Most topic bugs are a mismatch between faces: an inside that works perfectly behind an outside the orchestrator can't recognize.
The canvas vocabulary: Message nodes speak; Question nodes ask, validate against an expected entity type, and store the answer in a variable; Condition nodes branch on variables; Tool nodes invoke the Phase 2 arsenal in-line — an agent flow with mapped inputs/outputs (3.2.3), a custom prompt, a connector action, an HTTP request (3.3.3); Topic management nodes compose conversations — redirect to another topic, transfer to an agent, or end. Adding an agent flow to a topic is the marquee integration: select the tool node, pick the flow, wire variables in and out — reasoning delegating to procedure exactly where the conversation needs it.
System topics — Conversation Start, Fallback, Escalate and kin — are the platform's authored responses to conversational events; customizing them (especially Fallback, which fires when nothing matched) is part of architecture, not an afterthought.
⚠️ Exam Trap: Under generative orchestration, a topic that never triggers almost always has a description problem — vague, overlapping with a sibling's, or missing. Under classic orchestration, the same symptom points at trigger phrases. Diagnose by orchestration mode first.
Reflection Question: Two topics — "return an item" and "check return status" — keep intercepting each other's conversations. Which face of each topic do you edit, and what property must the two descriptions have relative to each other?
