Прототип агента собирают за день, доводят до продакшена месяцами. Разбор архитектуры AWS: что ломается на масштабе и как закрыть доступ по параметрам.
AWS разобрал архитектуру платформы Wood Mackenzie на Amazon Bedrock AgentCore: рабочий прототип агента команда собирает за один день, до продакшена доводит месяцами. Разница между этими двумя цифрами - счёт за инженерию, который компания получает, когда прототип падает на втором одновременном пользователе.
Агент-демо отвечает одному человеку в одной сессии.
Рабочий агент обслуживает множество пользователей одновременно, помнит, кто из них кто, не путает их состояние и держится в рамках, когда контекст выходит за сценарий разработчика.
Вокруг модели строится отдельный инженерный слой - сама модель тут ни при чём. ### Что именно рвётся на масштабе
Шесть вещей ломают прототип при переходе к реальным пользователям: конкурентный доступ, изоляция сессий, идентификация, персистентное состояние, горизонтальное масштабирование и guardrails, которые не дают агенту делать то, что не разрешено. AWS в разборе Wood Mackenzie прямо называет проблему: команды раз за разом строят каждый из этих слоёв заново для каждого нового агента вместо того, чтобы вынести их в общую платформу и переиспользовать.
Стандартизация экономит: слой строится один раз, а не N раз для N агентов.
Вторая часть уравнения - наблюдаемость.
Без неё на реальном трафике никто не знает, делает ли агент то, что нужно, когда пользователей стало много и сценарии разошлись с тем, что тестировал разработчик.
Отдельный разбор AWS про авторизацию MCP-инструментов на Amazon Quick называет вещь, которую бизнес обычно пропускает: каждый вызов MCP-инструмента - это событие доступа к данным, и валидного токена для него недостаточно.
Нужна проверка на уровне параметров вызова, а не только на уровне «пользователь залогинен».
Схема из разбора - цепочка проверок claims из OIDC JWT-токена, где role-based и attribute-based контроль применяется к каждому вызову инструмента отдельно. Цена ошибки конкретная: одна неверно настроенная разрешительная запись обходит требования доступа, обязательные для комплаенса, - и это всплывает при первой проверке.
Агент, который в демо отвечает на вопрос про отчёт, и агент, который безопасно обслуживает сотни сотрудников с разным уровнем доступа к одним и тем же данным, выглядят одинаково на скриншоте.
Первый готов к продакшену, второй - юридический риск с симпатичным интерфейсом.
Разница - в слоях, которые пользователь не видит: сессии, идентификация, авторизация по параметрам, масштабирование.
Бизнес платит именно за эту работу - за то, что метрика двинулась и не откатилась при нагрузке, а не за красивую демонстрацию.
Это зона, где строится LLM & Security Gateway: единая точка, через которую агенты и MCP-инструменты проходят авторизацию, вместо N реализаций одной и той же проверки в N агентах. То же с RAG-контуром: выбор векторного хранилища - Amazon OpenSearch, Aurora PostgreSQL с pgvector или S3 Vectors - определяет стоимость запроса и задержку ответа на масштабе тысяч обращений в день, и разные RAG-сценарии в проекте требуют разных хранилищ одновременно.
AI-native integration здесь - это вызов API, изолированный по сессии, авторизованный по параметрам и устойчивый, когда одновременных пользователей стало не один, а тысяча.
Агента, который не переживает второго одновременного пользователя и не проверяет права на уровне параметров вызова, справедливо считать демо, сколько бы задач он ни решал в одиночной сессии разработчика. Компании, которые платят за AI сейчас, платят за месяцы инженерной работы, которая превращает прототип за один день в результат, а не в риск.
