Voice Agent with Tool-Calling
Voice Agent with Tool-Calling
What you build: a hosted-AI voice agent with a custom tool (track_order). When a caller asks about their order, the agent decides to call the tool, Voicebip POSTs a tool.invocation request to your endpoint, your server hits your orders API and returns JSON, and the agent speaks it — all within the call.
Who it’s for: any developer with an existing backend API (orders, bookings, account balance) who wants the phone agent to act on live data, not just recite static docs. This is the biggest leap in capability — the difference between a demo and a product.
Tool-calling is a hosted-AI feature: Voicebip’s model runs the reasoning and decides when to call your tool. It’s a different path from BYOM, where your model runs and Voicebip is a dumb relay. An agent is either hosted-with-tools or BYOM — not both. Custom tools are dispatched to the agent’s webhook_url (the same field BYOM uses); built-in tools run internally.
Prerequisites
- A hosted-AI agent (see Inbound support + KB for the base build).
- An HTTPS
webhook_urlon the agent to receivetool.invocationand return results. It must be a public address (Voicebip’s SSRF guard rejects private/loopback/link-local hosts) and respond within a few seconds — the caller is waiting. - Your workspace signing secret (dashboard → Workspace → Signing Secret) to verify signatures.
Step 1 — Define the tool
tool_definitions is an OpenAI-compatible JSON array. Define one custom function:
Voicebip validates the model’s arguments against this JSON-Schema before calling your webhook — if the model hallucinates a bad shape, your endpoint is never hit and the model is asked to self-correct.
Alongside your custom tool, the agent always has these built-in tools it can call with no webhook — use them in your prompt:
Step 2 — Create the agent with the tool + webhook
tool_definitions is a string (stringified JSON). Custom tools dispatch to webhook_url, so set both. Instruct the model when to use the tool in system_prompt:
Step 3 — Handle tool.invocation on your server
When the model calls track_order, Voicebip POSTs to your webhook_url (HMAC-signed, same scheme as everything else). Verify the signature, run the tool, and return a JSON body — that body is fed straight back to the model, which turns it into speech.
The inbound tool.invocation request body:
Your response is just the tool’s result as JSON — return 200 with any JSON object:
How your response is used. Any 2xx JSON body is handed back to the model verbatim. A non-JSON 2xx body is wrapped as {"result": "<your text>"}. A 4xx/5xx becomes an error result the model can apologise for (and it can fall back to transfer_call). Speed matters — the caller hears silence while your tool runs; keep the handler fast and return { "error": "…" } rather than hanging.
Step 4 — Recursive tool loops
The agent can chain tools: call track_order, then based on the result decide to call transfer_call. Voicebip runs the tool loop up to a bounded depth per turn so a misbehaving prompt can’t loop forever. Design tools to resolve in one or two hops.
Test it
tool.invocation is dispatched to your webhook_url in a live call, so it isn’t part of the POST /v1/webhooks/test catalogue (which covers call.* / message.* lifecycle events). Two ways to exercise it:
- Chat in the playground and watch the model decide to call the tool:
- Unit-test your handler by POSTing a sample
tool.invocationbody (above) to your own endpoint with a valid signature.
Troubleshooting
Next steps
- Ground the agent’s answers in your docs too → Inbound support + KB.
- Prefer to run your own model end-to-end? → BYOM.
- Route different intents to different specialised agents → Multi-agent routing.