Tools & actions

Give your agent the ability to do things during and after a call - every tool and its settings explained in plain language.

A tool is something the agent can do, not just say. On its own, an agent talks: it explains, answers, persuades. Give it tools and it can also transfer the call to a person, send a WhatsApp message, look something up in your system, hang up cleanly, or record that the caller wants off your list. Think of tools as the difference between a receptionist who can only chat and one who can actually put you through, book you in, and text you the details.

Tools live in two places, and it helps to keep them straight:

  • The workspace catalog (main sidebar → Tools) is where you set a tool up once - the transfer numbers, the message templates, the webhook URLs. This is admin-level configuration for the whole workspace.
  • The agent (builder Step 3, or per node in the flow builder) is where you pick which of those tools this particular agent may use. An agent only ever gets the tools you tick for it.

That split matters: setting up a transfer number doesn’t mean every agent starts transferring calls. Nothing is granted until an agent selects it.

The golden rule: grant only what the call actually needs. Every extra tool is one more thing that could fire at the wrong moment - and a shorter, tighter tool list makes the agent faster and more predictable. When in doubt, leave it off.

How every tool describes itself

Before the individual tools, one idea that runs through all of them: almost every tool asks you for a “when to use” description. This isn’t a label for you - it’s the instruction the agent’s AI actually reads to decide whether and when to reach for that tool mid-call.

  • Vague description → the tool fires at the wrong time (or never). “Use this webhook” tells the agent nothing.
  • Specific description → the tool fires exactly when it should. “Check an order’s status by order ID - use when the caller asks where their package is” is a clear trigger.

Wherever you see a When to use / What it does field, treat it as briefing a new hire on exactly when to pull a particular lever. Most of these fields are required for that reason.

Transfer to human

What it is: hands the live call over to a real person - a support desk, a senior agent, an on-call teammate.

Why you’d use it: some conversations shouldn’t be finished by an AI. An angry customer, a complex dispute, a hot sales lead who wants to talk to a human now - the agent recognises the moment and passes the baton.

How to set it up (Tools → Transfer to human):

  • Transfer numbers - the approved list of destinations an agent may transfer to. You add each one with a label (“Support desk”), the number (Indian numbers, +91 followed by a 10-digit mobile), and a short “what it’s for” description. That description is important: when you have several numbers, the agent reads them to decide which one to send the call to (“transfer here for billing disputes” vs “transfer here for new sales”).
  • Transfer mode - how the handoff happens:
    • Warm (recommended) - the agent calls the human, waits for them to actually pick up, then bridges the caller in. The whole thing is recorded. The caller isn’t dumped into a ringing void.
    • Cold - the agent transfers immediately without waiting. Faster, but the human’s conversation with the caller isn’t recorded.
  • Announcement to caller - the line the caller hears at the moment of transfer, e.g. “Connecting you to a specialist now.” A small touch that stops the handoff feeling abrupt.

You must have a human on the other end. This is the one tool that dead-ends without real people behind it. If nobody answers the transfer number, the caller is left hanging - so only enable this if there’s genuinely a rota or desk ready to receive calls. (If a warm transfer fails to connect, the agent is built to recover gracefully and keep helping rather than leave the caller in silence, but that’s a safety net, not a substitute for staffing.)

  • Tip: behind the scenes, each approved number becomes its own transfer option for the agent. Add clear, distinct descriptions per number and the agent will route far more accurately than if you leave them blank.

End call

What it is: lets the agent hang up the phone by itself when the conversation is genuinely finished.

Why you’d use it: without it, an agent has no clean way to end a call - it can keep the line open awkwardly after everything’s been said. End call gives it a polite, decisive way to wrap up.

Two things worth knowing:

  1. It’s polite by design - it asks first. The agent doesn’t just cut the line. It asks permission to end (“Is there anything else, or shall I let you go?”), and only hangs up on a clear yes. If the caller’s reply is garbled or ambiguous, the agent re-asks rather than guessing - so a single unclear “uh…” can never strand someone or drop them mid-sentence. The call never ends without clear agreement.
  2. Every agent already has it. You don’t strictly need to add End call for an agent to be able to hang up - a sensible hangup capability is attached automatically so no call runs forever. Configuring it here simply lets you shape how it wraps up.

How to set it up (Tools → End call):

  • When to use - the description the agent reads (default: “End the call politely when it is complete.”). Required.

  • Farewell message - the exact goodbye, e.g. “Thanks for your time. Have a great day!”

  • End the call when - the situations that make it right to wrap up. Tick any of: caller says goodbye, the call objective is complete, voicemail is detected, the caller goes silent for too long.

  • Tip: turning on voicemail is detected is a quiet money-saver - the agent won’t sit talking to an answering machine.

Send WhatsApp

What it is: sends the caller a pre-approved WhatsApp message during the call - a payment link, a booking confirmation, a brochure - so they have it in writing before they hang up.

Why you’d use it: “I’ll text you the link” lands far better than reading a URL aloud. It also gives the caller something to act on after the call ends.

How to set it up (Tools → Send WhatsApp):

  • Your workspace must have WhatsApp connected first. WhatsApp is client-owned - you connect your own account (MSG91 or Meta) in Integrations → WhatsApp. If it isn’t connected, the tool shows a warning and simply won’t send. The platform can’t message on your behalf without your account, so never promise a caller a WhatsApp unless you’ve confirmed it’s wired up.
  • Templates - you don’t write free-text WhatsApp messages; WhatsApp requires pre-approved templates (that’s Meta’s rule, not ours). You create and get templates approved in your provider, and once approved they appear here to pick from.
  • Variable mapping - templates have placeholders like {{1}}, {{2}}. You map each one to a contact field (name, amount, link) so every message is personalised from your calling list.
  • When the agent sends it - the required description telling the agent the right moment, e.g. “After the caller confirms a delivery slot.”

A note on SMS: there’s also a Send SMS tool in the platform, but plain SMS is currently switched off - WhatsApp is its replacement. If you’re looking to text a link or confirmation mid-call, use WhatsApp. (SMS, when active, works the same way: reusable message templates each with a “when to use” note.)

  • Tip: name your saved template after the moment, not the content - “Delivery slot confirmation” is easier to reason about later than “Template 3.”

Webhook

What it is: lets the agent call your own backend mid-conversation, then use the answer in what it says next. This is the tool for “look it up in our system and tell the caller.”

Why you’d use it: your live data lives in your systems, not ours. A webhook lets the agent check an order, verify a policy number, create a record, or trigger a workflow on your side - and speak the result back naturally (“I can see your order shipped yesterday”).

How to set it up (Tools → Webhook):

  • Tool name - a short code-style name the agent sees, e.g. lookup_order (letters, digits, underscores).
  • Required parameters - the pieces of info the agent must collect from the caller before calling you, e.g. order_id, pincode. The agent will ask for these first.
  • What it does - the required description that tells the agent when to call it, e.g. “Check an order’s status by id.”
  • Webhook URL - your HTTPS endpoint (must start with https://). The agent sends a POST.
  • Authorization header (optional) - e.g. Bearer …, so your endpoint can verify the request is really from us.
  • Signing secret (HMAC) (optional) - adds a signature header so you can cryptographically confirm the request wasn’t tampered with.

Both the authorization header and signing secret are encrypted at rest and never shown again after you save. When editing a webhook, leave them blank to keep the existing values.

  • Tip: webhooks are the most powerful tool here and the easiest to over-scope. Give the endpoint exactly the parameters it needs and a razor-sharp description, and it’ll be reliable. Vague descriptions are the usual reason a webhook fires when it shouldn’t (or sits unused).

Fetch from internet

What it is: lets the agent read live data from a URL you approve - a status page, a public API, a rates endpoint - and use it in the conversation.

Why you’d use it: sometimes the agent just needs to look something up, no writing involved: today’s rate, whether a slot is free, a shipment’s public tracking status.

How to set it up (Tools → Fetch from internet):

  • Endpoints - each is a name, an https URL (you can include a placeholder like https://api.acme.com/orders/{id} - the agent fills it in), and a “what it does” description. You can add several.
  • Timeout - how long the agent waits for a response (4, 8, or 12 seconds). Past that, it stops waiting and keeps talking, so a slow endpoint never freezes the call.

Fetch is deliberately locked down. Agents can only reach the exact hosts you list - nothing else on the internet. Requests are read-only (nothing is ever written back), they time out automatically, and each endpoint is pinned to its own host. This is a hard security boundary the AI cannot talk its way around.

  • Fetch vs Webhook - which one? Reach for Fetch when you only need to read something and want a quick host-locked lookup. Reach for Webhook when you need to do something on your side (create a record, trigger a flow), need to send parameters as a POST, or want auth and signing. When in doubt: reading → Fetch, acting → Webhook.

CRM & integration actions

What it is: actions backed by the third-party tools you’ve connected - look up a contact in HubSpot or Salesforce, check a Shopify order, open a Zendesk ticket, offer meeting times and book a slot from a connected calendar.

Why you’d use it: rather than building a webhook by hand, if you’ve already connected a supported provider in Integrations, the matching actions become available to grant with a tick.

How it works:

  • An integration action only appears once its provider is connected. Connect Shopify and “Order lookup” shows up; connect Calendly, Cal.com, or Google Calendar and “Check availability” + “Book meeting” appear.

  • They’re off by default. Even when the provider is connected, you choose per agent (or per node) which of its actions that agent may use.

  • Available actions today include: Look up contact (HubSpot / Salesforce), Order lookup (Shopify), Create support ticket (Zendesk), and Check availability + Book meeting (Calendly / Cal.com / Google Calendar).

  • Tip: connecting a provider is safe - it doesn’t hand every agent its actions. You still opt each agent in deliberately.

Always-on tools (opt-out & disposition)

Two tools are built into every agent, on every call, and you cannot turn them off. You can reword when they fire (Tools → Always-on tools), but the action each performs is fixed in code.

Record a Do-Not-Call request (opt-out)

What it does: when a caller asks not to be contacted again, the agent records it - and that number is suppressed everywhere within seconds, honoured on every future dial across the workspace.

Why it’s always on: honouring opt-outs is a legal obligation, not a feature. It can’t be bypassed by the agent, the caller, or the model. You can sharpen the when-to-use wording, but the opt-out itself always works.

On some workspaces, opt-outs are detected from the transcript after the call instead of mid-call (a performance optimisation that lets the agent run leaner during the conversation). Either way, the request is captured and honoured - the difference is purely timing, and it’s invisible to the caller.

Set the call disposition

What it does: records the outcome of each call - interested, callback, not interested, and so on - as a clean, structured label.

Why it’s always on: everything in your Pipeline and Analytics is built on dispositions. Without them there’d be nothing to filter or report on, so it can’t be disabled.

  • Tip: the wording you give here nudges how the agent labels calls. Keep it aligned with the disposition categories your team actually uses so the reporting stays clean.

Agent-level tools vs per-node tools

Where you grant a tool depends on which kind of agent you’re building:

  • Single-prompt agents (the standard builder) get one tool set for the whole call - you pick it in Step 3 of the agent builder. Simple and right for most calls.
  • Flow agents (flow builder) can grant tools per node. The “Qualify” node might have no tools; the “Book” node gets calendar actions; the “Escalate” node gets Transfer to human. This keeps each stage of the conversation focused - the agent can only transfer during the part of the call where transferring makes sense.

The picker is the same in both places, and so is the logic: enabling a multi-item tool (transfer numbers, message templates, fetch endpoints) selects all its items by default, and you untick to narrow. So you can, for example, give one node access to just the “Support desk” transfer number and another node the “Sales” one.

  • Tip: per-node tools are one of the biggest advantages of a flow. If an agent keeps doing something at the wrong moment, the fix is usually “move that tool onto the one node where it belongs” rather than rewriting the prompt.

Mid-call vs post-call

Not everything has to happen while the caller’s on the line:

  • Mid-call - transfers, WhatsApp, webhooks, fetches, CRM lookups, ending the call. These need to happen live because they change the conversation in the moment.
  • Post-call - some outcomes are handled after the call, read from the transcript: setting the disposition, pushing a result to your CRM, and (on some workspaces) recording opt-outs. Doing this work post-call keeps the live conversation fast and lets the agent focus on talking. You configure post-call behaviour alongside your integrations.

The trade-off is simply speed: the fewer real actions an agent has to take mid-call, the snappier it feels. That’s why the platform quietly moves what it safely can to after the call.

Keep it tight

To repeat the one rule that matters most: only enable the tools an agent actually needs. Fewer, well-scoped tools make the agent faster, more predictable, and easier to debug. A sales-qualifier that only needs to book a meeting shouldn’t be carrying a webhook, a fetch endpoint, and three transfer numbers “just in case.” Grant deliberately, describe each tool precisely, and the agent will use them exactly when it should.

Next: Compliance packs → - the rulebook every agent follows before a single number is dialed.