Blog details

Retrieval Over Recall

Ami does not answer from whatever the model picked up in training. The site is chunked, embedded and sitting in a vector database, and every question goes through a search against that first.

Two things about that we did not expect. A customer's actual words make a poor query, so the question gets rewritten against the earlier messages before anything is searched. And broad questions have to be searched twice: one pass comes back almost entirely AI services, because that is what the front page is about, and the development and design work barely surfaces.

When the index has nothing, Ami says so. No price, no timeline, no opinion on a tool we have never written about. It offers to have someone confirm instead.

It also remembers you

Messages are written to Postgres on Supabase against the customer's number, so coming back on Thursday is not starting from scratch. Ami will not ask your name twice or try to book you a call you already have.

Human in the Loop

Ami is the first layer on a channel that never closes. It is not standing in for anyone. It handles what it can check, passes on what it cannot, and anybody on the team can take a conversation off it without telling it to stand down.

In practice that comes down to three rules. A colleague's message beats anything Ami was about to send. Nothing gets confirmed that was not read off the live calendar or out of the index. And everything is written down, so whoever picks the chat up reads the conversation rather than a summary of it.

Handover Etiquette

You can tap the button or just ask. Either way Ami tells them someone will be in touch, emails the team the number, the WhatsApp name and the time it came in, and stops replying.

Then it is gone for twelve hours. If somebody does reply, those twelve hours start again from their last message, so it cannot wander back into a live conversation. If a colleague replies while Ami is mid-draft, the draft is binned and nothing gets sent.

Typing bot on its own brings it back, carrying on from wherever the conversation had got to. Admin numbers can mute and unmute it the same way.

Booking Without Friction

Ami books into the team calendar, but only when somebody asks for a call. Thirty minutes, on the hour, nothing sooner than three hours away, nothing further out than a week, and always inside working hours even when it is the one awake at two in the morning.

It reads the calendar before offering a time and again before confirming it, and it does not invent meeting links. The name, the email and a short summary go to the leads sheet whether or not anything ends up booked.

The Stack Behind Ami

There is nothing unusual in the stack.

• n8n for the workflow, which keeps the branching readable instead of buried in code
• The WhatsApp Business platform for the number, the buttons and delivery
• A vector database holding the site as embedded chunks, with Gemini doing the embedding
• Gemini as the model, with a second model standing by in case the first one fails
• Postgres on Supabase for history, Google Calendar for availability, Sheets for leads

Working hours live in one place now. They used to be set in two, which is how we once offered somebody a slot half an hour after everyone had gone home.

What Actually Made the Difference

None of this needed a better model. It needed a clear idea of when the thing should keep quiet, something worth quoting from, and a team that can override it at any point.

The practical difference is small enough to say in a line. Nobody waits until Monday any more, and when a conversation does reach one of us it arrives with a name and a question already attached instead of starting from hello.