Capital One ставить на власних AI-агентів

Що Capital One виніс за межі одного чатбота

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

Тому банк розділив роботу на кілька ролей. Один агент визначає намір клієнта, другий отримує конкретні інструкції й готує підсумок, третій перевіряє факти, четвертий перетворює результат на оформлений документ із потрібними деталями. Це не декоративна схема, а спосіб прибрати з одного запиту надто багато різних завдань.

• Understanding agent: зрозуміти, що саме каже клієнт і який у нього намір.
• Reasoning agent: сформувати підсумок за заданими інструкціями.
• Validation agent: перевірити, чи підсумок точний.
• Explaining agent: оформити результат у документ, який можна передати співробітнику.

Практичне формулювання для бізнес-команди: Не просимо AI одразу вирішити все. Розкладаємо задачу на розуміння, висновок, перевірку і пояснення.

Другий приклад: Chat Concierge для автопокупок

Той самий принцип Capital One застосовує в Chat Concierge — клієнтському помічнику для auto-shopping. Тут використовується кастомізована версія open-weight моделі Meta Llama, навчена з урахуванням власних даних Capital One. Роль моделі не зводиться до загальної розмови: система має працювати з бізнес-правилами, планом дій, точністю та поясненням результату.

Розподіл ролей інший за предметом, але подібний за логікою: один агент веде розмову з клієнтом, другий будує план дій на основі бізнес-правил, третій оцінює точність, четвертий пояснює й валідовує результат. Для нетехнічної команди це корисний шаблон: клієнтський інтерфейс і внутрішня перевірка не повинні бути однією й тією самою дією.

Готова рамка для схожого процесу: Агент 1 спілкується з клієнтом. Агент 2 будує план за правилами бізнесу. Агент 3 перевіряє точність. Агент 4 пояснює результат у зрозумілому форматі.

Третій приклад: оптимізація backend за latency і cost

Capital One використовує агентну систему не лише в клієнтських сценаріях. Один із внутрішніх прикладів — автономне рішення для налаштування backend hosting infrastructure. У світі LLM-оптимізацій нові покращення з’являються постійно, але вони не завжди сумісні: дві окремо хороші оптимізації в комбінації можуть дати регресію продуктивності.

Тут агент не замінює дослідника. Дослідник задає search space, а система бере на себе механіку: підготувати експеримент, запустити його й подати зведення результатів. Людина отримує не магічну відповідь, а структурований матеріал для вибору конфігурацій, які дають кращу latency.

• Людина визначає простір пошуку.
• Система готує експерименти.
• Система запускає перевірки.
• Система підсумовує результати для дослідника.
• Людина оцінює, яка серія оптимізацій і конфігурацій підходить.

Формула для внутрішніх процесів: AI не обирає ціль замість експерта, а перебирає дозволені варіанти й приносить перевірене зведення.

Межі застосування і перевірки перед довірою

Цей підхід працює там, де є власні дані, правила, номенклатура, governance і guardrails. У Capital One прямо пов’язують якість із попередніми інвестиціями в data transformation, cloud adoption, enterprise-wide AI platform і кастомізацію open-weight моделей на proprietary data. Без цього multi-agent схема може лише розмножити помилки між ролями.

Прийом слабшає, якщо задача потребує свіжого контексту, але система не має real-time data. Vanee окремо підкреслює, що дані в реальному часі критичні для live customer або associate interactions. Так само небезпечно запускати proactive або event-driven AI без rigorous testing and monitoring: такі системи мають діяти не після запиту людини, а після виявлення умов для дії.

• Перевірити, чи є власні дані, яких немає у загальних frontier models.
• Перевірити, чи модель навчена на політиках і номенклатурі компанії.
• Перевірити, чи є окремий validation agent або інший механізм fact-checking.
• Перевірити, чи результат оформлений так, щоб його міг використати співробітник.
• Перевірити, чи є governance, guardrails, testing і monitoring.
• Перевірити, чи не дає комбінація оптимізацій регресію продуктивності.

Типова помилка — просити один AI одночасно зрозуміти клієнта, застосувати правила, зробити висновок, перевірити себе й написати фінальний документ. У кейсі Capital One саме це рознесли на спеціалізованих агентів. Друга помилка — вважати готову frontier-модель достатньою там, де перевага компанії лежить у власних даних, політиках і робочій мові.