Aira: a production AI booking agent on WhatsApp
Relayworks AI designed and built Aira, an AI agent that handles appointment booking over WhatsApp end to end — understanding the request, checking real availability, writing to Google Calendar and sending reminders. It is a live production system, not a prototype, and it is the reference implementation for how we build agents for clients.
The problem
Appointment-led businesses in India take bookings on WhatsApp because that is where their customers already are. The owner answers between customers, which means messages go unanswered for hours, slots get double-booked, and bookings agreed in chat never reach the calendar.
The obvious solution — a booking link — fails for a specific reason: it moves the customer out of the conversation they were already in, and completion rates collapse. The agent had to work inside WhatsApp.
Constraints that shaped the design
| Constraint | Consequence for the architecture |
|---|---|
| A wrong booking has a physical cost | Confirm-before-commit on every write; never guess a slot |
| Owners are not technical | Self-serve setup in under 30 minutes, or it does not get adopted |
| Customers write in mixed scripts | Tamil, Hindi and English including Tanglish, not just clean English |
| Per-message costs are real | Deterministic routing wherever judgement is not required |
| The calendar is the source of truth | Two-way sync, not a parallel database that drifts |
Availability is computed in code, not by the model. The conversation engine interprets; the booking service decides.
How it is built
The system is a Python service on FastAPI with PostgreSQL for state, Redis and Celery for scheduled work, and a conversation engine backed by a large language model. The components that matter:
- Conversation engine. Interprets the customer's intent and maintains state across turns. It does not decide availability — it asks the booking service.
- Booking service. The authority on what is bookable. Working hours, breaks, service durations and existing appointments are evaluated in code, deterministically. The model never invents a slot.
- Calendar integration. Confirmed bookings are written to the owner's Google Calendar so there is one source of truth rather than two that disagree.
- Reminder worker. A queue-backed scheduler sends reminders ahead of appointments — the single most effective no-show reduction available.
- Owner dashboard. Business profile, working hours, services and appointments, so the owner can see and override everything the agent does.
The decision that mattered most
Early on, availability was computed by the model. It was faster to build and it demoed beautifully. It was also wrong occasionally — and "occasionally" is unacceptable when the failure mode is a customer arriving at a business that is not expecting them.
Moving availability entirely into deterministic code made the system correct, cheaper and faster at the same time. The model's job became narrow: understand what the customer wants and speak naturally. Everything consequential is computed.
Let the model interpret. Let code decide. Every agent we have built since follows it.
Cost design
Because a large share of a booking conversation is deterministic — greeting, slot presentation, confirmation, reminder — routing those turns away from the model materially reduces cost per booking without changing the experience. Combined with caching the static business context that is identical on every turn, this is the difference between an agent that is economic to run and one that is not.
This is the same analysis set out in our guide to what drives AI agent cost, applied to our own product.
Cost per conversation is instrumented from the first deployment, not added once the bill becomes interesting.
What we would do differently
- Build the evaluation set first. We built it after the conversation engine. Doing it first would have made every subsequent decision faster and better-evidenced.
- Treat WhatsApp API onboarding as the product. Meta business verification is the hardest step for a small business, and we underestimated how much of the activation problem it represents.
- Instrument cost per conversation from day one, rather than adding it once the bill became interesting.
Why this is the case study we lead with
Anyone can describe a methodology. Aira is a system we had to make work, keep working and pay for — with the same constraints we design under for clients: real users, real money, real consequences for being wrong.
When we tell a client to move decisions out of the model, to confirm before committing, or to instrument cost per run, it is not a theoretical position. It is what we learned running this.
Last updated 4 September 2026. See Aira for the product, or agent development for the same architecture applied to your business.
Want a system built to this standard?
Start with a two-week diagnostic. You will know what to build, what it returns and what it costs.