Tools
How agents take real actions mid-conversation — looking things up in your systems, writing records, and notifying your team.
An agent with instructions and a knowledge base can talk about your business. A tool lets it do something: look up a real order, check today's real availability, create a ticket, alert your team. Tools are what turn a good conversation into a useful one.
How a tool actually works
This is the part that trips people up, so here it is end to end. Say a caller asks "where's my order?" and you've built an order-lookup tool.
The agent decides to use it
Mid-conversation, the agent looks at the tools available to it and reads their descriptions. It sees one that says "Look up the status of a customer's order using their order number" and recognises that's exactly what's being asked.
It isn't documentation — it's the instruction the AI uses to decide whether this tool applies right now.
It collects what the tool needs
You've defined the tool's parameters — the pieces of information it requires. Here, an order number. If the caller already said it, the agent uses it. If not, the agent asks for it, naturally, in the middle of the conversation.
ClearTalk calls your system
The parameters get dropped into the request you configured, and it's sent to your system. Because that takes a moment, you also tell the agent what to say while it waits — "Let me pull that up for you" — so the caller never hears dead air.
Your system answers
It sends back whatever it sends back, typically a block of data with far more in it than the conversation needs.
You pick out the parts that matter
In the tool's response settings you name the specific values worth keeping — the status, the delivery date — and each becomes a variable the agent can use.
The agent uses them
It speaks them naturally ("Your order shipped Tuesday and arrives Thursday"), and if the tool sits inside a pathway, the conversation can branch on them — one path if the order shipped, another if it's delayed, another if nothing was found.
The description is the trigger. It's the single most important thing to understand about tools — the AI reads it to decide whether this tool applies right now. Vague descriptions produce tools that never fire, or fire at the wrong moment.
The whole chain is: description decides when → parameters gather what → the request goes out → the response comes back → extracted values shape what happens next.
- 1
The agent recognises the need
It reads the descriptions of the tools it has and decides this one applies right now.
- 2
It gathers the parameters
From what the caller already said, or by asking for what's missing.
- 3
ClearTalk calls your system
Saying your waiting line out loud so the caller doesn't hear silence.
- 4
Your system answers
Usually with far more data than the conversation needs.
- 5
The values you named are pulled out
Each becomes a variable the rest of the conversation can use.
- 6
The agent speaks — or the pathway branches
It reads the result back naturally, and a pathway can take a different path depending on it.
Where tools get used
- Attached to an agent — the agent may use the tool at any point when it seems relevant. Best for lookups that could come up anywhere ("what's my balance?").
- As a Custom Tool step in a pathway — the tool runs at exactly that point, and the pathway branches on the result. Best when the action belongs at a specific moment, or when what happens next depends on the answer.
Build once, use in both. Tools live in Tools in your sidebar and are reusable across every agent and pathway you own.
What makes a good tool
- One job. "Look up an order" and "cancel an order" are two tools, not one with a mode switch. The AI chooses between clear, narrow tools far more reliably.
- A description written for the AI, not for you. Say when it should be used, in plain language: "Use when the caller asks about the status or delivery date of an existing order. Requires their order number."
- Fast. Every second of a tool call is a second of silence on a live phone call. Anything over a few seconds needs a good waiting line, and anything much slower is better handled as a follow-up than in-call.
- A plan for failure. Systems go down and records aren't found. Decide what the agent says then — and if it's in a pathway, give that outcome its own path.