"AI agent" has been applied to autocomplete, to a chatbot with three buttons, and to systems that book flights unsupervised. When one word covers that much ground it stops carrying information.
Here is a definition that is narrow enough to be useful:
> An AI agent is a language model running in a loop, with tools it can call and a place where people can reach it.
Three parts, all of them required. Remove the loop and you have a prompt. Remove the tools and you have a search box over your documents. Remove the way in and you have a demo.
The loop is the whole difference
A normal model call is one shot. Text goes in, text comes out, the model never learns whether the answer was right.
An agent gets a goal instead of a question. It looks at the tools available, picks one, sees what came back, and decides again:
customer: "where is order 4471?"
turn 1 model decides: call lookup_order(orderId: "4471")
tool returns: { status: "in_transit", eta: "2026-08-14" }
turn 2 model decides: no more tools needed
answer: "It is in transit and should arrive on the 14th."That second turn is what a plain prompt cannot do. The model saw real data and changed its answer because of it. Everything people find impressive about agents comes from repeating those two steps until the job is done.
The loop also explains why agents fail in ways chatbots do not. A chatbot with a broken button shows a broken button. An agent with a badly described tool calls the wrong one, gets a plausible result, and answers confidently with it.
The four parts
| Part | What it does | What happens without it |
|---|---|---|
| Model | Decides what to do next | Nothing decides |
| Tools | Read and change the real world | It can only talk about your business, never act on it |
| Memory | Keeps the conversation and what it learned | Every message starts from zero |
| Channel | Where a human reaches it | It is a script only you can run |
Most of the writing about agents is about the first part, and most of the engineering is about the other three.
Tools are functions with a description the model reads. lookup_order, book_slot, create_ticket, transfer_to_human. Their descriptions matter as much as your system prompt, because the description is how the model decides whether this is the moment to call it.
Memory is usually two things pretending to be one: the current conversation, and a knowledge base the agent searches. The first is state, keyed by whoever is talking. The second is retrieval, and it is what stops the agent inventing your refund policy.
Channel is the part that turns a project into a product. Which brings us to the question people skip.
Where agents actually live
An agent that only exists behind a chat widget on your website reaches the small set of people already on your website.
The agents that get used live where the conversation already happens:
- WhatsApp for support, bookings and anything conversational in Brazil, LATAM, India, Southeast Asia and Southern Europe, where it is the default messaging app.
- SMS for reaching anyone with a phone, no app required, with the highest open rate of anything on this list.
- Email for long context, attachments and B2B threads, where an agent can read a whole quotation request and answer with one.
- Voice for callers who will not type, which is still most people over a certain age and everyone whose hands are busy.
- Telegram, Instagram and Messenger for communities and consumer brands whose audience already lives there.
This is why "which model should I use" is rarely the decision that determines whether the agent works. The model is roughly interchangeable. The channel is not.
The types that actually exist in production
Set aside the demos. These are the shapes that survive:
The support agent. Answers questions from a knowledge base, looks up order or account state, escalates to a person when it cannot. The most common by a wide margin, and the easiest to measure: deflection rate and escalation rate.
The booking agent. Checks availability, holds a slot, confirms. Small tool surface, high value, and unforgiving: double-booking is worse than not answering.
The qualifier. Talks to inbound leads, asks three or four questions, writes the result to your CRM and routes the ones worth a human. The clearest ROI of the group because you can price a qualified lead.
The scheduled agent. Nobody talks to it. It runs on a cron, checks something, and messages a person when the answer is interesting. Stock is low, a payment failed, a customer has been silent for thirty days. Underrated, because the "conversational" framing hides that agents are also good at starting conversations.
The voice agent. Answers the phone, does the same job as the support agent, under a latency budget of about one second. Every design decision is downstream of that number.
What is not an agent
Being precise here is worth more than it sounds, because the wrong label sets expectations you then have to pay for.
A chatbot with a decision tree is not an agent. If a human wrote every branch, the model is not deciding anything. This can still be the right product: a scripted flow is predictable, auditable and cheap, and for a menu of five options it beats an agent. See agent vs chatbot for when each one wins.
A model answering from documents is retrieval. Genuinely useful, and often all you need. It becomes an agent when it can also do something: create the ticket, not just describe how.
A workflow with a model in one step is a workflow. If the sequence is fixed and the model just rewrites some text in the middle, calling it an agent adds nothing but expectation.
A single model call with a long prompt is a prompt, however long the prompt is.
What an agent costs
Three separate meters, and most pricing pages only mention the first.
Tokens. Every turn of the loop is a model call carrying the whole conversation. A three-turn agent costs roughly three times a single reply, plus the growing history. This is why the turn limit is a budget control and not just a safety valve.
Channel delivery. WhatsApp, SMS and voice each charge per message or per minute, and those rates come from Meta and the carriers, not from the model. For an agent handling volume, this line is usually larger than the token line.
Human escalation. The conversations the agent hands over still cost what they cost. An agent that deflects 60 percent of tickets is a 60 percent saving, not a 100 percent one, and the honest business case says so.
On Zavu, agents can run on the managed zavu provider, billed from your project balance, or on your own OpenAI, Anthropic, Google or Mistral key with no markup on the model cost. The pricing page has the current numbers.
Trying one
The fastest path from reading about agents to talking to one. Nothing here is code you write:
terminalnpx skills add zavudev/zavu-skills npx zavudev@latest login npx zavudev agents init
The first line teaches your coding agent this API so it stops inventing endpoints. The second authorizes it. The third is guided.
agents init walks through creating a sender, pulling a ready-made agent from the catalog and setting its secrets. From there npx zavudev deploy puts it live, and:
terminalnpx zavudev agents test --agent <agentId> --message "do you have a table for four on Friday?"
runs the real agent and shows you what it would say, without delivering anything or charging anything.
Keep reading
- How to build an AI agent: the loop from scratch, then deployed on a channel.
- AI agent vs chatbot: the decision, with the cases where the chatbot wins.
- AI agent frameworks compared: which layer LangChain, CrewAI and the rest actually own.
- AI agents for WhatsApp, SMS and email: the platform view.