Mobileye автоматизувала підтримку через AI-агента

Що саме робив агент, а не просто «відповідав на тікети»

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

Агент не обмежився класифікацією звернення. Через Model Context Protocol він отримував доступ до API платформи обробки drive-data під час відповіді: міг запитати статус сесії, витягнути логи обробки й діагностичну інформацію. Тому відповідь ставала не шаблоном, а результатом короткого розслідування.

• Якщо сесія завершена, агент підтверджував стан і давав деталі доступу.
• Якщо обробка впала, агент показував конкретну помилку, давав рекомендації для налагодження й посилання на логи.
• Якщо запиту бракувало або він не був поданий правильно, агент проводив користувача через процес подання.

Як перенести принцип у робочий процес компанії

Ключовий прийом із кейсу: автоматизувати не «підтримку загалом», а один клас звернень, де людина щоразу виконує однаковий ланцюжок перевірок у кількох системах. Для Mobileye це були статусні запити по сесіях. У іншій компанії таким кандидатом може бути будь-який внутрішній процес, де відповідь залежить від даних у системах, логах або статусах, а не від експертного судження.

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

• Оберіть вузький тип тікетів, де є зрозумілий результат: статус, помилка, лог, інструкція або посилання.
• Задайте ціль для proof of concept: у Mobileye це була точність класифікації 95% і відповідь менш ніж за 2 хвилини.
• Підключіть агент не до скриньки з текстами, а до живих систем, де лежить відповідь.
• Поверніть відповідь назад у тікет із коментарями, мітками, посиланнями й наступними кроками.
• Збирайте спостережуваність: метрики сесій, затримку, використання токенів і трасування для розбору помилок.

Де прийом не спрацює або дасть слабкий ефект

У джерелі прямо видно межу: статичні скрипти, правила й дерева рішень не підійшли, бо реальні запити мали варіативність і потребували розуміння контексту. Але й агент не є універсальним рішенням. Він корисний там, де можна дати йому керований доступ до потрібних систем і де відповідь перевіряється через факти: статус, лог, діагностику, посилання, коментар у тікеті.

Якщо внутрішня система недоступна з хмари, архітектуру треба будувати як міст між середовищами. У Mobileye ticketing-система була on-premises і не була доступна з AWS, тому локальний оркестратор забирав нові тікети, передавав їх агенту в AgentCore Runtime, а потім повертав відповідь у внутрішню систему.

• Не починайте з усіх звернень одразу: джерело показує старт із одного повторюваного класу запитів.
• Не замінюйте доступ до систем здогадками моделі: агент має запитувати live production systems через MCP Server.
• Не ігноруйте безпеку й governance: у Mobileye доступ до Claude йшов через внутрішній LLM Gateway із керуванням квотами.
• Не запускайте без моніторингу: потрібні метрики, latency, token usage, traces і сигнали про code exceptions.

Що перевірити перед довірою до відповіді агента

У Mobileye proof of concept був окремим етапом перед production. Це важливо: агент спочатку мав довести, що правильно класифікує тікети й вкладається в час відповіді. Лише після цього команді знадобилась production-платформа з serverless-інфраструктурою, observability, підтримкою різних агентних фреймворків і гібридною інтеграцією з on-premises системою.

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

• Чи видно, з яких систем агент взяв статус і діагностику.
• Чи є в відповіді конкретна наступна дія, а не загальна порада.
• Чи правильно проставлені коментарі й labels у тікеті.
• Чи можна розібрати невдалу відповідь через traces і метрики сесії.
• Чи обмежений доступ агента через внутрішній gateway, ролі, автентифікацію й cost governance.

Коли перший агент став стабільним, Mobileye перетворила підхід на внутрішню платформу: команди дають код агента, вказують потрібні можливості AgentCore, а Cloud Infra готує IAM Roles, S3, CloudWatch, Cognito і файл bedrock_agentcore.yaml. Для розробника деплой зводиться до agentcore deploy, але контроль інфраструктури, безпеки й витрат лишається централізованим.