Creating Agents

Agents are AI-powered voice assistants that can handle phone calls, chat conversations, and more. Each agent has its own personality, instructions, voice, and set of tools, making it a fully autonomous representative of your workspace. You can deploy agents to inbound phone numbers, outbound campaigns, or embed them as chatbot widgets on your website.

Creating with Operator

Operator is the AI-powered assistant built into Cloudax Connect that helps you create and configure agents through natural conversation. Describe your ideal agent in plain English, for example, “a friendly dental receptionist that books appointments and answers insurance questions”, and Operator will generate an optimised system prompt, select an appropriate voice, and pre-configure relevant settings. This is the fastest way to get an agent up and running, and you can refine every detail afterwards.

Operator is also available in the agent editor's right-hand panel. Use it to review or change instructions, greetings, voice and speech settings, call handling, knowledge, compliance and integrations. It can also create, edit, disable, test or remove tools and webhooks, run agent tests, and review or restore version history, subject to your workspace permissions.

Changes Operator makes in the editor remain a draft until you deploy them. When you ask Operator to deploy, the normal Deploy review opens so the complete editor draft is saved and published together.

Onboarding Wizard

After Operator creates your agent, the onboarding wizard guides you through five essential configuration steps:

Arrange the Agent Editor

The agent editor works like a flexible tabbed workspace. Use the menu tab to open settings such as Tools, Webhooks, Knowledge and Integrations, then drag tabs between groups or split them up, down, left or right.

• Right-click a tab to close it, close nearby tabs, pin it, move it to another group or create a split.
• The menu and Operator are regular tabs: move or close them like any other tab. If every document is closed, the menu remains available so you can reopen one.
• Your layout is remembered when you leave and reopen the agent.
• To return to the original arrangement, open View and choose Reset Workspace.

Use Help in the editor header to open documentation and release notes, report an issue or send product feedback.

Test Agent

Open Test Agent in the main workspace to call the deployed agent, or preview your unsaved changes. The Conversation view combines the live transcript with tool activity, including whether a tool is running and the result it returned.

Use the other views to inspect tool calls, response timing, the effective configuration and connection events. Ending a test call returns the tab to its setup screen, so you can change the agent and test again without reopening it.

Managing Agents

Once you have a few agents, the Agents page becomes the central control panel. It supports a handful of conveniences for keeping a busy workspace tidy.

Organise agents into folders

When a workspace grows to dozens of agents, folders keep the list manageable. Group agents however you work, for example Sales, Demos, or a folder per client project. Folders are shared across your whole team, so everyone sees the same structure, and an agent always lives in at most one folder.

Rename or delete a folder from the kebab (⋮) menu on its chip. Deleting a folder never deletes the agents inside it; they simply move back to Unfiled. Read-only members can browse and filter by folder but can't create, rename, reorder, or delete them.

Pin agents to the top

Right-click any agent on the Agents page and choose Pin to top to keep your most-used agents at the top of the list, regardless of the active sort or filter. A small pin icon shows next to the name so you can spot pinned agents at a glance. Pins are stored per-user per-workspace . They don't leak between orgs and don't affect anyone else on your team. Right-click again and choose Unpin to remove the pin.

Per-agent access control

Workspace admins can lock individual agents down to specific team members. Right-click an agent and choose Manage access, then flip the per-member toggle. Restricted members lose the agent everywhere: the Agents list, the editor, call logs, dashboards, wallboards, and Operator; and can't open it by URL either. Admins always bypass restrictions, so you cannot lock yourself out. See Per-Agent Access Control in the Roles & Permissions docs for the full behaviour, including how it interacts with call-log scopes.

Multi-user editing & presence

The agent editor shows live presence avatars for everyone on your team currently in the same agent. Hover an avatar for the member's name and which tab they're on, so you can collaborate without stepping on each other's edits. Saves are atomic per-section: if two members modify different tabs, both changes land cleanly; if they touch the same field, the second save wins and the editor flags the conflict.

Version history

Every commit records the agent's configuration and every deployment selects a committed version for new calls. Open Versions from the editor menu to review commit messages and compare two versions in the main workspace. Restoring an earlier version creates a new commit, preserving the history you restored from. Active calls keep the version they started with; see Deploying Changes below.

Deleting agents

Right-click an agent and choose Delete to remove it. Agents can be deleted even if they have already taken calls, useful for clearing out old test or duplicate agents. The agent and its call history are removed, but your billing and usage records are kept: they live in a separate ledger, so deleting an agent never changes anything on your invoices or reports.

System Prompt

The system prompt is the single most important piece of your agent's configuration. It tells the AI who it is, how it should behave, and what it should (and should not) do during a conversation.

What the System Prompt Controls

• Personality: the agent's tone, demeanour, and conversational style (e.g. formal, friendly, empathetic).
• Instructions: step-by-step guidance on how to handle different scenarios, gather information, and resolve queries.
• Constraints: hard boundaries on what the agent must never do, such as making promises it cannot keep or discussing competitor products.
• Response style: whether the agent should be concise or detailed, use bullet points, confirm understanding, or ask clarifying questions.

Writing Effective Prompts

A well-structured system prompt typically follows this pattern:

1. Identity: start with who the agent is and which workspace it represents.
2. Objective: state the primary goal of the conversation (e.g. qualify leads, book appointments, resolve support tickets).
3. Process: outline the steps the agent should follow, in order.
4. Rules: list explicit do's and don'ts.
5. Fallback: define what the agent should do when it cannot help (e.g. transfer to a human, take a message).

Conditional Start Messages

Open Start messages to set the greeting callers hear first. The default message is used when no conditional rule matches. Add conditional messages when different callers or situations need different introductions.

Variables found in your prompt and greetings are offered while building rules. Call fields use fixed choices, such as Inbound call and Outbound call, so the saved value is unambiguous.

Multilingual Conversations

If your agent will handle calls or chats in more than one language, you must tell the LLM so explicitly in the system prompt. Choosing a multilingual STT model only handles transcription; the LLM itself still needs an instruction to speak and understand multiple languages, otherwise it will default to a single language regardless of what the caller uses.

Open the agent's system prompt and add a clear multilingual statement, for example:

You are a multilingual customer service representative. Detect the language the caller is speaking and respond fluently in that same language. If the caller switches languages mid-conversation, switch with them and continue naturally.

You can be more specific where it helps: list the exact languages you expect to support (e.g. “English, Spanish, French and German”), and tell the agent how to handle a language it does not speak (typically: apologise and offer to transfer to a human). Pair this with an STT model that supports those languages and, where appropriate, a TTS voice that can pronounce them naturally.

Prompt Variables

Drop double-curly tokens into your system prompt, start message, and post-call email or SMS templates, and Cloudax Connect substitutes them at runtime: no need to hard-code dates, numbers, or call-direction logic per agent. The variable picker on the prompt editor (type {{ to open it) lists every available token with a live example. The built-in tokens fall into three groups.

Date & time

These resolve from the clock at the moment the prompt is sent, so the agent always knows the current date and time. UK tokens use Europe/London and adapt to GMT/BST automatically; US tokens use America/New York (Eastern).

Call & caller (voice only)

These resolve from the live call context, so they only carry a value on voice calls; in a web-chat session they have no caller and are left blank. The prompt editor hides them from chat agents for that reason.

Use them anywhere natural, e.g. “{{greeting_uk}}, you're through to Acme Sales” or “This call to {{customer_number}} is being recorded”.

Dynamic & campaign pass-through variables

Beyond the fixed tokens above, any per-call data attached to an outbound call is passed straight through to the prompt as a variable. This is how campaigns personalise each call; the contact's details and any custom metadata become tokens you can reference by name.

• Contact details: the contact's name is available as {{contactName}} (and the alias {{customerName}}), alongside any other fields carried on the call.
• Custom metadata keys: every metadata field passed with the call is exposed by its raw name and an auto-generated camelCase alias, so account_id is reachable as both {{account_id}} and {{accountId}}. Common examples are {{campaignId}} and {{customerName}}.
• SIP X-headers: inbound SIP headers are captured and made available by their raw header name or configured alias (e.g. {{providerCallId}}), which is where {{unique_call_id}} is sourced from.

See Post-Call Actions for the separate set of post-call variables (summary, sentiment, key topics, action items, and more) used in follow-up emails and SMS.

Filling variables on test & web calls

Custom variables aren't only for campaigns; you can supply them on test/preview calls and on the web calls you share with others.

• Testing & previewing: when you press Test Agent or Preview Changes and your prompt or start message contains custom variables, a short Call variables form appears first so you can type in a value for each one. The agent then greets you with the real details instead of the raw {{placeholder}}. Built-in tokens (date, time, caller number, and so on) are filled in automatically and are never asked for. Leave a field blank to send no value.
• Shared test link: the shareable test page (View → Open shareable test page) accepts values in the URL, so a link can arrive pre-filled. Pass a JSON blob as ?vars={"name":"Sam"} or individual keys as ?var.name=Sam&var.account_id=123.
• Embedded voice widget: add a metadata object to the widget's CloudaxAgentConfig snippet and those values flow into the same prompt and greeting variables, so the agent can address a visitor by name or reference their account from the first word.

Uninterruptible Lines with <Disclaimer> Tags

Wrap any line in your system prompt, start message, or post-call message with <Disclaimer>…</Disclaimer> and the agent will speak the wrapped text without letting the caller interrupt: perfect for legal disclosures, recording notices, compliance scripts, and warnings that must be heard in full. In a start message, the presence of a disclaimer protects the complete opening greeting. Normal turn-taking resumes after the protected wording finishes.

Drop the tags inline anywhere in your prompt or message; they can wrap a single sentence, several sentences, or be repeated multiple times in the same script. For example:

Hi, you're through to Acme Health. <Disclaimer>This call is being recorded for quality and training purposes, and may be reviewed by a clinician.</Disclaimer> How can I help today?

• Caller can't barge in: the agent finishes required wording even if the caller starts talking. If a start message contains a disclaimer, its entire opening greeting plays in full.
• Works with prompt variables: disclaimers can include tokens like {{agent_number}}, e.g. “<Disclaimer>Calls to {{agent_number}} are recorded.</Disclaimer>”.
• Multiple disclaimers per prompt are supported. Each required block is delivered in full whenever its surrounding instructions call for it.

Advanced Settings

Beyond the core configuration, agents support a range of advanced settings to fine-tune their behaviour for specific use cases.

Memory

When memory is enabled, your agent retains context across multiple calls with the same contact. This means it can recall previous conversations, reference past issues, and build rapport over time. Memory is stored per-contact and can be viewed or cleared from the call logs.

Privacy & Compliance

Open Advanced and use Privacy & Compliance to choose which call data the agent retains:

• Save call audio: retain an audio recording after the call.
• Save call transcripts: retain the written conversation. Turning this off does not stop the agent from understanding and answering the caller during the live call.
• Delete recording and transcript if caller declines: when a caller explicitly refuses or asks to stop recording, remove retained call audio, transcript and transcript-derived results. The call can continue without retention.

Audio and transcript retention are independent. For campaign calls, data is retained only when it is enabled on both the agent and the campaign.

Call Settings

Fine-tune how your agent handles the mechanics of a phone call:

• Block unknown numbers: reject inbound calls that arrive with anonymous, withheld, restricted, unavailable, or unknown caller ID (including sip:[email protected]) before any session starts. The caller hears a busy tone (the trunk responds with a SIP busy status), outbound calls are unaffected, and blocked attempts appear in the call log with a Blocked – unknown caller badge.
• Auto end call: automatically terminate the call after a period of silence or when the agent determines the conversation is complete.
• End call message: a closing message the agent speaks before hanging up, such as “Thank you for calling. Have a lovely day!”
• Noise cancellation: filters out background noise from the caller's audio to improve transcription accuracy.
• Background audio: play ambient sound during the call to make outbound dialling feel a bit more human and to hide short silences while the LLM thinks. Pick from: office (default), city street, crowded room, forest, hold music, keyboard typing, or busy keyboard typing.

Call Transfer

Configure your agent to transfer calls to human operators or other phone numbers when it cannot resolve an issue. You can define multiple transfer targets with labels (e.g. “Billing Department”, “Technical Support”) and set conditions for when each transfer should be triggered. Transfers use SIP REFER for a seamless handoff.

Transfer Hours

Limit each human transfer destination to the hours when someone is available to answer. Direct phone transfers, departments, custom routing, and contact-centre DDI, extension, and queue targets each keep their own schedule.

Custom Caller ID Name on transfers

Each transfer destination can carry its own Caller ID Name (e.g. Acme Sales). The name is forwarded on the SIP From display-name when the agent dials the receiving handset, so the supervisor immediately sees who the call is for. Per-destination CNAM is supported on:

• Static Department lists configured on the agent.
• Contact Centre DDI, extension, and queue targets (see Contact Centre below).
• Department nodes in the visual flow editor.
• Values returned by a custom routing API response: if your backend chooses the destination at runtime, you can return a CNAM alongside the destination address and we forward it.

If a transfer destination has no Caller ID Name set, the agent falls back to the default Caller ID Name configured on the imported phone number (see Phone Numbers). Per-target values always take precedence over the number-level default.

Contact Centre

Sit your AI agent in front of an existing contact-centre platform. The Contact Centre tab on the agent editor lets you configure a deep, bidirectional integration with your SIP trunk and PBX, useful when you want the agent to triage inbound calls and hand off to live queues, departments, or specific handsets without losing the original call context.

Inbound SIP X-Headers

Capture custom X- headers on the inbound INVITE (e.g. X-Call-ID, X-Account-Id) and make them available to the system prompt, the call metadata, and any outbound templating. You can:

• Toggle Capture X-Headers on or off: requires the inbound trunk to be provisioned with include_headers: SIP_X_HEADERS or a headers_to_attributes map.
• Nominate a Unique Call ID Header (typically X-Call-ID) so the platform can correlate the call with your contact-centre's own call record.
• Define header aliases that map raw header names to template-friendly keys (e.g. X-Call-ID → providerCallId) for cleaner prompt and metadata access.

Transfer Targets

Define the destinations the agent can hand off to. Three target types are supported:

• DDI: a direct dial number (E.164). Use for a single handset, supervisor desk, or external skill-based number.
• Extension: an internal extension on your PBX, optionally combined with a DTMF post-dial sequence to navigate IVR menus on transfer.
• Queue: a contact-centre queue. The agent hands the call off via the per-target webhookUrl, falling back to the assistant-level queue_handoff webhook if no per-target URL is set. See Queue handoff webhooks below.

Each target can also carry its own custom Caller ID Name, custom outbound SIP headers, transfer schedule, and (for queues) a farewell message the agent speaks before handing off.

Outbound Defaults

Configure default SIP headers attached to every outbound and warm-transfer leg, plus a list of inbound headers to forward through to the receiving system. This is what lets your contact-centre platform stitch the agent leg back together with the original caller record.

Agent-to-Agent Handoff

Mid-conversation handoff between two AI agents in the same workspace, available on both voice and chat. Open the Agent Handoff section on the Advanced Features tab, pick the agents your main agent is allowed to hand off to, and give each one a slug, description, and optional intro message.

The LLM gets a transfer_to_<slug> tool for each target: when it decides to use one, the target agent's full stack (system prompt, voice, STT, LLM, tools, knowledge bases) takes over for the rest of the call or chat. The target can hand back to the parent agent when it's done, and a configurable max-depth loop guard stops handoffs running away. Self-loops are rejected server-side, so an agent can never be its own handoff target.

Agent-to-agent handoff is distinct from Call Transfer and Contact Centre queue handoff; those two hand off to humans on a SIP endpoint. Agent-to-agent handoff stays inside the AI layer, so the original Fabric room and recording continue uninterrupted.

Collaboration

Comments

Leave inline notes for your team while you work on an agent. Open the Comments tab in the right panel of the agent editor to drop a comment, reply to a teammate, edit your own, or tick a thread off as Resolved. Comments fan out live, so anyone else with the same agent open sees new threads, replies, edits, deletions, and resolutions instantly. The tab icon carries a small badge with the number of unresolved comments so you can spot something needs attention without opening the panel.

Open / Resolved / All filters keep the list tidy, and resolved threads collapse their replies behind a one-click Show replies toggle.

Multi-User Editing & Presence

Multiple teammates can open the same agent at once. Avatars in the editor toolbar show who else is currently looking at the agent and what they have selected. Edits are merged in real time: if a colleague tweaks the system prompt while you are adjusting the voice settings, both changes are preserved.

Embedding Your Agent on a Website

Any voice agent can be dropped onto your own website as a floating “Talk to AI” launcher. When a visitor clicks it, a compact panel opens and they can start a live voice conversation with your agent straight from the page; no phone call required. Everything is configured from the Embed tab in the right-hand panel of the agent editor.

<script>
  window.CloudaxAgentConfig = {
    apiUrl: "https://your-domain.com",
    agentId: "your-agent-id"
  };
  (function () {
    var s = document.createElement("script");
    s.src = "https://your-domain.com/api/agent-widget";
    s.async = true;
    document.head.appendChild(s);
  })();
</script>

The snippet only bakes in the agent id; all branding and consent settings flow live from Cloudax Connect on every page load, so a customer never has to re-paste it when you change the widget's appearance.

Letting the agent see and use the page

Three optional switches under Page access in the Embed tab give an embedded agent superpowers on the page it lives on. All are off by default and are enforced server-side, so nothing changes for existing embeds until you opt in.

Screen sharing adds a share-screen button to the widget's call controls. When a visitor clicks it, their browser shows its native screen-picker prompt, and from then on the agent can look at what the visitor is sharing: a form they're stuck on, an error message, a product page, and talk them through it. The agent only inspects the screen when the conversation calls for it, and the visitor can stop sharing at any time from the same button or the browser's own indicator.

Camera adds a webcam button that works exactly the same way. When a visitor turns it on (after their browser's permission prompt), the agent can look at the camera feed: a product they're holding up, a document, a damaged part, using the same on-demand, still-frame sampling as screen sharing, so it stays just as cheap. Screen sharing and camera are independent switches; you can enable either, both, or neither.

Allow website actions lets your own site register named actions the agent may trigger, and push live page updates into the conversation. Actions run in your JavaScript on your page; the agent can only call what you explicitly register, with the arguments schema you declare:

<script>
  // Wait for the widget to load, then register what the agent may do.
  window.CloudaxAgent.registerAction({
    name: "apply_discount",
    description: "Applies a discount code to the visitor's basket",
    parameters: {
      type: "object",
      properties: { code: { type: "string", description: "Discount code" } },
      required: ["code"]
    },
    handler: async function (args) {
      await myShop.applyDiscount(args.code);
      return "Discount " + args.code + " applied";
    }
  });

  // Keep the agent in the loop as the visitor moves around.
  window.CloudaxAgent.sendContext(
    "Visitor is on the checkout page with 3 items totalling £42"
  );
</script>

The handler's return value (a string, or anything JSON-serialisable) is fed back to the agent as the action's result, so it can confirm out loud what just happened. sendContext can be called as often as the page state changes; the agent sees the latest updates the next time it responds. Use window.CloudaxAgent.unregisterAction("name") to remove an action, for example after the visitor logs out.

JavaScript API reference

The loader exposes everything on the global window.CloudaxAgent object once the widget script has loaded. Calls made before it exists are your responsibility to guard (e.g. set window.CloudaxAgentConfig and act in the script's onload). Both action and context APIs are safe to call even when the toggles are off; they simply stay dormant until enabled.

• registerAction(definition) : makes an action available to the agent. definition is an object with:
  • name (required) - matches /^[a-zA-Z][a-zA-Z0-9_]*$/, up to 64 characters, unique per page.
  • description (recommended) - a short sentence telling the agent when to use it; truncated at 300 characters.
  • parameters (optional) - a JSON-Schema object describing the arguments; capped at 4 KB. Omit for a no-argument action.
  • handler(args) (required) - your function, sync or async. Its return value (a string, or anything JSON-serialisable) is sent back to the agent as the result. Throwing returns an error to the agent instead.
  Returns true when registered. Up to 16 actions can be registered at once.
• unregisterAction(name) : removes a previously registered action.
• sendContext(text) : pushes a plain-text snapshot of the current page state into the conversation (capped at 4 KB). Call it whenever the page changes; only the latest updates are shown to the agent on its next response. Updates sent before the visitor opens the widget are buffered and replayed on connect.
• open(), close(), toggle(), isOpen() : control the widget panel from your own buttons.

Deploying Changes

After making changes to your agent's configuration, click the Deploy button to publish the updated version. Your agent will begin using the new configuration for all subsequent calls immediately.

Enter a commit message in the Deploy review to record the completed configuration, then deploy that commit. You can also keep a commit without deploying it. If something goes wrong, open Versions, compare the changes and restore an earlier configuration as a new commit.