Перейти к основному содержимому
megapromotingДавайте обсудим

Экспертиза · Интеграции и автоматизации

Чтобы ваши системы говорили друг с другом, без того чтобы кто-то заново вводил те же данные.

Мы соединяем систему записей, магазин, CRM, таблицы и каналы сообщений так, чтобы агент или запланированное правило могли читать и писать в них в реальном времени. Ключи остаются на сервере, у инструментов есть прописанные лимиты, а каждая интеграция тестируется и на случай, если другая система упадёт.

Уже построеноIntegrări proprii, scrise și rulate, măsurate azi în cod: conectorul pentru sistemul de programări Altegio (946 de linii, cu șase unelte expuse agentului), conectorul de CRM amoCRM (2.888 de linii în platforma de mesagerie, plus 12 funcții de server în platforma vocală), Bitrix24 (903 linii, plus 4 funcții), Google Sheets (615 linii, plus 10 funcții și un cont de serviciu dedicat), catalogul viu peste magazin (serviciu de platformă, 318 linii), notificări de lead pe Telegram (1.776 de linii), SMS prin Infobip cu limite anti-abuz, automatizări programate (1.088 de linii) și canalul de chat al unei platforme locale de anunțuri (2.459 de linii). În execuție, agentul poate chema 15 tipuri de unelte interne, pe lângă unelte prin webhook și unelte cu cod propriu rulat în izolare.

Интеграция — это не логотип на странице. Это ответ на очень конкретный вопрос: может ли эта система читаться и записываться в реальном времени, кем, с какими правами, и что происходит, когда она не отвечает? Поэтому наш первый вопрос к любой интеграции — не «с каким API», а «какой у неё публичный вход». Иногда ответ полностью меняет стоимость работы: магазины на WooCommerce, например, публично предоставляют API магазина, который не требует никакого ключа потребителя, поэтому новый клиент подключается только с адресом своего сайта — не с учётными данными, которые нужно сгенерировать, отправить, а затем ротировать.

В нашей платформе сообщений инструмент, который агент может вызвать во время разговора, относится к одному из трёх типов: вызов к webhook, собственный код, запущенный изолированно, или внутренний инструмент платформы. Внутренние инструменты — те, которые мы предпочитаем, потому что они держат ключи вне базы данных: сегодня их пятнадцать, от чтения страницы и записи в электронную таблицу до доступности и создания записи, отправки SMS и запроса каталога продуктов.

Разница между интеграцией, которая держится, и той, которая ломается, почти всегда кроется в мелочах, найденных на практике. Система записи ничего не возвращает, если вы спрашиваете часы специалиста для услуги, которую он не оказывает — услуга и специалист всегда путешествуют вместе. Та же система отвечает отказом, если запрос приходит с заголовком по умолчанию библиотеки HTTP, поэтому каждый запрос должен явно идентифицироваться. Магазин может сообщать цену ноль для товаров с вариантами, а поиск по пустым словам возвращает весь каталог. Таких деталей по десять на каждую интеграцию, и ни одна из них не в документации.

Над интеграциями стоят автоматизации: правила, которые выполняются со временем, а не по чьему-то запросу. У нас они запланированы встроенным планировщиком — возобновление разговоров без ответа, первое сообщение новому контакту, постановка на паузу и повторный запуск агента после рабочего времени — каждая со своими счетчиками, чтобы было видно, сколько запусков было, сколько сообщений ушло, сколько было пропущено и почему. Автоматизация без счетчика — это автоматизация, о которой нельзя сказать, работает ли она.

Automatizare transparentă — integrări care se pot verifica · video în română, cu subtitrare și transcriere

Transcrierea completă

Să intrăm direct în subiect. Astăzi vom diseca realitățile tehnice și, sincer, adesea ignorate, ale automatizării prin asistenți bazați pe inteligență artificială. Ne vom concentra pe o abordare super pragmatică a platformei iCat.md dezvoltată de Mega Promoting. Nu avem promisiuni de marketing astăzi și, cu siguranță, nu avem concepte vagi. Discutăm despre o platformă aflată direct în producție, cu funcționalități explicate direct din arhitectura bazei de date. Așa că haideți să vedem cum arată, de fapt, automatizarea complet transparentă. Agenda acestei analize este simplă și la obiect. Trecem prin problema timpului, mecanica tehnologiei, un caz real, limitele clare ale sistemului, managementul datelor și pașii următori. Începem cu prima secțiune, problema timpului. Știți cu toții acea întrebare extrem de frustrantă? De ce o întreagă echipă de suport pierde ore bune, zi de zi, scriind de mână răspunsuri la fix aceleași cinci întrebări? Informația există deja pe site-ul companiei, dar, cu toate astea, clienții continuă să ceară detaliile în mod repetat. Și exact asta este esența problemei noastre. Fără o soluție tehnică potrivită, toate aceste solicitări repetitive pur și simplu înfundă mesageria directă, nu contează dacă e Instagram sau Messenger. În consecința, răspunsurile întârzie masiv pentru clienții care au cu adevărat o problemă complexă, cererile se rătăcesc în marea de mesaje, iar întregul proces de suport devine practic o cutie neagră pe care nu o poți nici verifica, nici măsura. Partea a doua. Cum funcționează, de fapt, tehnologia sub capotă? Uite care-i treaba. Setarea platformei se bazează pe patru pași foarte logici. Mai întâi conectăm canalele de comunicare folosind cod propriu. Apoi se indexează toată baza de cunoștințe. Urmează legarea uneltelor care pot executa acțiuni în sistemele voastre existente. Iar la final, și acest detaliu este vital, se configurează un traseu clar înregistrat direct în baza de date prin care botul predă discuția unui operator uman. Totul este un sistem vizibil și perfect configurabil. Acum, un aspect absolut fascinant. Nu vorbim din plian de aici. Acestea sunt setări extrase direct din schema bazei de date. Când asistentul are nevoie de un răspuns, el folosește o așa numită căutare hibridă. Implicit, algoritmul extrage 5 fragmente de text, aplică un prag strict de similitudine de 0-70 și acordă o importanță de 30% potrivirii exacte a cuvintelor. Totul este procesat prin modelul Text Embedding 3 Small. Practic, sistemul transformă cuvintele în concepte matematice pentru a prinde contextul exact. Răspunsurile nu sunt oghicitoare, ci matematică pură. Rețineți acest număr. 15. Este o limită tehnică absolută în sistem. Reprezintă timpul maxim, în secunde, alocat pentru a rula orice unealtă sau căutare. Dacă o integrare externă durează mai mult de atât, să zicem că are nevoie de 40 de secunde, nu o putem lăsa în fluxul live-a conversației. Ea trebuie procesată asincron, altfel s-ar rupe complet ritmul natural al dialogului. Și mai e ceva. Oamenii scriu pe chat în rafale, nu? 2, 3, 4 mesaje scurte trimise unul după altul. Pentru a nu înnebuni sistemul, există un tampon de concatenare de 15 secunde. Tot ce intră în această fereastră se lipește și devine o singură cerere clară. Mai mult, pe platforme ca Meta, unde uneori te lovești de mesaje duplicate trimise din eroare, sistemul aplică un filtru de memorie de 120 de secunde pe ID-ul mesajului. Astfel, clientul primește un singur răspuns coerent, nu 3 alarme false. Secțiunea a treia. Să vedem un caz real. Avem acest scenariu clasic de e-commerce. Avem un magazin online, cu un catalog impecabil pe site, dar care primește o avalanșă de mesaje private pe Instagram și Messenger? Mai e în stoc? Ce preț are? Aici integrarea s-a făcut elegant, conectând asistentul direct la interfața publică Store API de la WooCommerce. Fără complicații de securitate, catalogul viu al magazinului a fost pur și simplu pus în mânile asistentului. Doar aici intervine realitatea tehnică a fiecărei platforme, chiar și sub umbrela aceleiași companii, cum e Meta. Pe Messenger, asistentul vă poate arăta carusele de produse superbe. Pe Instagram, botul o să vă răspundă doar cu text și cel mult o imagine simplă. De ce? Pur și simplu pentru că Meta nu suportă acele șabloane generice pe Instagram. Asistentul trebuie să joace exact după regulile canalului unde se află. Aici este punctul critic. Ce se întâmplă când botul este depășit de situație? Ei bine, în baza de date conversația are stări explicite. Când o întrebare iese din zona de confort a catalogului, firul de discuție trece imediat din starea bot în starea umană. Și partea genială e că sistemul contorizează timpul în care răspundă operatorul uman, marcând totul clar, status OK, avertiziment sau termen depășit. Tot contextul este predat omului, fără să se piarda absolut nimic pe drum. Secțiunea A4 Limitele sistemului Pentru că transparența înseamnă să știm ce nu poate face. Sunt câteva limite ferme pe care trebuie să le acceptăm. Nu puteți trimite mesaje proactive pe WhatsApp dacă au trecut mai mult de 24 de ore de la mesajul clientului. Meta va trânti o eroare, mai exact eroarea 131047, iar acțiunea va eșua. Sistemul nu face fișie RPDF, nu citește atașamente. La partea de limbi străine, traducerile merg doar într-un singur sens. Clientul primește răspunsul tradus, dar operatorul vede originalul. Și, deși integrarea cu 999.md funcționează, este neoficială și se bazează pe cookie-urile din browser. Dacă platforma își modifică mecanismele, conexiunea cade și necesită reparații. Și rețineți neapărat asta. Asistentul este oglinda datelor voastre. Un preț greșit pe site va deveni garantat un preț greșit în conversație. El acționează ca un cititor, nu ca un manager de magazin. Nu va corecta din proprie inițiativă erorile umane din cataloge. Infrastructura tehnică de aici nu e o joacă. Totul este ținut pe un server privat Microsoft Azure. Discutăm despre o bază de date MySQL extrem de structurată, cu peste 80 de tabele modelate clar pentru a separa canalele și pentru audit. Cheile de acces pentru WhatsApp, care sunt supersensibile, folosesc criptare fernet. Pe lângă asta, la nivel de web, domeniile pentru widgetul de chat sunt adăugate manual într-o listă albă. Nimeni nu se conectează fără permisiune explicită. Trebuie însă să abordăm o realitate evidentă. Oamenii vor scrie tot felul de date personale în acele ferestre de chat, numere de telefon, adrese. Tehnic, nu ai cum să blochezi un câmp de text liber. Așa că soluția este administrativă. Când implementați un astfel de sistem, aveți nevoie, din secunda 1, de politici clare de retenție care să dicteze exact cine are voie să vadă acele date și pentru cât timp sunt stocate. Și am ajuns la punctul 6. Pașimul mători. Filozofia centrală a întregului sistem poate fi rezumată prin acest citat. Un asistent utim nu este cel care compune poezii sau scrie frumos, ci acela care este conectat la informații reale și, foarte important, știe exact unde trebuie să se oprească. Automatizarea eficientă în business înseamnă preluarea corectă a datelor și siguranța cu care cedes controlul unui operator uman la momentul oportun. Prin urmare, pasul următor nu este să cumpărați un soft, ci să vă analizați cu atenție procesele actuale. Evaluați ce fluxuri de lucru merită cu adevărat să fie construite și automatizate, cum se pot conecta ele în siguranță și, cel mai important, stabiliți cum veți măsura rezultatele cu date reale, nu cu iluzii de marketing. Și vă las cu această temă de gândire. Dintre toate procesele de comunicare dintr-o afacere, care sunt acelea care necesită cu adevărat empatia și tactul unui om și care sunt, de fapt, doar sarcinii repetitive ce așteaptă pur și simplu să fie conectate cu precizie la baza de date corectă? Orice plan de automatizare ar trebui să plece de la această întrebare. Mulțumim că ați fost alături de noi în această analiză!

Что входит

Работа, по составляющим

Сначала мы проверяем, какой публичный вход есть у системы

Для магазинов на WooCommerce мы используем публичный магазинный API, которому не нужен consumer key: клиент подключается только по адресу сайта. Это выбор, у которого есть реальные последствия, а не только эстетические — мы заменили им написанные вручную инструменты, которые хранили ключи магазина в открытом виде в базе данных. Когда у системы нет публичного входа, мы переходим к аутентификации, но тогда ключ становится элементом, которым управляют, а не тем, который забывают в строке базы данных.

Ключи остаются на сервере, не в инструменте и не в странице

SMS-инструмент внутренний для платформы именно потому, что среда, в которой выполняется собственный код инструмента, не имеет доступа к переменным среды — если бы отправка выполнялась из кода инструмента, ключ пришлось бы записывать в базу данных, а этот ключ может отправлять сообщения за счет всех. То же и с системой записи: партнерский токен один, он хранится в серверной среде, а клиент указывает только идентификатор своей компании.

Агент вызывает инструмент во время разговора, с параметрами и сроком

У каждого инструмента есть написанное для модели описание, типизированные параметры с обязательными и необязательными полями, и собственный срок выполнения — от 15 секунд для списка услуг до 30 для поиска доступности. Срок для каждого инструмента — не деталь: без него медленная интеграция блокирует разговор, а человек на другом конце слышит тишину.

Реальные записи в системе салона или клиники

Шесть инструментов над Altegio: список услуг с реальными ценами, специалисты, полная доступность, создание записи, отмена и изменение. Доступность возвращает не только «свободен/занят»: она возвращает, какие специалисты оказывают запрошенную услугу, и первые свободные часы для каждого, отсортированные по самому раннему, именно чтобы агент мог предложить конкретную альтернативу вместо того, чтобы говорить «недоступно».

Каталог магазина, читаемый вживую

Цена и доступность читаются из магазина в момент вопроса, а не из устаревшей копии. Каталог загружается постранично, до 30 страниц по 100 товаров, хранится в временной памяти десять минут на сайте и нормализуется в единую форму, читаемую без изменений всеми потребителями — включая карусель товаров в мессенджере, которой нужна числовая цена, и виджет на странице, которому нужен заголовок.

CRM, таблицы и каналы сообщений

amoCRM и Bitrix24 с полным OAuth, обновлением токена и проверкой состояния. Google Sheets через отдельную учетную запись службы, отделенную от остальных учетных данных, с записью, запускаемой агентом. Telegram для уведомлений о лидах. SMS через Infobip. Плюс чат-канал локальной платформы объявлений, подключенный с собственным refresh token — тип интеграции, которого нет ни в одном международном каталоге и который очень важен локально.

Автоматизации, которые выполняются со временем, со счетчиками

Возобновление разговоров без ответа, первое сообщение новому контакту, постановка на паузу и повторный запуск агента после рабочего времени. Каждый запуск увеличивает видимые счетчики: сколько запусков, сколько отправленных сообщений, сколько пропущено потому, что агент был остановлен, сколько потому, что не было конфигурации, сколько ошибок. Без них единственный способ узнать, что автоматизация умерла, — жалоба клиента.

Антиабузные лимиты, потому что решение принимает модель

Инструмент, вызываемый языковой моделью, нуждается в границах, которые модель не может перейти. Для SMS: в режиме «к фирме» получатель берется из конфигурации, никогда не от модели; в режиме «к клиенту» номер нормализуется и проверяется. Помимо этого, дневной лимит на одного агента, пауза в одну минуту на тот же номер и ограничение длины сообщения. Это ограждения, написанные в коде, а не инструкции в prompt — prompt можно обойти, ограждение нельзя.

Выходные фильтры, для данных, которые не должны выходить

Когда интеграция возвращает больше, чем должен знать клиент, мы фильтруем на выходе, а не надеемся, что агент удержится. Реальный пример: для клиента в сфере транспорта политика запрещает агенту диктовать номер телефона водителя, но API возвращал эти номера в ответе. Мы написали фильтр, который рекурсивно проходит результат инструмента и удаляет контактные поля водителя, сохраняя номера диспетчерской. Фильтр применяется ровно там, где нужно, а не глобально, чтобы случайно не скрыть что-то другое.

Как это выглядит

Путь, шаг за шагом.

01

Инвентарь: какие системы, какие шлюзы, какие права

Какие системы задействованы, что каждая из них раскрывает, кто имеет право создавать учетные данные и кто их ротирует. Для каждой — основной вопрос: можно ли читать без аутентификации? Если да, интеграция становится намного дешевле и гораздо проще воспроизводится для второго клиента.

02

Коннектор: объявленные инструменты, ключи на сервере, сроки

Каждое действие становится инструментом с названием, описанием, написанным для модели, типизированными параметрами и собственным сроком. Ключи остаются в серверной среде. В конце агент не «умеет делать» что-то расплывчатое: у него есть конечный набор действий, каждое со своими границами.

03

Тест на случае, который ломается, а не только на том, который работает

Коннектор тестируется на правильном запросе, на неполном запросе, на системе, которая отвечает медленно, и на системе, которая не отвечает вовсе. Что говорит агент, когда интеграция падает, — это решение по проектированию, а не ошибка, которую обнаруживает клиент: мы предпочитаем честное сообщение и передачу человеку вместо правдоподобной импровизации.

04

Устойчивость к нестабильности другой системы

Повторная попытка с увеличивающимися паузами, но только при ошибках, которые имеет смысл повторять, — ограничение по rate или ошибка сервера, а не неверный запрос, который будет неверным и во второй раз. А когда проблема на уровне сети другой стороны, подход иной; пример ниже — как раз такой случай.

05

Передача: что меняется, когда меняется поставщик

Мы отмечаем, что ломается, если другая система меняет свой API, какие учетные данные истекают и когда, что нужно обновить вручную. Интеграция без этого списка — скрытый долг: она работает безупречно до того дня, когда перестает работать, и никто не знает почему.

Un centru. În jur, ce intră în el — pe trasee separate.CENTRUL SE SPRIJINĂ PE CE E ÎN JURUL LUI
Sistemele externe din jurul conversației: programări, catalogul magazinului, CRM, foi de calcul, SMS și canale de mesaje — fiecare citit la cerere, cu cheile rămase pe server.

Данные

К чему прикасаемся, где оно лежит и сколько остаётся

Вопросы, которые задаёт всякий, у кого есть ответственный за защиту данных, — заданы здесь раньше, чем их задаст он.

Где хранятся учетные данные
Ключи поставщика платформы хранятся в серверной среде, а не в базе данных и никогда не на клиентской странице. Собственные учетные данные клиента — там, где интеграция их требует — хранятся в зашифрованном виде. Разница важна: скомпрометированный ключ платформы затрагивает всех, учетные данные клиента затрагивают один аккаунт; мы относимся к ним по-разному, потому что риск разный.
Что сохраняется из внешних систем, а что нет
Каталог товаров не копируется: он читается по запросу и хранится во временной памяти десять минут, чтобы десять последовательных вопросов об одном и том же магазине не означали десять полных обходов. Записи у нас не дублируются — источником истины остается система салона. Мы сохраняем след разговора и результат действия, а не копию базы другой системы.
Что попадает в языковую модель
Результат инструмента входит в разговор, значит, входит и в контекст модели. Поэтому фильтрация выполняется на результате, до того как он будет передан модели, а не в инструкциях. Поля, которые клиент не имеет права слышать, удаляются у источника; то, что удалено, нельзя продиктовать, независимо от того, как спрашивают агента.
Кто может подключить интеграцию
Подключение интеграции — это аутентифицированная операция, привязанная к аккаунту бизнеса, а полученные инструменты прикрепляются к конкретному агенту — не ко всем. У агента есть ровно те инструменты, которые нужны для его роли. Это та же логика, что и с доступом сотрудника: ему не дают все ключи только потому, что так проще.
Что осталось исправить, сказано открыто
Не все интеграционные модули в нашей платформе находятся на одном уровне. Перечисленные здесь написаны и запущены. Есть и начатые модули, в несколько десятков строк, которые пока не делают ничего полезного — мы не представляем их как доступные и не включаем ни в одно предложение. Если вам нужна система, которая у нас находится на этой стадии, мы рассматриваем ее как работу, которую нужно построить, с предварительной проверкой совместимости, а не как пункт для галочки.

Случай

Интеграция падала периодически, и проблема была не у нас

Ситуация

Один коннектор CRM иногда работал, а иногда нет, без видимого на первый взгляд шаблона. Запросы зависали, пока не превышали лимит выполнения серверной среды, поэтому в журналах появлялось превышение времени — признак, который ошибочно направляет искать медлительность в собственном коде.

Что мы построили

Причина была в сети, на другой стороне. Доменное имя аккаунта CRM разрешается в несколько IP-адресов, а часть узлов кластера была нездоровой. Обычный HTTP-запрос выбирает один адрес и, если тот не отвечает, не пробует остальные адреса, возвращённые DNS — автоматического перехода к следующему ответу нет. Исправление состояло в том, чтобы больше не использовать стандартный HTTP-клиент для этого домена: мы сами разрешаем имя, открываем зашифрованные соединения напрямую к каждому адресу параллельно, с коротким сроком ожидания на каждый, и используем первый, который отвечает; если в одном раунде все холодные, процесс повторяется.

Что получилось

Периодические сбои перестали быть лотереей. Что важнее для клиента: диагностику стало можно выразить одной фразой — «узлы поставщика периодически недоступны, и мы их обходим» — вместо «иногда не работает».

Чего этот случай не говорит

Это исправление компенсирует проблему другого, и это нужно говорить. Оно добавляет сложность в наш код из-за дефекта в инфраструктуре поставщика; если тот исправит свой кластер, сложность останется у нас. Мы документируем это именно так, чтобы её можно было убрать, когда она больше не понадобится.

Вопросы

О чём нас спрашивают перед тем, как позвонить

Какие системы вы реально, а не теоретически, подключили?

Систему записи Altegio, с шестью действиями, вызываемыми агентом. amoCRM и Bitrix24, с полным OAuth и обновлением токена. Google Sheets, с отдельным сервисным аккаунтом. Магазины на WooCommerce, через публичный API магазина. Telegram, для уведомлений. Infobip, для SMS. Чат-канал локальной платформы объявлений. Плюс каналы сообщений Meta и Telegram для разговоров. Для любой другой системы — включая платформы магазинов, которые мы не довели до конца — честный ответ таков: по запросу, после проверки совместимости, рассматриваемой как работа, а не как настройка.

Мой магазин должен генерировать мне API-ключи?

Для WooCommerce — нет. Мы используем публичный API магазина, который не требует ключа потребителя — вы подключаетесь через адрес сайта. Это и безопаснее, не только проще: таким подходом мы заменили более старые инструменты, которые держали ключи магазина в открытом виде в базе данных. Для других платформ это зависит от того, что они предоставляют; мы проверяем это до того, как что-либо обещать.

Может ли агент реально создать запись, а не только сказать, что делает это?

Да, если система записи это позволяет. Он создаёт запись, может её отменить и изменить, а также проверяет доступность заранее. Деталь, которая узнаётся только на практике: в той системе услуга и специалист путешествуют вместе — если вы запрашиваете свободные часы специалиста для услуги, которую он не оказывает, вы получаете ноль результатов, а не ошибку. Поэтому инструмент доступности возвращает всех специалистов, которые оказывают услугу, и первые свободные часы для каждого, чтобы агент мог предложить конкретную альтернативу.

Куда попадают мои ключи?

Ключи платформы остаются в серверной среде, никогда не в базе данных и никогда на вашей странице. Учётные данные, которые принадлежат вам, хранятся в зашифрованном виде. Правило, которое мы применяем: если ключ может тратить деньги или читать данные всех клиентов, ему не место нигде, куда попадает код, выполняемый по запросу языковой модели.

Может ли агент отправлять SMS кому захочет?

Нет, и это намеренное ограничение. В режиме уведомления компании получатель берется из конфигурации — модель не может выбрать его сама. В режиме для клиента номер нормализуется и проверяется. Сверху есть суточный лимит на агента, пауза в одну минуту на тот же номер и ограничение по длине сообщения. Это ограждения в коде, а не инструкции в prompt; prompt можно обойти в разговоре, ограждение — нет.

Что происходит, когда чужая система падает или отвечает медленно?

У каждого инструмента свой срок выполнения, чтобы медленная система не блокировала разговор. Мы повторяем попытки с увеличивающимися паузами, но только на тех ошибках, которые стоит повторять — ограничение скорости или серверная ошибка, а не неверный запрос. А поведение агента при сбое прописывается в сценарии: он говорит, что сейчас не может проверить, и передает разговор, вместо того чтобы выдумывать правдоподобный ответ.

Что происходит, если поставщик меняет свой API?

Что-то ломается, и именно поэтому мы предпочитаем официальные шлюзы вместо чтения страниц. Инструменты, которые извлекают информацию из HTML сайта, ломаются при любом изменении темы — мы намеренно заменили их одной реализацией поверх официального API, именно чтобы не поддерживать десятки хрупких вариантов. Когда альтернативы нет, мы говорим, что это хрупкое решение, и относимся к нему соответственно.

Вы можете делать автоматизации без агента, только по расписанным правилам?

Да. Повторный запуск разговоров без ответа, первое сообщение новому контакту, остановка и запуск агента по рабочему графику — это запланированные задачи, которые работают сами. У каждой есть собственные счетчики запусков, отправленных сообщений, пропущенных сообщений и ошибок, чтобы на вопрос «запустилось ли?» можно было ответить цифрой, а не предположением.

Как вы гарантируете, что агент не скажет лишнего из-за интеграции?

Мы фильтруем результат до того, как он попадет к модели, а не после. Конкретный случай, который мы решили: политика клиента запрещала агенту диктовать номер телефона водителя, но API возвращал эти номера. Мы написали фильтр, который рекурсивно проходит по ответу инструмента и удаляет поля контактов водителя, сохраняя номера диспетчерской, примененный именно к этому инструменту. То, что не попадает к модели, не может быть произнесено, независимо от того, как агента спрашивают.

На чём основаны утверждения выше (18 источников)

18 из них — код и файлы из наших репозиториев. Мы не публикуем их название и строку: вместе, на одной странице, они слишком точно описали бы, как устроены системы, которые принадлежат не только нам. Мы разбираем их вместе с тобой, в репозитории, по запросу — проверка остаётся возможной, просто она проходит в разговоре.

Что вы хотели бы наладить?

Расскажите о своём процессе. Вместе определим, что стоит построить, что можно подключить и как проверим результат.

Давайте обсудим