Grab скоротив запуск AI-агента з 2 тижнів до години
Grab перевела понад 500 внутрішніх AI-агентів на власний фреймворк LLM-Kit. Раніше на запуск нового агента йшло два тижні — тепер година: інженер отримує готовий сервіс із секретами, трейсингом і оцінкою якості (ROUGE, BLEU, модель-суддя). Інструменти агенти беруть на льоту з 50+ MCP-серверів, а виклики моделей ідуть через єдиний шлюз GrabGPT (5 провайдерів).
Вартість масштабування агентів ховається не в промптах чи моделях, а в інфраструктурі навколо — секретах, спостережуваності, оцінці якості. Тому Grab обрав гнучкий фреймворк, а не жорстку платформу.
Що саме інженер отримує за годину
Заявка на новий агент у Grab — це форма, а не окремий проєкт. У відповідь інженер отримує репозиторій із готовим FastAPI-сервісом: модулі агента на LangGraph, трейсинг через OpenTelemetry, секрети через Vault і вже підключений service discovery. Ендпоінт для оцінки якості — з першого ж коміту, а не як доробка «колись потім»: відповіді агента одразу можна перевіряти метриками ROUGE, BLEU і другою моделлю-суддею.
Інструменти агент бере не з жорстко прописаного списку, а на льоту — з понад 50 серверів за протоколом MCP. Це означає, що інструмент, зареєстрований один раз, одразу стає доступним усім агентам компанії, а не тільки тому, для кого його писали. Виклики моделей ідуть через єдиний шлюз GrabGPT, який приховує п'ять різних провайдерів за одним OpenAI-сумісним інтерфейсом і сам підставляє облікові дані — прикладному коду провайдер знати не треба.
У пості Grab це сформульовано так: Цикл міркувань агента займав цілий день. Обгортка для продакшену — два тижні. Тобто вузьке місце ніколи не було в «розумній» частині агента — воно було в усьому, що навколо: секретах, спостережуваності, реєстрації сервісу.
Чому фреймворк, а не готова платформа
Grab свідомо не робила LLM-Kit жорсткою платформою з єдиним способом побудови агента. У компанії це пояснюють так: Платформа замкнула б команди в жорстких припущеннях, які швидко застаріли б. Фреймворк дозволив зустріти розробників там, де вони вже були. Тобто LLM-Kit — це не нова абстракція агента і не власна мова опису, а обв'язка навколо інфраструктури, яка в Grab уже існувала.
Аналітик Кай Веенер (Kai Waehner), на якого посилається матеріал, зауважує ширшу закономірність: залежність від конкретного постачальника в агентних системах стійкіша за звичайну прив'язку до API, бо вона накопичується одразу на кількох рівнях — модель, фреймворк, середовище виконання і патерни, які команди будують навколо них. У випадку Grab шлюз GrabGPT знімає прив'язку лише на рівні моделі; фреймворк, середовище виконання і напрацьовані патерни лишаються спільними для всіх 500+ сервісів і поза шлюзом не вирішуються.
Що змінилось, коли агентів стало 500
LLM-Kit розв'язав задачу «зібрати і запустити один агент». На масштабі 500 сервісів проблема змістилась із рівня фреймворка на рівень платформи: шлюз визначає, яку модель усі викликають, спільний MCP-фреймворк дозволяє командам перевикористовувати чужі інструменти, а платформа оцінки показує, чи зміна промпту справді покращила відповіді агента, чи просто зробила їх іншими.
Окремо команда кібербезпеки Grab описала свою систему Palana, яка дозволяє командам експериментувати з автономними агентами, не втрачаючи контролю над ідентифікацією, секретами, мережевим доступом і операційною видимістю. Аналітичний підрозділ компанії тим часом побудував власну багатоагентну систему підтримки розробки. Частину цього платформного шару компанії вже не обов'язково будувати самі: Amazon Bedrock AgentCore і Agent Runtime від Google готові розміщувати агентів, написаних у наявному фреймворку, і одразу постачають ідентифікацію, шлюз та спостережуваність.
На що дивитись, перш ніж копіювати підхід
- Скільки часу займає власне логіка агента (промпт, вибір моделі) — якщо це вже афтернун, а не тиждень, проблема не в бракі AI-навичок, а в інфраструктурі навколо
- Хто у вашій команді відповідає за секрети, трейсинг і оцінку якості агентів — якщо це вирішується щоразу заново для кожного сервісу, саме тут ховається справжня вартість масштабування
- Чи є в компанії єдина точка виклику моделей (аналог шлюзу) — без неї зміна провайдера чи додавання нового означає правки в кожному сервісі окремо
- Чи можна оцінювати якість відповіді агента автоматично (метриками або моделлю-суддею) з першого дня, а не лише через ручну перевірку постфактум
Головний висновок Grab для тих, хто зважує подібне рішення: питання не в тому, яку бібліотеку агентів обрати, а в тому, хто володіє секретами, трейсингом і оцінкою якості. Якщо унікальна робота займає день, а спільна інфраструктура — два тижні, саме інфраструктура і є рішенням, яке варто приймати централізовано. Дати запуску LLM-Kit за межі Grab чи умов доступу до Palana в матеріалі немає.