Ninth Wave будує онбординг банків через AI-агентів

Чому не одна модель, а сім агентів під оркестратором

Перед тим як зупинитись на мультиагентній схемі, Ninth Wave розглядала два інші варіанти. Перший — власні моделі на серверах компанії: повний контроль, але додаткове навантаження на інфраструктуру та команду. Другий — один AI-агент з retrieval-пошуком по документації (RAG-патерн): простіше в реалізації, але точність падала одразу на кількох задачах — мапінгу полів, пошуку, аналізі розбіжностей, відповідях на запитання. Мультиагентна архітектура складніша на старті, зате кожен агент тримає окремий контекст і інструкцію під одну задачу, не конкурує за місце в промпті з іншими запитами, і точність не деградує при додаванні нових типів задач.

Архітектуру тримають три рішення. По-перше, маршрутизація за наміром: оркестратор класифікує запит один раз і передає конкретному спеціалісту — контекстне вікно кожного агента лишається «чистим», а результат передбачуваним. По-друге, вибір моделі під задачу: легкі моделі обробляють високооб'ємні прості запити, складніші — мапінг, аналіз розбіжностей і інтерактивні відповіді. Тобто потужність моделі підбирають під складність задачі, а не女 женуть усе через одну модель. По-третє, контекст обмежений тенантом: перед викликом агента застосунок збирає в запит дані саме того банку, з яким працює, — інформація одного банку не потрапляє в сесію іншого, хоча обидва працюють на спільній моделі.

Сім спеціалістів і де саме працює RAG

Оркестратор розподіляє запити між сімома агентами: пошук по документації порталу, відповіді на запитання по документації Compass і стандарту FDX, автоматична класифікація завантажених документів, мапінг полів FDX до структури API конкретного банку, аналіз розбіжностей у форматах і назвах полів, ведення покрокових онбординг-воркфлоу та складання наративу оцінки готовності.

Лише останній агент — оцінка готовності — звертається до бази знань Amazon Bedrock (RAG). Решта шести агентів отримують контекст напряму із застосунку, що дає команді повний контроль над логікою пошуку і ранжування. Виняток зроблено свідомо: цьому агенту потрібно синтезувати відповідь по всьому корпусу референсних документів FDX, який фізично не вміщається в один запит, тож RAG тут — правильний інструмент саме для цієї задачі, а не для решти агентів.

Сам числовий показник готовності до FDX модель не рахує взагалі. Він обчислюється детерміновано в коді застосунку — за покриттям обов'язкових полів у OpenSearch:

оцінка_готовності = замаплені_обов'язкові_поля / усі_обов'язкові_поля_FDX

Причина — аудиту потрібен точний, відтворюваний результат, а не ймовірнісна оцінка моделі.

Безпека для зовнішніх партнерів банку

Compass одночасно обслуговує внутрішні команди Ninth Wave і зовнішніх розробників банків та фінтех-партнерів, тож посилення безпеки виділили в окрему фазу проєкту.

• Кожен запит проходить через CloudFront (TLS 1.2+, HSTS) і WAF з політикою «заборонено за замовчуванням» ще до того, як дістанеться логіки застосунку
• Автентифікація — OAuth2/OIDC з обов'язковою багатофакторною перевіркою; ідентичність банку передається в усі подальші сервіси, щоб обмежити кожен запит даних саме цим банком
• Секрети зберігаються в Secrets Manager з окремими ключами шифрування на середовище, доступи — за принципом найменших привілеїв, уся активність логується
• Дані кожного банку ізольовані на рівні окремих індексів OpenSearch і префіксів сховища
• Обмеження поведінки й безпеки задаються окремо для кожного агента на рівні застосунку — можна донастроїти одного агента, не чіпаючи інших
• AI-навантаження винесене в окремий обліковий запис через міжобліковий IAM-доступ — це стримує наслідки, якщо один компонент буде скомпрометовано

Це дозволяє системі відповідати вимогам SOC 2 і PCI DSS, які й до впровадження Compass були стандартом для Ninth Wave.

Впровадження й результат

Проєкт пройшов п'ять фаз: базова інфраструктура (OpenSearch, сховище, керування стеками через CloudFormation/CDK), портал для банків і партнерів з автогенерацією гайдів мапінгу, розгортання оркестратора й агентів, посилення безпеки, і нарешті бета-запуск для перших клієнтів з подальшим виходом у продуктив.

Кожен агент окремо моніториться: кількість викликів, витрачені токени, затримка і вартість — це видно в CloudWatch і на дашбордах Grafana, алерти йдуть через SNS. Деплой автоматизований через GitHub Actions:

push → збірка образу → Amazon ECR → новий ECS task definition → rolling deploy на Fargate → circuit-breaker rollback при провалі health-check

Автоматичний відкат критичний саме тому, що зміна в промпті чи контексті агента може зіпсувати точність відповідей ще до того, як це стане видно в метриках.

Результат — скорочення часу на мапінг і аналіз API полів на 95%, спільний робочий простір замість email-переписки й таблиць, розширений самообслуговуваний доступ для зовнішніх розробників через чат-боти документації, і брендований портал для кожного банку, щоб самостійно запрошувати своїх агрегаторів і фінтех-партнерів.