Give a bot functions it can call mid-conversation
What it may actually do rather than just say — look something up, create a record, offer a slot. Functions are where a bot stops being a FAQ.
Without functions a bot can only say things. With them it can do things — check an order, create a record, offer a real appointment slot. That is the difference between a deflection tool and something that completes work.
It is also where a bot can fail in front of a customer in a new way. A function that errors, times out or returns nothing leaves the agent knowing it should have an answer and not having one, which is precisely the situation that produces invented answers. Every function needs a plan for failing.
Before you start
- A bot with a clear job.
- A decision about what it may change, not just read.
- An answer to "what should it say when this fails?"
Steps
Find functions on the bot
Same place for chat bots and call bots, alongside the knowledge base and the handover conditions.
Think of the three together: knowledge is what it can say, functions are what it can do, and handover conditions are when it should stop doing either. A bot with functions and no handover conditions can take actions it cannot explain.
Add only what the job needs
Three functions that work reliably beat ten that mostly work. Each one is a thing that can go wrong live, in front of a customer, mid-sentence.
Describe each function in customer language
The agent decides when to call a function from its description. "Check whether a delivery slot is available on a given date" gets used correctly; "getSlots" gets used at random or not at all.
Be explicit about required inputs
If it needs a date and a postcode, the agent must know to collect both before calling. Say so in the instruction as well as in the function definition — the instruction is what shapes the conversation that gathers them.
Say what to do when it fails
The most-skipped step and the most damaging. Without instruction the agent either invents a plausible answer or goes silent, and both are worse than "I cannot check that right now — let me get someone who can."
Pair anything that changes data with a handover condition
A function that creates a record, cancels an order or takes a payment deserves a human nearby. Reading is low-risk; writing is not.
Test the unhappy path first
Missing data, no results, a timeout, a malformed answer. The happy path almost always works — the others are what your customers will find.
Check it worked
Deliberately break one function — point it at something that will fail — and have a conversation with the bot. Whatever it says in that moment is what a customer will hear on a bad day. If you do not like it, fix the instruction.
The parts people get wrong
- Booking a calendar slot is one of the functions you can give it, and it reads the same availability a booking link publishes — so it cannot offer a slot you are not free for.
- Functions run mid-conversation, so latency matters. A slow lookup on a voice call is a silence the caller will fill.
The ones people actually ask
The bot calls the wrong function, or never calls one.
The description is written for you rather than for the model. It decides when to call a function from the description, so check whether a delivery slot is available on a given date gets used correctly and getSlots gets used at random or not at all.
What happens when a function fails?
Whatever you told it to do — and if you told it nothing, the agent will either invent a plausible answer or go silent, both worse than admitting it. This is the most-skipped step and the most damaging. Write the failure sentence explicitly.
How many functions should a bot have?
As few as the job needs. Three that work reliably beat ten that mostly work, because each one is a thing that can go wrong live, in front of a customer, mid-sentence. Anything that changes data deserves a handover condition beside it.