We design AI agents for WhatsApp, voice and web with a specific responsibility: understand requests, consult permitted sources and coordinate tools within explicit boundaries. Autonomy is defined per action, not through a general promise.
Let’s discuss your operationA booking agent and a document agent need different objectives, context and tools. Design begins by defining which requests it handles, which data it needs and when it should stop. That contract makes it possible to evaluate whether a conversation ended correctly and prevents one agent from trying to solve everything with overly broad permissions.
A tool may query a booking, prepare a ticket or retrieve a document. Each call has expected inputs, permissions and a response that must be checked. State changes have defined confirmations, duplicate protection and failure behavior. An intent expressed in natural language is not, by itself, business authorization.
The agent needs to distinguish the current conversation from actual system state. It can retain a useful summary for continuity, but data such as availability, balances or permissions must be checked against the corresponding source. Instructions inside external documents are treated as content, not authority to expand actions or reveal information.
Normal and difficult cases are part of testing: ambiguous users, unavailable tools, contradictory information and out-of-scope requests. Evaluation checks whether the agent chooses the right action and recognizes when it needs help. Human review and records allow the process to be adjusted before granting more responsibility.
The starting point is anonymized real conversations, checking whether the agent reached the right result rather than whether it sounded convincing. A baseline comes first: how these requests are handled today, with which errors and how many handoffs. Then frequent cases are reviewed and, more carefully, difficult ones: contradictory data, users who change their mind midway, tools that do not respond and out-of-scope requests. Each transcript is reviewed against criteria written beforehand.
The same agent role behaves differently depending on the channel. In messaging the conversation is asynchronous: the person may reply hours later, attach photos or documents and pick the thread back up, so the agent must recover context without asking everything again. In voice, turn-taking, confirming what was heard and brevity matter. On the web, the environment often provides more structure, such as forms or buttons. The design adapts the journey to each channel without changing the business rules.
Messaging providers set their own conditions about who may start a conversation, within what time window a free-form reply is allowed and when pre-approved template messages are required. They also regulate contact consent and the kind of content permitted. These rules change over time and vary by provider, country and account type, so verify the current conditions with your provider before designing flows that rely on outbound messages. Agent design treats them as starting constraints, not as details to settle at the end.
An agent is only as useful as the material it works with. Before starting, it helps to gather approved answers to the most repeated questions, policies with their exceptions and a list of actions the agent could perform, ordered by risk. You also need to decide who receives handoffs, during which hours and with what information, because a good handoff depends as much on the human side as on the automated one.
An agent should not approve exceptions to a policy, change amounts or promise what no system backs up. Nor should it follow instructions hidden in documents or messages that try to widen its permissions. Higher-impact actions go through confirmation or a person, and periodic samples of conversations are reviewed to detect drift. When data or procedures change, the expected behavior is tested again.
Answering them in writing, even imperfectly, speeds up the design of the first agent.
Understand the request and verify it is in scope.
Retrieve permitted context and choose the next step.
Use an authorized tool or request approval.
Verify the result and answer or transfer with context.
Autonomy depends on the task and its risk. Some inquiries can be resolved using approved sources; other actions require confirmation or human review.
It is a design option when responsibilities differ. The simplest architecture that retains context, permissions and a clear way to verify outcomes is preferred.
It should ask for clarification, state the information limit or route the case. Expected behavior is defined and tested; inventing a solution is not acceptable.
Let’s start with a process that matters. Discover what your team could do with more time.
Book a demoOr write to us about the process you want to improve