Forter навчив 200 співробітників будувати AI-агентів за 2 тижні
Forter (фрод-скоринг для платежів, дані про ~2 млрд ідентичностей) провів 2-тижневий спринт-хакатон для всього R&D, включно з аналітиками без досвіду коду. Основа — власний MCP-сервер Toolchain: до старту в ньому було ~20 інструментів, за 5 тижнів підготовки — 60, до кінця спринту — майже 100. Замість RAG, який визнали надто складним за 2 тижні, обгорнули наявний корпоративний пошук Glean у три MCP-інструменти: пошук, читання, резюме.
Що зібрали за два тижні, окрім базових чат-ботів
Аналітики у Forter здебільшого прийшли з нетехнічних професій — хтось був юристом, хтось психологом, хтось лабораторним науковцем — і з кодом раніше майже не стикався. Одна з них, з бекграундом лабораторної науки, добре знала, як правильно будувати й перевіряти гіпотезу; молодші колеги не завжди дотримувалися цієї дисципліни, робили передчасні висновки й потім поверталися до досліджень заново. Вона зібрала агента з цією експертизою — він підказував колегам, як загострити гіпотезу ще до початку експерименту. На інженерному боці подібний принцип застосували до «BetterNext» — внутрішньої назви постмортемів після інцидентів: агент знав, що має містити якісний розбір, і ставив авторам незручні уточнювальні запитання.
Складніший приклад — агент для gap-аналізу: коли показники фрод-детекції для якогось мерчанта погіршувалися, агент підключався до Snowflake, викликав спеціалізовані Databricks-ноутбуки і за розгорнутим системним промптом пропонував конкретні зміни конфігурації для цього мерчанта.
«Системні експерти» Layla і Penny
Найдалі пішли агенти Layla і Penny — вони отримали доступ одразу до аналітичного коду, поточної продакшн-конфігурації та даних про транзакції, а також до метаданих про тисячі взаємопов'язаних внутрішніх компонентів системи фрод-скорингу Forter. Layla може відповісти на питання на кшталт «чому цю транзакцію відхилили» чи «що зміниться в системі, якщо змінити цей компонент» — і, за словами доповідача, її знання про систему ширші, ніж у будь-якого окремого співробітника.
Layla створювалася для інженерів і аналітиків, але знала про систему настільки багато, що її передали командам customer success і підтримки клієнтів — вона перехоплює частину запитів, які раніше йшли до інженерів. Penny працює за тим самим принципом, але відповідає на питання про білінг: чому конкретну транзакцію виставили саме так.
Платформа під три різні сценарії
Користувачам були потрібні три типи агентів: інтерактивний чат, агенти за подією (найчастіше — новий тікет у Jira чи Asana) та агенти за розкладом. Для чату дали два варіанти. No-code — на основі опенсорсного LibreChat, який якраз перед спринтом отримав підтримку MCP, але не дозволяв обмежити, якими інструментами агент користується в конкретному чаті. Команда обійшла це, створивши кілька окремих підключень до Toolchain, кожне з власним набором інструментів.
- Плюси LibreChat: швидкі експерименти, у чаті видно, який саме інструмент викликається і з якими параметрами.
- Мінуси: MCP-з'єднання іноді розривалися, у зібраних так агентів немає контролю версій і гнучкості налаштувань.
Code-based варіант — шаблонний репозиторій з повною кастомізацією, але аналітикам було значно важче довести його до розгортання. Вже після спринту команда зібрала AI Hub, що поєднує швидкість LibreChat із прямою інтеграцією в Toolchain; доповідач визнав, що шкодує, що не встигли зробити це до спринту — такий інструмент збирається за кілька днів. Для агентів за подією чи розкладом обрали фреймворк Strands замість LangChain — через простіший для навчання API, а запуск підключили до вже наявних Argo workflows, тож окрема інфраструктура під агентів не знадобилася.
Де підхід дав збій
RAG свідомо не робили: команда вважала, що правильно розбити документи на фрагменти, проіндексувати, знайти релевантні шматки й відранжувати їх — навряд чи вдасться зробити добре й узагальнено за два тижні. Обхідний шлях з обгортанням наявного пошуку Glean спрацював, але підходить лише там, де в компанії вже є зрілий корпоративний пошук, який можна підключити напряму.
Ще одне обмеження: занадто великий набір інструментів для одного агента плутає модель і може призвести до небажаних дій, тому в Toolchain для кожного підключення свідомо давали доступ лише до потрібних інструментів. Сам Toolchain також фіксував споживання токенів і використання інструментів по кожному підключенню — це давало командам видимість, хто й що саме викликає.
Інструмент scaffold create, який дозволяв за назвою агента, системним повідомленням і списком інструментів швидко створити новий репозиторій для агентів за подією чи розкладом, не витримав перевірки часом: аналітикам і розробникам однаково було незручно доводити свіжий репозиторій до розгорнутого стану, а коли команда хотіла додати нову можливість на кшталт кращого трейсингу, доводилося вручну проходити кожен окремий репозиторій агента.