The video runs eight minutes and fifty-two seconds and ends with an agent answering messages on a real channel. It is not a demo against a mock: the agent is wired to a Telegram bot, it replies, and the conversations land in the Inbox like any other.
This is the written version, with what a video cannot pause to say: what each field decides, what gets billed, and the exact point where an agent stops answering and a person takes the conversation. The narration is in Spanish; the steps below are the whole thing in English.
What you end up with
- An agent with a name, a goal and a prompt, created from the dashboard.
- A Telegram bot connected and activated, receiving and replying.
- Tools declared: what the agent is allowed to do against your systems.
- A way to test it without messaging a customer.
- An Inbox where you read the conversations and can step in yourself.
If you have never built one and want the mental model first — what an agent loop is, what separates it from a chatbot — start with how to build an AI agent and come back.
1. Create the agent
In the dashboard: Agents → create agent. The dialog asks for two things and nothing else.
Name. You will see it in the metrics, in the Inbox and in the logs. "Support" is enough.
Goal. A plain-language description of what it should do. This becomes the first draft of its prompt, so write it the way you would explain the job to someone starting tomorrow: which questions it answers, in what tone, and what is not its call.
Senders are connected afterwards. A freshly created agent is attached to no number and no bot, and that separation is deliberate: one agent can serve several senders, and a sender answers with one agent at a time.
2. Configure it
This is where the agent stops being a name. The agent screen holds the prompt and the switches that decide when it wakes up.
| Field | What it decides | The part that matters |
|---|---|---|
| System prompt | How it answers and what it never does | The only place your policy lives. If you do not write it, it does not exist |
| Model | Which engine reasons | With the zavu provider you do not need to bring your own API key |
| Context window | How many previous messages it sees | Between 1 and 50. More context is more coherence and more cost per reply |
| Trigger channels | Where it answers | An agent triggering on a channel its sender does not have answers in the playground and nowhere else |
| Message types | Text, image, audio | Text only by default |
Two sentences in the prompt are worth more than everything else: what it does when it does not know, and what it must never promise. An agent that invents a delivery date with total confidence is not a model problem. It is a design decision nobody made.
3. Connect Telegram
In Accounts you connect the bot: talk to @BotFather on Telegram, send /newbot, and paste the token it gives you. Zavu stores it encrypted, registers the webhook, and the bot starts receiving.
Three things worth knowing before they surprise you:
Connecting is not activating. A newly connected account arrives inactive and every send on it is refused until you switch it on. Activation is what counts as a channel connection against your plan.
Telegram identifies people by a numeric chat ID, not by @username. A bot cannot message someone who never opened a conversation with it. You message the bot once, and its reply carries the ID.
Telegram has no 24-hour window and no templates to get approved. That is why it is the right channel for a first agent: two minutes and you have a real channel to test on. WhatsApp is where the volume eventually lives, and it brings business verification and the 24-hour window; the same agent works on both, you change the sender. If that is your destination, the WhatsApp guide covers what it adds.
4. The tools
A model with no tools can talk about your return policy. A model with a lookup_order tool can tell a customer where their package is. Nearly all of a support agent's value lives there.
A tool is four things: a name, a description — which is what the model reads to decide whether to call it — the parameters as JSON Schema, and an HTTPS URL of yours that receives the call.
terminalcurl -X POST https://api.zavu.dev/v1/agents/AGENT_ID/tools \ -H "Authorization: Bearer $ZAVU_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "lookup_order", "description": "Returns the status and estimated date of an order by its number.", "webhookUrl": "https://api.yourstore.com/zavu/orders", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "Order number, e.g. ORD-12345" } }, "required": ["order_id"] } }'
The response carries a webhookSecret once and never again. Zavu signs every call to your endpoint with it, in the X-Zavu-Signature header: an HMAC-SHA256 of the body. Verify it before trusting the call, or anyone who guesses your URL can ask your backend for order data.
The description is the tool's prompt. "Looks up orders" gets it called when it should not be; "Returns the status and estimated date of an order by its number" tells the model when yes and when no.
5. Test it before a customer does
There are two ways and they do different things.
The Playground runs the agent and shows you the reply without sending anything to anyone. It is where you iterate the prompt. One detail that matters: by default it does not execute the tools, because executing them has real side effects, so the model says which one it would call and stops there. There is a switch to run them for real when you want to exercise the whole loop. A reply that sounds like "I have checked your order" with tools off is an invented reply, and that confusion has cost more than one debugging session.
The Sandbox lets you message the agent over WhatsApp or SMS from Zavu's own numbers, from the phone of someone on your team. It is the same path a real message takes.
And from the API, to put it in CI:
terminalcurl -X POST https://api.zavu.dev/v1/agents/AGENT_ID/test \ -H "Authorization: Bearer $ZAVU_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "message": "Where is my order ORD-12345?", "executeTools": true }'
The response carries warnings: things that are true of this agent and that a dry run cannot prove. That the agent is disabled, for instance, or that it triggers on channels its sender does not have. Read them before calling the setup done.
6. Real conversations, and when it goes quiet
With the bot live, every conversation lands in the Inbox with its full history. You see what the agent answered, and you can answer yourself.
The handoff to a person works exactly like this: when a handoff opens, the agent stops answering. Not the contact's next message, not the one after that. The conversation waits in the Inbox. When someone on the team replies, the thread goes back to the agent for whatever follows, so the silence is not permanent.
It is worth stating precisely, because the earlier version of this did not do it: the agent marked a status, nobody was notified, and the bot kept talking over the person it had just promised.
What gets billed, and what does not
- Telegram, WhatsApp, Instagram and Messenger share one monthly message allowance, and it counts both directions: what you receive spends exactly like what you send.
- Zavu does not charge delivery on Telegram. What you pay for is the active channel connection, monthly, according to your plan.
- The model is billed per token. The Agents screen shows executions, tool calls, tokens and cost per agent; a 50-message context window shows up in that column.
- SMS, voice and email are billed separately, per message or per minute.
When this stops being enough
This route — dashboard, prompt, tools, Telegram — is the right one for a support agent that answers questions and looks data up. It stops being enough when the agent needs logic that does not fit in one webhook per tool: rules spanning several systems, queues, retries, state between conversations.
At that point the agent is declared in code and deployed as a function, with defineAgent and defineTool, and it still shows up on the same screens. Same agent, written differently. And if you would rather your coding agent write it, that is a whole workflow of its own.
What does not change on either route: an agent is worth what its tools are worth, and it only works on the channel where your customers are already typing.