Один AI-агент, дві спеціалізовані ролі: як Ven маршрутизує кожне звернення

Одна ідентичність, один router і один owner на кожен хід

Модель одного агента зберігає безперервність. Привітання може належати Customer Support, наступне повідомлення показує, що відвідувачу потрібен електрик, і Front Office перебирає хід без зміни видимої ідентичності чи нового флоу. Transcript, visitor, channel і active request залишаються спільним контекстом. Змінюється лише authority: support використовує перевірені знання, а операційна роль — тільки налаштовані для неї послуги й дозволи на дії.

Customer Support — широкий розмовний шар. Він обробляє привітання, питання про продукт або процес із дозволеного контенту й безпечний handoff, коли джерел недостатньо. Йому не потрібен доступ до зміни Service Request, щоб пояснити, як працює бізнес. Knowledge base може вирости від мінімального Starter Coverage до повного help center, але кожна відповідь усе одно обмежена контентом робочого простору.

Окремі знання та права для Support і Front Office

Front Office володіє чітким сервісним наміром. Він зіставляє звернення з активними послугами каталогу, витягує лише поля шаблону вибраної послуги й рекомендує наступний стан. У Qualify він може створити заявку для впевненого match, записати high-confidence відповіді та надсилати по одному дозволеному уточненню. Він не може вигадувати послуги, непомітно переписувати виправлені значення, планувати роботу чи виконувати handoff без відповідного інструмента в наступному режимі.

Starter Coverage прибирає незручний розрив, коли workspace увімкнув Front Office, але ще не створив повну базу підтримки. Стартовий матеріал дозволяє Ven привітатися, пояснити збір сервісних деталей, поставити достатнє запитання для маршрутизації та підтвердити перехід. Він навмисно не відповідає про продукти, ціни, політики чи доступність. Екран Content явно показує обмежене покриття, щоб бізнес не сплутав мінімальну безперервність із налаштованою підтримкою.

Starter Coverage зберігає цілісність handoff без удаваного всезнання

Deployment контролюється на двох рівнях. Глобальний графік і список каналів визначають, де Ven доступний. Потім кожну роль можна окремо зробити live або pause, а Front Office має власний рівень автономії та readiness checks для послуг. Якщо Front Office увімкнено без повної підтримки, setup пропонує Starter Coverage замість того, щоб мовчки залишати загальні питання без відповіді. Owner усе ще може обрати вузький deployment, але бачить наслідок до збереження.

Deployment controls дозволяють розширювати workspace роль за роллю

Така архітектура спрощує подальше розширення. Нові ролі не стають окремими ботами, що конкурують за розмову; це спеціалізовані власники за одним router. Кожна роль отримує мінімально потрібні знання та права, кожен хід фіксує причину маршрутизації, а оператор бачить результат в inbox. Успіх вимірюється не кількістю ролей, а тим, чи одне повідомлення клієнта створює одну відповідальну відповідь і одну безпечну наступну дію.

Перевірте межу п’ятиходовим role-routing сценарієм

Почніть нову розмову з привітання, потім поставте загальне процесне питання, а далі опишіть підтримувану сервісну потребу. Перевірте, що Customer Support володіє першими двома ходами, а Front Office — сервісним, хоча клієнт бачить одну ідентичність Ven і безперервний transcript.

Далі надішліть неоднозначне сервісне повідомлення й unsupported питання про продукт або ціну. Неоднозначність має викликати уточнення без випадкової заявки. Unsupported питання має використати дозволений контент або зробити чистий handoff; Starter Coverage не повинен вигадувати відповідь заради автоматизації.

Нарешті окремо призупиніть кожну роль і повторіть сценарій. Deployment screen має пояснити, куди піде категорія без відповіді, audit — записати routing reason, а дві ролі не повинні публікуватися з одного inbound message. Такий короткий тест доводить ownership краще за довгу демонстрацію лише простих питань.