Connecting a voice agent to your systems

An agent with no connections can only talk. Connected to your systems, it can look up an order, log a request or read your current policy. zlicx offers three ways to connect it, each suited to different work.

HTTP tools: actions and live lookups

An HTTP tool describes a request to your API: its name, what it's for, the URL, the method, and its headers and body. Each parameter has a source:

• LLM prompt. The model fills it from the conversation, such as a callback time the caller mentioned.
• Static value. Always the same, such as a source tag.
• Dynamic variable. Supplied when the call starts, such as the order number.

Use dynamic variables for anything that decides whose data is accessed. If the customer ID comes from the conversation, a caller might talk the agent into fetching someone else's record. Your API should still enforce its own permission checks. A prompt isn't a security boundary.

The description matters more than it looks, since it's how the model decides when to use the tool. Say what the tool does, when to use it, and when not to.

MCP servers: existing tool collections

If a system already offers an MCP server, you can connect it, then attach only the tools that agent needs. Don't attach a whole server because it's easier. Every extra tool is one more thing the model can choose by mistake.

Knowledge bases: approved answers

Add files or URLs, and the agent can search them during a call. This suits material that's stable and written down, such as policies, delivery areas or opening hours.

It doesn't suit anything that changes per customer or by the hour. Stock levels and order status belong in a tool. Check for contradictions too: if two documents disagree, the agent may quote either of them.

Keep credentials out of prompts

Store API keys as secrets rather than writing them in a prompt or a tool's plain fields. Prompts get copied, shared and sent to model providers.

Rules to put in every prompt

These small rules prevent the most damaging errors:

1. Say an action is done only after the tool reports success.
2. If a tool fails, say so and offer the next step, instead of retrying forever or making up a result.
3. Say "let me check that" before slow lookups, so the caller doesn't sit through silence.
4. Don't read back raw data such as IDs or JSON unless the caller needs it.

Make your endpoints call-friendly

• Fast. The caller is waiting. Aim for well under a second where you can.
• Safe to repeat. A retried booking shouldn't produce two bookings.
• Plain results. "Order shipped, arriving Thursday" is easier for the model than a large payload.
• Clear errors. "Order not found" helps the agent. A generic 500 doesn't.

Test by breaking things. Point the tool at an endpoint that times out, and listen to what the agent says.

The operations automation page has example flows. Tool calls use extra model tokens, which appear in your usage under the pricing formula. For anything unusual in your stack, talk to us.