#retail#data#team

Единый слой знаний: как HEMA закрыла portal-hopping через MCP

Кейс HEMA на Bedrock AgentCore и MCP: почему скорость ответа агента решает интеграция с системами компании, а не выбор модели.

  • Проблема: знание есть, доступа нет
  • Подход HEMA: слой доступа, а не копия данных
  • Как это работает технически
  • Модель - заменяемая деталь, не архитектура

Кейс

AWS опубликовал разбор кейса HEMA - нидерландского ритейлера со 100-летней историей и 750 магазинами в нескольких странах. Инженеры, продакт-оунеры и бизнес-аналитики компании годами искали ответы на простые вопросы, прыгая между вики, каталогами сервисов и IT-порталами. HEMA заменила этот маршрут единым слоем знаний на Amazon Bedrock AgentCore и протоколе MCP.

Повод - кейс одного клиента, мысль в нём шире: скорость, с которой сотрудник получает рабочий ответ (TTU, time to use), определяется устройством доступа агента к источникам данных, а не тем, какую модель купила компания.

Проблема: знание есть, доступа нет

В большинстве компаний нужная информация физически существует - в базе знаний, тикет-системе, регламенте, коде. Проблема в маршруте: сотрудник должен помнить, в какой из пяти систем искать, открыть её, подобрать запрос, сопоставить результат с контекстом задачи. Каждый лишний портал - это минуты, умноженные на сотни сотрудников и тысячи вопросов в день. HEMA считала это трением, которое накапливается в масштабе 750 точек и десятков ролей.

Подход HEMA: слой доступа, а не копия данных

Команда HEMA не стала сводить всё в новую центральную базу знаний: это дало бы вторую копию данных, которую нужно синхронизировать и которой нельзя доверять по умолчанию. Вместо этого агент на Bedrock AgentCore получил доступ к существующим системам через MCP: протокол описывает, какие инструменты и ресурсы доступны агенту в каждой системе, и оставляет права доступа и данные на месте, в источнике.

Как это работает технически

MCP-сервер оборачивает каждую систему - вики, каталог сервисов, IT-портал - в набор инструментов с понятным описанием: что можно спросить, что можно получить. Агент на стороне AgentCore получает вопрос сотрудника на естественном языке, определяет, какие MCP-серверы релевантны, обращается к ним параллельно и собирает ответ со ссылками на источник. Систему для каждого запроса выбирает агент сам, за секунды - сотруднику не нужно щёлкать по вкладкам браузера.

Оценить, где ИИ даст эффект в вашем процессе

Почта clients@kt.team Telegram @kt_team_it

Модель - заменяемая деталь, не архитектура

  1. В этом же пакете AWS вышел материал о запуске AI coding agent на открытых моделях через Bedrock: компании получили возможность держать данные внутри периметра и переключать модель под задачу - от требований резидентности данных до цены за токен.

  2. Одновременно вышли GPT-6 Sol и GPT-6 Luna - пара моделей, разведённых по осям «интеллект» и «эффективность», чтобы каждую задачу можно было отдать модели по её реальной сложности, а не одной универсальной.

  3. Тренд один: модель - параметр конфигурации агентной системы.

  4. Фундамент - то, как агент подключён к данным компании.

Настоящая инженерия - в сайзинге и цене ответа

  1. Здесь же AWS показал третий кусок той же картины: concurrency sweeps для подбора конфигурации inference-эндпоинта.

  2. Без систематического теста компания либо переплачивает за простаивающие GPU, либо режет мощности и получает очередь запросов и рост латентности у пользователей. Concurrency sweep прогоняет нагрузочные тесты по комбинациям инстансов и параметров и находит точку, где цена и задержка сбалансированы.

  3. Выглядит это как одна цифра в конфиге.

  4. За цифрой - десятки нагрузочных прогонов и понимание профиля нагрузки конкретного продукта.

Что это значит для бизнеса

  1. Смена модели раз в квартал под анонс очередного релиза даёт компании право сказать, что она использует последнюю модель.

  2. Скорость ответа для сотрудников от этого не меняется.

  3. Скорость появляется там, где выстроен слой доступа агента к внутренним системам: MCP-обвязка над CRM, тикет-трекером, 1С-Битрикс или Pimcore, шлюз, который разграничивает права и логирует обращения агента к чувствительным данным, и конфигурация инференса, подобранная под реальную нагрузку.

  4. Это и есть инженерия: маршрут между вопросом сотрудника и системой, где лежит ответ.

  5. Модель - второстепенная деталь этого маршрута.

Вывод

HEMA построила слой MCP поверх своих систем и сократила путь от вопроса до ответа с блуждания по порталам до секунд. Компании, которые вкладываются в такой слой, продолжат получать результат при любой смене модели на рынке. Компании, которые ждут следующего анонса, продолжат прыгать между вкладками браузера.

Обсудить статью: Единый слой знаний: как HEMA закрыла…

Укажите email или телефон, чтобы мы могли вам ответить.

Отправить через:

Нажимая кнопку, вы принимаете оферту и предоставляете согласие на обработку персональных данных.

Похожие кейсы

Все кейсы

Статьи по теме

Подборка про интеграции

Видео по теме

Все видео
4:46 Интеграция «Честного ЗНАКа» и 1С | Автоматическая Маркировка Товара 1СИнтеграции
5:14 Интеграция через REST API | Сокращение ошибок и ускорение процессов APIИнтеграции
5:14 API-архитектура и Брокеры Сервисов | Эффективные интеграции APIИнтеграцииАрхитектура

Новости по теме

Все новости