Glossary
A quick reference for the terms you'll meet across the Nexus docs. Each entry is a one- or two-sentence definition with a link to the page that covers it in full. Terms are grouped lightly - the platform and its products first, then the building blocks, then routing, memory, and testing.
The platform and its products
Nexus - the Yellow.ai platform, at nexus.yellow.ai. It brings together smart agents, an in-app AI copilot, custom widgets, and an AI Trust Centre. See Nexus platform overview.
Nexus AI - the in-app AI copilot that lets you build and run your assistant by asking in plain language instead of clicking - creating agents, writing prompts, indexing knowledge, generating tests, and pulling analytics. It always acts on the project you have open. See Nexus AI. (Sometimes referred to as the AI layer or Copilot Nexus.)
Harness - the build product in the Nexus rail: where you author AI Agents, Automation, and the AI Trust Centre. The build → test workflow (Configuration, agents, tools, widgets, testing) lives here. See AI agents.
Atlas - the knowledge product in the Nexus rail: the Knowledge Base your agents answer from, plus the support-portal knowledge base. See Knowledge base overview.
Fabric - the data product in the Nexus rail: customer records and segments (the CDP) your agents read and write. See Customer data overview.
Quickstart - the fastest path from a new project to a working agent you can talk to (about 10 minutes): give it an identity, add one knowledge-base tool, and test it in the Playground. See Quickstart.
Playground - the interactive, single-conversation test panel on every agent's profile (the play ▶ icon in the title bar), where you chat with your agent exactly as a customer would. Your fastest feedback loop while building. See Test your AI agent.
Configuration and agents
Configuration - the project-level settings that apply to all your agents - identity and tone, conversation rules, routing logic, global tools, memory, fallback, lifecycle hooks, and AI safety. Configuration shapes every conversation, rather than being one agent among many. See Configuration.
Single agent - one agent with one prompt. It reads the conversation and decides each turn what to ask, which tool to call, and when it's done. Best for open-ended work - support, troubleshooting, free-form Q&A - where the path depends on what the customer says. See Single agents.
Multi agent - an agent whose work is split across steps you lay out on a flow canvas, with the routes between them drawn by you. Both types use an LLM; the difference is who owns the path. Best for procedures you want laid out explicitly and auditably - order returns, KYC checks, booking flows. See Multi agents.
Agent node - the workhorse node inside a multi agent: an agent that owns one step of the conversation, with its own instructions, tools and exits. It talks with the customer over as many turns as that step needs. It has no trigger and is never picked by routing - the flow hands control to it, and it finishes by choosing one of its exits. See The Agent node.
Routing and handoff
Trigger - the natural-language description at the top of an agent's profile that says when that agent should activate. It's the primary signal routing reads on every turn to pick the best-matching agent. Sometimes called the agent's Start trigger. See Routing Logic. (Inside a multi agent, the Start node carries an equivalent trigger description for the whole flow - see Multi agents.)
Routing Logic - the optional Configuration surface where you write plain-English rules that override or refine how each message is routed between agents and tools. Most projects route correctly with sharp Triggers alone; reach for rules only when you want a deterministic override. See Routing Logic.
Handoff / routing - the runtime act of handing the conversation to a specialist agent, driven by Triggers and any Routing Logic rules. A handoff only fires when something actually triggers routing - an @-mention of an agent in prose is a reference, not a handoff. See Routing logic.
Agent instructions - the rich-text field on a single agent that defines its scope and how it behaves - how it behaves once it has the conversation (as opposed to the Trigger, which is when it takes over). Write them plain, one action per line. See Writing agent instructions.
Tools, workflows, and UI
Tool - an action an agent can take in the real world: run a workflow, search a knowledge base, escalate to a human, transfer a call. Defined once and usable by any agent in the project; a tool's description is what the LLM reads to decide when to call it. See Tools - Overview.
Workflow - a callable, deterministic skill (an API call, a lookup, a calculation, multi-step business logic) built in the visual flow editor. It's a reserved term: a multi agent is not a workflow, though a multi agent can call one. Attach a workflow to an agent as a Workflow tool, or run it from a multi agent's Execute Workflow node. See the Workflow tool.
Knowledge Base - the centralized source of truth your agent answers from: documents, websites, articles, and third-party content, imported and organized in one place. Surfaced to an agent as a Knowledge Base tool. See Knowledge base overview and the Knowledge Base tool.
Widget - a custom, self-contained piece of interactive UI (a form, picker, or multi-step wizard) you design in the Widget Builder and drop into a conversation. When the user fills it out, the result flows back as the next agent input. See Widget Builder.
Memory
Memory - how your assistant retains context about the customer across turns and across agent handoffs. At runtime it's a single key-value pool, shared by every agent in the conversation and separate per customer. The window resets on each customer message and is 60 minutes by default. See Memory.
Global memory - the label the product uses on an agent's profile for variables that are shared across every agent (e.g. customer_id, account_tier), as opposed to ones scoped to that one agent. Once your variables are on unified memory the distinction no longer applies - everything is shared. See Memory.
Journey variable (flow-local) - a variable belonging to one multi agent, carrying values from node to node within a single run. Unlike a global variable it is not shared with other agents and does not outlive the flow run, so anything another agent needs to read has to be global instead. An Agent node reaches one through its Allowed variables, which lists globals, journey variables and user properties together, tagged by scope. See Which scope it belongs in.
AI Trust Centre and testing
AI Trust Centre - the durable, dataset-driven evaluation surface for a Nexus project (a top-level studio nav item). The Playground answers "does this conversation work?"; the Trust Centre answers "is it, overall, getting better or worse, and what should I fix next?". See AI Trust Centre.
Evaluator - a continuous quality or safety score (e.g. Empathy, Accuracy, Hallucination, PII Detector) computed for every agent response, with a tunable threshold. Evaluators make a fuzzy LLM judgement about how good a reply is. See Evaluators & Rules.
Rule - a hard invariant your assistant must always (or never) satisfy, evaluated on every run. Unlike an evaluator's score, a Rule is pass/fail. See Evaluators & Rules. (Distinct from a Routing Logic rule, which controls routing decisions - see above.)
Test case - a saved conversation plus its assertions, used to check behaviour repeatably. The detail panel pairs the conversation with the execution trace that produced it, and lets you edit inputs and re-run. See Test Case detail.
Execution trace - the per-turn, deterministic record of what the agent actually did to produce a reply: every tool call and result, memory write, routing decision, knowledge lookup, and guardrail check, in order. The chat bubble shows what the agent said; the trace shows why. See Reading an execution trace.