KTern.AI рассказала, как перестроила свое ПО для трансформации SAP вокруг долго работающих AI-агентов на Amazon Bedrock AgentCore, предложив один из самых ясных на сегодня примеров того, как AWS хочет, чтобы корпоративные клиенты разворачивали производственные агентные системы, а не отдельные чат-функции.

Согласно публикации в AWS Machine Learning Blog, написанной совместно с компанией, KTern.AI использовала Amazon Bedrock AgentCore и Strands Agents SDK для запуска специализированных агентов для задач, включая реверс-инжиниринг, работы по fit-to-standard, анализ кода и поиск исключений в процессах финансов и продаж. Идея проста: вместо создания собственной инфраструктуры для оркестрации, памяти, идентичности, доступа к инструментам и наблюдаемости, KTern.AI перенесла эти функции на управляемые AWS-сервисы, чтобы собственные инженерные команды могли сосредоточиться на SAP-специфичных рабочих процессах.

Это важно, потому что проекты трансформации SAP — высокоценный тестовый кейс для агентных систем. Это долгие, насыщенные документами, чувствительные к процессам программы со строгими требованиями безопасности и большим объемом дорогостоящей работы человеческих консультантов. Если AI-агенты могут надежно работать там, облачные провайдеры получают более сильный аргумент в пользу того, что корпоративные агенты выходят за рамки демонстраций и становятся операционным ПО.

Почему KTern.AI выбрала AgentCore для SAP-рабочих процессов

По версии AWS, KTern.AI уже построила программную платформу для миграций SAP S/4HANA, конверсий и более широкой цифровой трансформации. Вопрос был не в том, может ли генеративный ИИ помочь с несколькими задачами, а в том, сможет ли компания поддерживать множество специализированных агентов в проектах, которые могут длиться месяцами или годами.

AWS и KTern.AI описывают несколько требований, которые подтолкнули компанию уйти от самостоятельно управляемого стека: постоянный контекст между повторяющимися взаимодействиями, аудируемый доступ к SAP API и системам клиентов, изоляция арендаторов, эластичное масштабирование и достаточное логирование и трассировка для отладки поведения нескольких агентов в корпоративной среде. Это типичные болевые точки для команд, пытающихся перейти от PoC-ко-пилотов к AI-агентам производственного уровня.

В опубликованной архитектуре Amazon Bedrock AgentCore Runtime используется для хостинга агентов, AgentCore memory — для сохранения контекста проекта во времени, AgentCore identity — для аутентификации и доступа с минимальными привилегиями, а AgentCore observability — для передачи логов, метрик и трасс в Amazon CloudWatch. Для доступа к внешним системам агенты вызывают инструменты через слой Model Context Protocol шлюза AgentCore. AWS говорит, что трафик к Amazon Bedrock и AgentCore может оставаться вне публичного интернета с помощью AWS PrivateLink и VPC interface endpoints.

Реализация KTern.AI также, по данным поста AWS, опирается на конфигурацию, а не на собственный код оркестрации. Каждый агент определяется промптами, привязками инструментов и паттернами оркестрации, при этом компания использует шаблоны Strands Agents SDK, такие как swarm, workflow и graph, в зависимости от рабочей нагрузки. Это важная архитектурная деталь: AWS здесь продает не только модели, но и управляемую среду выполнения и операционный слой для агентных систем.

AWS строит более широкую историю AgentCore

Случай KTern.AI не возникает в изоляции. Другие недавние публикации AWS Machine Learning Blog указывают на более широкую работу по позиционированию Amazon Bedrock AgentCore как производственной контрольной плоскости для корпоративных агентов.

Один пост описывает, как построить семантический слой для agentic analytics с Stardog и Amazon Bedrock AgentCore. В этом примере AWS утверждает, что главная проблема корпоративных агентов — не просто генерировать SQL или вызывать модель, а последовательно рассуждать над фрагментированными бизнес-данными. Предлагаемое решение — слой смысла, построенный с Stardog поверх источников вроде Amazon Aurora и Amazon Redshift, чтобы агенты могли запрашивать управляемые бизнес-концепции, а не сырые системы напрямую.

Это важно для истории KTern.AI, потому что работа по трансформации SAP имеет ту же структурную проблему. Долго работающим агентам нужен устойчивый контекст, безопасный доступ к системам и некое общее бизнес-понимание процессов, кода и исключений. Посыл AWS в обоих постах одинаков: моделей самих по себе недостаточно; производственным агентам нужна инфраструктура для памяти, инструментов, идентичности, управления и доступа к данным.

Отдельная публикация AWS о защите Amazon Bedrock AgentCore Runtime с помощью AWS WAF добавляет еще одну подсказку о том, где AWS видит барьеры внедрения. В ней речь идет о размещении интернет-доступного Application Load Balancer перед эндпоинтами AgentCore, приватной маршрутизации трафика через VPC endpoint и обработке осложнений health-check, вызванных встроенной аутентификацией SigV4 и OAuth в AgentCore. Сам факт, что AWS публикует подробные шаблоны интеграции AWS WAF, Amazon Cognito и ALB, говорит о том, что компания пытается снять корпоративные опасения по безопасности, которые часто мешают развертыванию после успешного пилота.

Что KTern.AI, по ее словам, достигла

Самые сильные числовые результаты в этом наборе происходят из поста KTern.AI в блоге AWS, и их следует читать как производственные метрики, предоставленные вендором, а не как независимо проверенные бенчмарки.

По словам KTern.AI, ее агенты сократили общие сроки SAP-проектов на 45%, уменьшили объем discovery и assessment на 60–70%, автономно выявили 90% операционных исключений в финансах и продажах и сэкономили 480 инженерных часов в месяц в производственных проектах. Пост также утверждает, что первый производственный агент можно было развернуть за 4–6 часов без какого-либо собственного кода оркестрации, тогда как ранее в самоуправляемой схеме на одного агента уходило 2–3 недели. AWS и KTern.AI также сообщают о снижении времени настройки инфраструктуры на 95% и о 99,8% устойчивого времени работы агентов в производственных развертываниях.

Эти цифры могут быть значимыми для покупателей, оценивающих AI-агентов в корпоративной трансформации, но предоставленные доказательства ограничены. В посте не раскрываются число клиентов, методология, определения базовой линии, состав проектов или то, были ли измерения получены из небольшой выборки или широкой установленной базы. Он также не разделяет выигрыш, полученный за счет самих агентных рабочих процессов, и выигрыш, полученный от перехода на управляемую AWS-инфраструктуру.

Тем не менее, даже с этими оговорками, такие заявления подчеркивают бизнес-кейс, который AWS хочет, чтобы клиенты рассмотрели. Если время поставки агента падает с недель до часов, ценностное предложение смещается от отдельных проектов автоматизации к переиспользуемым внутренним портфелям агентов.

Доказательства, архитектура и где утверждения слабы

Публикации здесь почти полностью основаны на контролируемых AWS источниках, включая несколько постов AWS Machine Learning Blog и материал AWS Wire. Это означает, что детали архитектуры продукта полезны, но операционные результаты статьи следует воспринимать осторожно.

Лучше всего источниками подтверждается техническая форма системы: KTern.AI использовала Amazon Bedrock AgentCore, Strands Agents SDK, Amazon CloudWatch, AWS Lambda, Amazon S3, IAM и приватную сеть через AWS PrivateLink. AWS также четко описывает связанные паттерны развертывания для AWS WAF, ALB и Amazon Cognito, когда командам нужны средства web application firewall перед AgentCore Runtime.

Менее убедительно подтверждена история производительности. Цифры по скорости, трудозатратам, uptime и обнаружению исключений AWS приписывает внутренним измерениям KTern.AI. В исходных материалах нет ни стороннего аудита, ни отзыва клиента, ни методологии бенчмарка. Та же осторожность относится и к более широкому заявлению компании о 7-кратном ускорении трансформаций и снижении общих усилий на 24% благодаря ее платформе.

Для читателей, оценивающих Amazon Bedrock AgentCore, ключевой вывод не в том, что эти точные проценты можно обобщать, а в том, что AWS теперь имеет как минимум одну публичную корпоративную референс-архитектуру, показывающую, как многoагентные приложения можно встраивать в чувствительные операционные системы с постоянным контекстом и контролируемым доступом к инструментам.

Что это значит для разработчиков и корпоративных покупателей

Для AI-разработчиков пример KTern.AI подтверждает паттерн, который становится все яснее в корпоративном ИИ: многие сложные проблемы носят операционный, а не чисто модельный характер. Сохранение сессии, изоляция арендаторов, аутентификация инструментов, трассировка и управляемое подключение к системам-источникам часто определяют, выживут ли AI-агенты за пределами лабораторной демоверсии.

Для продуктовых команд примечателен подход с высокой долей конфигурации, описанный со Strands Agents SDK. Если новые агенты действительно могут определяться промптами, привязками инструментов и паттернами оркестрации, а не новыми инфраструктурными стеками, команды смогут выпускать специализированных по доменам агентов быстрее и с меньшими затратами на платформенную инженерию. Это особенно важно в отраслях с повторяемыми, но насыщенными контекстом рабочими процессами, включая модернизацию ERP, операции по комплаенсу и корпоративную аналитику.

Для корпоративных покупателей картина смешанная. С одной стороны, Amazon Bedrock AgentCore все больше выглядит как ответ AWS на распространенный вопрос закупки: кто отвечает за скучные, но необходимые runtime-компоненты для production AI-агентов? С другой стороны, покупателям по-прежнему нужно проверять, перевешивает ли управляемое удобство lock-in, достаточно ли контролей AWS для их модели безопасности и надежно ли поведение агентов в реальных условиях программы, а не в отобранных примерах.

Сопутствующий контент AWS также указывает, что развертывание агентов на AWS часто будет вовлекать соседние сервисы, такие как Amazon Aurora, Amazon Redshift, Stardog и сам Amazon Bedrock. На практике покупка агентной среды выполнения может означать подключение к более широкой облачной архитектуре для памяти, управления, сетевой безопасности и посредничества данных.

За чем следить дальше

Следующий сигнал, за которым стоит наблюдать, — будет ли AWS публиковать больше сторонних примеров клиентов для Amazon Bedrock AgentCore вне блог-постов, написанных самим вендором. Независимые кейсы с раскрытыми базовыми значениями усилили бы аргумент о том, что платформа набирает реальную производственную динамику.

Второй сигнал — продолжит ли AWS расширять сопутствующие корпоративные механизмы контроля. Недавние рекомендации по AWS WAF показывают, что безопасность на входе и инспекция трафика — реальные вопросы клиентов. Больше готовых шаблонов для аудируемости, применения политик и многoарендных операций сделают Amazon Bedrock AgentCore более убедительным для регулируемых нагрузок.

В-третьих, стоит наблюдать, как AWS связывает AgentCore с корпоративными системами данных. Пример Stardog показывает один путь через семантический слой поверх Amazon Aurora и Amazon Redshift. Если этот паттерн распространится, агентные платформы будут оцениваться не столько по выбору модели, сколько по тому, насколько безопасно они связывают бизнес-смысл с живыми системами.

Наконец, стоит следить, предоставят ли KTern.AI или AWS более полные доказательства со стороны клиентов. Названные внедрения, более ясные методы и сигналы удержания или расширения сказали бы рынку больше о том, создает ли эта архитектура устойчивую ценность в SAP-трансформации.

Взгляд Creati.ai

Кейс KTern.AI при поддержке AWS полезен не тем, что доказывает, будто agentic AI уже решил корпоративную трансформацию, а тем, что показывает, куда смещается реальная платформа-битва. Дифференциатор уже не только доступ к модели. Это управляемый слой, который делает AI-агентов работоспособными внутри сложных, долгих бизнес-программ.

Для основателей и продуктовых лидеров урок практический: если ваш продукт зависит от того, что AI-агенты взаимодействуют с production-системами, ваша архитектура для памяти, идентичности, доступа к инструментам, observability и сетевого контроля будет важна не меньше, чем дизайн промптов. Amazon Bedrock AgentCore — это попытка AWS занять этот слой. Согласятся ли клиенты на компромиссы, будет зависеть от доказательства того, что он снижает трение при развертывании, не создавая при этом новый класс проблем runtime и governance.