Glossary
When a term shows up differently across docs — "trigger" here, "entry point" there — it slows you down. This page pins every term to exactly how Perfox uses it, so you always know what something means when you see it on the canvas or in a response.
These definitions are for builders: people writing agents, connecting providers, and reading API responses. If a concept has its own page, a link takes you there — you don't need to read both; the dedicated page goes deeper.
Worked example
Here's a short scenario that touches most of the terms below. Asha is setting up a support agent for Acme Diagnostics.
Setup. Asha creates an agent on the canvas with a WhatsApp trigger. She attaches a Personality sub-node with the agent's name and a system prompt describing how to help customers book lab appointments, connects an MCP server that talks to Acme's booking system on the Integration port, and adds a WhatsApp Sender on the Action port so the agent can reply.
Action. A customer named Priya sends a WhatsApp message: "I need to book a blood test." Perfox resolves Priya's identity from her phone number, matches the trigger, and runs the agent. The AI Agent node sends a tool call to the MCP server, which returns available slots. The agent replies to Priya with the options.
Result. Priya picks a slot and confirms. The MCP server records the booking. The agent confirms the booking to Priya through the WhatsApp Sender.
What just happened. The Trigger handled the inbound channel, the AI Agent node ran the conversation, and the MCP server held all the booking logic. The canvas controlled the order; no business rules were written on the canvas itself.
Agents & the canvas
| Term | Meaning |
|---|---|
| Agent | A graph of typed nodes you author on the canvas and then Activate. It owns the orchestration and conversation flow, but no business knowledge — your business rules and data live in your own connected MCP server. See What is Perfox?. |
| Node type | One of the building blocks you drop on the canvas, each running as a step in your flow: triggers, AI Agent, Agent Team, Email / SMS / WhatsApp Sender, Condition (IF/ELSE), Human Handoff, Collect Info, Look up Data, HTTP Request, Render View, Track Event, Document Processing, and more. See Canvas Basics. |
| AI Agent node | The conversation engine at the centre of an Agent — persona, language, and tool selection — with no domain knowledge baked in. Its behaviour is identical whether the customer arrives by chat, WhatsApp, phone, SMS, or email. |
| Sub-node | A helper node you attach to an AI Agent node to configure one aspect of it. Sub-nodes are resolved inline as part of the agent rather than run as their own flow step. The AI Agent's ports are Personality, AI Model, Integration, Knowledge, Action, Operator and Steps. |
| Action node | A node on the AI Agent's Action port that gives the agent a concrete action: send an email, SMS or WhatsApp message, place a phone call, make an HTTP request, append a row to Google Sheets, query a database, extract data from a document, save a document to the customer's file, or hand off to a human. |
| Edge / connection | How nodes are wired together. A standard flow edge controls the order steps run in; a sub-node edge attaches a helper (Personality, AI Model, Integration, Knowledge, Action, Operator or Steps) to an AI Agent node. |
| Sticky note | A canvas-only annotation you add for your own notes. It is ignored when the agent runs. |
| Personality | The one place you author your agent's identity and behaviour. Every AI Agent node has exactly one Personality, where you set its name, role, tone, language (plus a fallback language and the language behaviour), region and greeting — and write the system prompt that is the single source of truth for how the agent behaves. See Persona. |
| Trigger | The entry point of an Agent. You pick the kind of trigger from the canvas + → Triggers: a channel (Phone Call, SMS, Email, WhatsApp, Web Chat), Webhook, Schedule, Internal Event, Knowledge Base, Folder Watch, Sub-Workflow or Manual Test. See Trigger Nodes. |
| Condition (IF/ELSE) | A branch node that routes your flow. Its conditions may reference only metadata about the run — the agent's exit reason, the channel, the trigger type, or a decision flag returned by one of your MCP tools. Branching directly on a raw business field is intentionally blocked, both when you publish and when the agent runs, because business decisions belong in your MCP tools. See Agents and MCP. |
| Exit reason | A named exit your AI Agent can emit to signal how a stage ended. A Condition (IF/ELSE) node is allowed to branch on it, because it is metadata about the run rather than a business field. |
Automations
| Term | Meaning |
|---|---|
| Scheduled agent | An ordinary agent whose trigger is Schedule, so it runs on a timetable you set. Active schedules are listed under Admin → Developer → Scheduled Jobs. Outbound campaigns are just such an agent; there's no separate engine to learn. See Automations. |
| Sender | An Email Sender, SMS Sender or WhatsApp Sender node. On the AI Agent's Action port it lets the agent reply and send messages on that channel; without one, the agent can't reply on email, SMS or WhatsApp. See Channels Overview. |
Providers & credentials
| Term | Meaning |
|---|---|
| BYOP | Bring Your Own Provider. You connect your own accounts for the providers your agent talks through (Plivo, your email provider, storage, databases, Google Sheets) and Perfox uses them at run time. AI models, storage, semantic search and web voice are included and managed by Perfox. See BYOP. |
| Provider types | The providers you can connect on the Connections page, grouped as Telephony & messaging, Email, Storage, Databases and Integrations. See BYOP. |
| Connection | A stored provider credential you configure on the Connections page. Each provider has its own required fields and a one-click Test button so you can confirm it works before your agents rely on it. Managed infrastructure and connections handled by the Integrations page are set up for you and do not appear here. |
| Three-layer model | Agent (orchestration) → AI Agent node (conversation) → your MCP server (all business logic and state). See What is Perfox?. |
Channels & identity
| Term | Meaning |
|---|---|
| Unified inbound | Every non-voice channel flows through one shared inbound path: resolve identity, match a trigger, then run the matched agent. A message no trigger watches gets no reply. Duplicate deliveries are handled for you, so the same message never triggers two AI replies — even if a provider delivers it twice. |
| Customer | The end-user — the person your agent talks to, not your business. Perfox resolves identity by phone, then email, then WhatsApp, and normalises phone numbers to a single canonical format, so the same person across web, WhatsApp, phone, and email is recognised as ONE customer. See Customer Identity. |
| User context | The all-optional identity payload you pass to the widget's identify / update calls: name, phone, email, external_id, attributes, plus a verification hash and session token. It is attached to the conversation and forwarded to your MCP tools. See User Context. |
| external_id | Your own system's stable customer ID — the strongest identity anchor, and the field the verification signature covers. |
| attributes | A free-form key/value map on user context for any custom fields that aren't part of the standard schema, so you can attach your own data without waiting on a schema change. |
| Trust level | How confident Perfox is about who the customer is: anonymous (no external_id), self-asserted (an external_id supplied without a valid verification hash), or verified (an external_id with a valid verification hash). |
| Anonymous (start) | Every conversation starts as anonymous, even when a channel asserts an identity such as caller ID or a phone number — that is a low-trust signal, never proof of the human. Elevating a conversation to authenticated is your explicit decision via the auth-context callback. See Authentication. |
| Verification hash | A cryptographic signature over the combination of your site ID and the customer's external_id, keyed by your site secret. Perfox validates it against every active and expiring site secret, so you can rotate secrets without breaking verified sessions. See Identity Verification. |
Sites & the widget
| Term | Meaning |
|---|---|
| Site | A Web Chat embed credential set, created on the Web Chat trigger's Install tab with Generate Credentials. Creating a site returns its secret (starting sa_secret_live_…, shown once — copy it immediately); the site ID never changes; suspending a site hard-blocks new conversations. Each site allows up to two active and two expiring secrets at a time, so you can rotate safely with overlap. See Site Management. |
| Widget | The embeddable chat UI — a self-contained Shadow-DOM bundle with a history sidebar, new-chat control, transcript export to Markdown, fullscreen, diagram rendering, and structured-data cards. For custom front-ends, a framework-free headless SDK powers the same experience. See Embedding. |
MCP
| Term | Meaning |
|---|---|
| MCP | Model Context Protocol — the contract your agent uses to call your tools. Every tool call passes through the gateway, which discovers the tool, validates its input, applies your tool and rate-limit policies, caches where allowed, injects your credentials, invokes the tool, and records an audit entry. See MCP overview. |
| MCP gateway | The managed layer in front of your MCP servers. It enforces a per-tool rate limit and returns a clear rate-limit error to the caller when a server's configured limit is exceeded, protecting your backend from overload. |
| MCP server | A registered MCP server in your workspace. You give it a name, description, and URL, choose its transport, pick its authentication method (none, bearer token, API key, basic, or OAuth 2), point it at a stored credential, and optionally tune its rate limit, request timeout, and cache duration. Perfox discovers its tools and tracks its health for you. See Registering an MCP server. |
Knowledge Base
| Term | Meaning |
|---|---|
| KB | Knowledge Base — semantic search over the files you upload. Perfox chunks and embeds each file so your agent can answer questions grounded in your content, while the original files are kept safely in object storage. Whether you upload directly, sync a connector, or add files through the API, everything converges on the same indexing pipeline. See Knowledge Base. |
Memory
| Term | Meaning |
|---|---|
| Agent memory | What an agent remembers about a customer across conversations: facts they've shared, their preferences, and what earlier conversations covered. On by default and controlled per agent in the AI Agent's Memory section. See Agent Memory. |
| Remember this customer | The Memory switch that lets the agent recall what it already knows about the person. Turn it off for an agent that treats every conversation as a fresh start. |
| Key facts | A short running profile of what matters about a customer, which the agent carries into every turn so it doesn't ask again (Keep a running set of key facts). |
| Persistent memory | Notes your team keeps about a customer on their Profile tab in Engage → Customers, which last across sessions. |
API keys & IDs
| Term | Meaning |
|---|---|
| Scope (API key) | A capability tag on a workspace API key — for example, permission to manage documents or the knowledge base. Every route is deny-by-default and requires the matching scope, so a key can do exactly what you granted and nothing more. Create keys under Admin → Developer → API keys. See API Keys. |
| UUID v7 | The identifier format used for every record: time-sortable and globally unique, so records naturally sort in chronological order. See Design Principles. |
You can now speak Perfox
You know what every term on the canvas and in these docs means, and you've seen how they fit together in a real flow. When you're ready to go deeper:
- Design Principles — the reasoning behind choices like UUID v7 and the three-layer model
- Technology Stack — what Perfox runs on and what you bring yourself
- Agents and MCP — how the Agent, AI Agent node, and your MCP server divide responsibility
- Agent Memory — what agents remember about customers and how to control it