Разработка прототипа 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. Предложить клиенту ближайшую альтернативу (следующий свободный слот у того же мастера или другого мастера того же профиля), не извиняться абстрактно и не завершать диалог тупиком. Примеры диалогов в приложении