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