A multi-agent AI receptionist built to work across CRM and booking systems.

The problem: one receptionist across different operating stacks

A startup had attempted to build a multi-agent receptionist internally but needed a system that could operate across different CRM and booking products. A bot tied to one provider would not solve the product problem: customers needed a configurable assistant that could work with their own data and scheduling stack.

What we built: a supervisor that adapts specialised agents

We built a supervisor-agent architecture. The supervisor reads the live CRM and booking context, then prepares and updates the instructions used by specialised agents. This avoids hard-coding a separate conversational flow for every CRM or calendar configuration.

The system combines amoCRM, Bitrix24, YClients, Google Calendar, and Yandex Calendar. It also uses retrieval-augmented generation for company-specific answers and long-term memory so the assistant can preserve customer context across conversations.

Product work beyond the agent flow

The delivery included settings pages for configuring agents and a refactor that removed roughly 6,000 lines from a large area of the codebase while preserving functionality. That work matters because an AI receptionist is not only a prompt: it needs configuration, integrations, memory, and maintainable product behaviour.

What this case does and does not prove

This is an architecture and product-delivery case. The client remains confidential because the product had not launched publicly at the time of publication. We do not claim bookings, conversations handled, revenue, or labour savings because verified live-use metrics were not available.