Cornerstone скоротив діагностику БД на 78%
Cornerstone OnDemand (140 млн користувачів, 186 країн) побудувала мультиагентну систему Orion AI на Amazon Bedrock і Strands Agents. Діагностика збою бази даних впала з 45 до 10 хвилин. Систему з 13 агентів команда з трьох людей зробила за 6 місяців.
Алертів-шуму стало на 65% менше — із 10 сповіщень до інженерів тепер доходять лише 3-4. 15-хвилинна затримка звітності між SRE та дата-командою зникла, а завдання на 10+ кроків звелись до одного запиту природною мовою.
Чому поділили на 13 вузьких агентів, а не один універсальний
Архітектура Orion AI — модель «хаб і спиці»: один агент-координатор (TaskExecutor) лише розподіляє запити між спеціалізованими агентами й керує послідовністю кроків, а сам не має власних інструментів доступу до систем — тільки інструменти маршрутизації й контролю кроків. Усі робочі операції виконують 13 окремих агентів, кожен зі своїм набором інструментів і системним промптом.
Принцип команди: розбивати агентів за предметною сферою, а не за складністю завдання. Для діагностики SQL Server це означає три різні агенти на одну проблему. Перший показує блокування й довгі запити та відповідає на питання «що відбувається і чим це загрожує бізнесу». Другий реконструює ланцюжок блокувань до кореневої причини — від миттєвого завершення сесії до рекомендацій щодо архітектурних змін. Третій напряму опитує сервер бази даних через внутрішній DATAOPS API і відповідає на питання «що відбувається прямо зараз». Решта агентів відповідають за моніторинг інфраструктури, аналітику клієнтів, маршрутизацію сповіщень і пошук у внутрішніх регламентах.
Як система визначає, якому агенту передати запит
Приблизно 80% запитів Orion AI розпізнає менш ніж за мілісекунду через пошук за ключовими словами — це швидкий шлях для передбачуваних запитів. Якщо ключових слів недостатньо, щоб зрозуміти намір, система переходить до семантичного пошуку на моделі Amazon Titan Text Embeddings V2, яка підбирає агента за смислом запиту.
Коли жоден інструмент не підходить напряму, запит іде у базу знань Amazon Bedrock Knowledge Bases: вона витягує фрагменти внутрішньої операційної документації, щоб відповідь спиралась на затверджені процедури, а не на вигадані моделлю кроки.
Чотири рівні захисту від помилкових дій
Частина операцій з базою даних руйнівна — наприклад, завершення процесу, що виконується. Через це команда не обмежилась стандартними фільтрами контенту, а побудувала власну логіку guardrails під конкретні ризики DataOps.
- Обмеження прямо в системному промпті кожного агента: заборона небезпечних рекомендацій і вимога використовувати лише неруйнівні методи.
- Підтвердження людиною: деструктивна операція призупиняється, доки користувач не підтвердить дію протягом п'ятихвилинного вікна; якщо час вийшов — дія за замовчуванням відхиляється.
- Окремі модулі перевірки вхідних даних (обмеження довжини, блокування SQL- та prompt-ін'єкцій) і вихідних даних (видалення секретів і персональних даних), а також обмеження частоти запитів, рольовий доступ і облік витрат на кожен запит.
- Заборона відповідати на операційні питання з пам'яті розмови: для будь-якого питання про поточний стан системи агент зобов'язаний звернутись до живих даних.
Де межі підходу й що перевірити перед копіюванням
Пам'ять системи розділена на три рівні — коротка пам'ять у межах сесії (DynamoDB плюс скорочений виклад розмови), довга пам'ять між сесіями (AgentCore memory, прив'язана до ID користувача) і тимчасовий блокнот між кроками агентів усередині одного завдання. Для будь-якого запиту про поточний стан бази даних ця пам'ять повністю обходиться. Якщо впроваджуєте подібну систему у себе, варто одразу перевірити саме цю межу: чи не підмішує агент застарілий контекст із попередньої розмови до відповіді про те, що відбувається прямо зараз.
Інфраструктурне рішення теж не універсальне: обчислення розгорнули на Amazon ECS, бо на старті проєкту середовище Amazon Bedrock AgentCore Runtime ще не було доступне, і команда зараз розглядає перехід на нього як окрему майбутню задачу. Дата запуску Orion AI та вартість проєкту в матеріалі не наведені.