Разработка прототипа Booking agent

Вводная
Бизнес для которого разрабатывается агент – салон красоты/парикмахерская. Все что касается Booking агента – это по сути подагент, который будет находиться под оркестратором. Tools которые будут использованы также должны быть реализованы в примитивном виде, чтобы тестирование и приемка были полноценны. 

Реализация на моделях OpenAI. Оптимизированно по стоимости. Память на уровне передачи в контекст сообщений из диалога.

1ый подэтап. Критерии приемки
Согласование критериев приемки. Обсуждение вопросов и ограничений. 
Это мои первые шаги в AI-разработке и я ищу человека, который будет в душе частично Продуктом, т.е. человеком, который будет думать о конечном результате, а не только о реализации. С кем мы сможем обсудить кейсы, взаимодействие клиентов с агентом, как контролировать качество конечного продукта, да и как его вообще принять, этот результат. 
Я не жду большого опыта и готов работать даже с Junior python-разработчиком с небольшим опытом в программировании, но увлекающегося построением агентов, с кем можно строить продукт, гибко подходя к постоянно меняющимся технологиям.

2ой подэтап. Реализация прототипа
Объем может быть разделен на несколько частей, к примеру, мы можем взять только часть юзкейсов.

Задание
Booking Agent управляет полным жизненным циклом записи клиента: создание, отмена, перенос, «опаздываю», статус записи, добавление услуги к существующей записи, история («кто стриг в прошлый раз»). Это единственный подагент в системе с правом записи (write) в БД. Это разделение прав — архитектурное решение, а не рекомендация, и должно быть закреплено на уровне доступа к Integration Gateway, а не только промптом.

Рамки (in scope / out of scope)
**In scope:**
- Создание записи (с уточнением недостающих слотов: услуга, мастер, филиал, дата/время).
- Отмена записи.
- Перенос записи.
- «Опаздываю» — уведомление мастера/филиала, при необходимости — предложение переноса.
- «Когда моя запись» — статус текущих записей клиента.
- Добавление услуги к уже существующей записи («ещё бороду постричь»).

**Out of scope (→ `handoff_required` Оркестратору):**
- Вопросы о ценах/услугах, если они ещё не определены на момент записи → Consultation Agent (агент не должен сам придумывать цену или список услуг).
- Часы работы, адрес, парковка → Policies Agent.
- «Какая стрижка подойдёт», портфолио → Style Advisor Agent.
- Общий сбор контактов вне контекста записи (например, для маркетинговой рассылки) → Lead Qualification Agent.

Если в процессе бронирования всплывает вопрос вне скоупа (например, «а сколько это будет стоить?» посреди диалога о записи), агент должен вернуть частичный `handoff_required`, сохранив уже собранные слоты, и вернуться к записи после ответа.

Особенности write-операций
Здесь центральная сложность не в поиске информации, а в безопасности и корректности операций записи.

### Confirm-before-write
Любая write-операция (`create_booking`, `cancel_booking`, `reschedule_booking`, `add_service_to_booking`) должна сначала пройти через явное подтверждение клиента в диалоге («Записываю вас к Андрею в субботу в 15:00 — всё верно?») и только после положительного ответа — реальный вызов инструмента. Собрать слоты и молча создать запись — недопустимо, даже если модель уверена, что поняла клиента правильно.

### Конкурентность / race condition
Между `get_availability` и `create_booking` слот может быть занят другим клиентом. Это штатная ситуация, а не техническая ошибка — агент должен:
1. Поймать ошибку «слот больше не доступен» от Gateway/CRM как конкретный код, а не как generic exception.
2. Предложить клиенту ближайшую альтернативу (следующий свободный слот у того же мастера или другого мастера того же профиля), не извиняться абстрактно и не завершать диалог тупиком.

Примеры диалогов в приложении