Grab скоротив запуск AI-агента з двох тижнів до години
Grab перевів 500+ внутрішніх агентів на фреймворк LLM-Kit: інженер заповнює форму — і отримує готовий сервіс із логуванням, секретами у Vault та оцінкою якості (ROUGE, BLEU, модель-суддя) з першого коміту. Інструменти агенти беруть на льоту з 50+ MCP-серверів, моделі — через єдиний шлюз GrabGPT на пʼять провайдерів.
За словами команди, сама логіка агента займає півдня, а вся обвʼязка навколо неї — секрети, логи, реєстрація сервісу — займала два тижні. Тому Grab один раз централізував цю рутину, а не будував нову абстракцію для агентів.
Що саме бере на себе LLM-Kit
Головна ідея Grab — розділити дві частини роботи над агентом. Перша — логіка розмірковування (reasoning loop): що агент має робити, як приймати рішення. Друга — все, що навколо: секрети, логування, реєстрація сервісу, оцінка якості. У пості команди Grab це сформульовано прямо: «Цикл розмірковування зайняв цілий день. Продакшн-обгортка — два тижні».
Тому LLM-Kit — не нова абстракція для агентів і не окрема мова опису. Це каркас поверх інфраструктури, яка в Grab уже була, зібраний після того, як компанія перестала розв'язувати ці задачі по одному сервісу за раз і почала розв'язувати їх один раз централізовано. Інженер заповнює форму — і отримує репозиторій із готовим FastAPI-сервісом: модулі агента на LangGraph, трейсинг через OpenTelemetry, секрети у Vault, реєстрація сервісу — усе вже підключено, плюс endpoint для оцінки якості з першого коміту.
Чому інструменти й моделі не «зашиті» в код
Інструменти агент отримує не наперед, а на льоту — під час виконання він звертається до понад 50 зареєстрованих MCP-серверів. Це означає, що можливість, зареєстровану один раз, одразу отримують усі агенти, а не тільки той, для якого її писали спочатку.
Так само з моделями. Кожен виклик моделі йде через сумісний з OpenAI шлюз GrabGPT, який покриває пʼять провайдерів і сам підставляє облікові дані. Прикладний код ніколи не «зашиває» конкретного провайдера напряму — це дає змогу міняти або додавати провайдера через реєстрацію чи конфігурацію, без передеплою сервісів.
Чому обрали фреймворк, а не платформу
Команда Grab пояснює вибір так: платформа змусила б команди підлаштовуватись під жорсткі припущення, які швидко застаріють. Фреймворк дав змогу зустріти розробників там, де вони вже працюють — тобто не ламати їхні звичні інструменти й процеси, а дати їм спільну обвʼязку.
Окремо в Grab є Palana — інструмент від команди кібербезпеки, який дозволяє командам експериментувати з автономними агентами, не втрачаючи контролю над ідентифікацією, секретами, доступом до мережі та операційною видимістю. Аналітична група на цій основі побудувала власну багатоагентну систему підтримки розробки.
Що зʼясувалось на масштабі 500+ сервісів
LLM-Kit розвʼязав задачу побудови й запуску одного агента. Але коли сервісів стало понад 500, проблеми змістились із рівня фреймворку на рівень платформи. Шлюз керує тим, яку модель викликає кожна команда, фреймворк для віддалених MCP дає змогу командам повторно використовувати чужі інструменти, а платформа оцінки показує, чи зміна промпту справді покращила агента, чи просто зробила його іншим.
Частину цього платформного шару тепер можна купити, а не будувати самим: Amazon Bedrock AgentCore і Agent Runtime від Google хостять агентів, написаних у наявному фреймворку, і додають ідентифікацію, шлюз та спостережуваність. Головний висновок для команд, які зважують такий вибір: питання не в тому, яку бібліотеку агентів обрати, а в тому, хто відповідає за секрети, трейсинг і оцінку якості — бо саме там, а не в логіці агента, ховаються два тижні роботи.