KTern.AI ha explicado cómo reconstruyó su software de transformación SAP en torno a agentes de IA de larga duración sobre Amazon Bedrock AgentCore, ofreciendo uno de los casos de estudio de proveedor más claros hasta la fecha sobre cómo AWS quiere que los clientes empresariales desplieguen sistemas de agentes en producción en lugar de funciones de chat aisladas.

Según una publicación del blog de Machine Learning de AWS coescrita con la empresa, KTern.AI utilizó Amazon Bedrock AgentCore y el SDK Strands Agents para ejecutar agentes especializados en tareas como ingeniería inversa, trabajo fit-to-standard, análisis de código y minería de excepciones en procesos de finanzas y ventas. La propuesta es sencilla: en lugar de construir infraestructura personalizada para la orquestación, la memoria, la identidad, el acceso a herramientas y la observabilidad, KTern.AI afirma que trasladó esas funciones a servicios administrados por AWS para que sus propios equipos de ingeniería pudieran centrarse en flujos de trabajo específicos de SAP.

Eso importa porque los proyectos de transformación SAP son un caso de prueba de alto valor para los sistemas agentivos. Son programas de larga duración, cargados de documentos, sensibles a los procesos, con estrictos requisitos de seguridad y mucho trabajo de consultoría humana costosa. Si los agentes de IA pueden operar de forma fiable allí, los proveedores de nube ganan un argumento más sólido de que los agentes empresariales están pasando de las demos al software operativo.

Por qué KTern.AI eligió AgentCore para los flujos de trabajo de SAP

En la versión de AWS, KTern.AI ya había construido una plataforma de software para migraciones de SAP S/4HANA, conversiones y un trabajo más amplio de transformación digital. El problema no era si la IA generativa podía ayudar con unas pocas tareas, sino si la empresa podía dar soporte a muchos agentes especializados en proyectos que pueden durar meses o años.

AWS y KTern.AI describen varios requisitos que empujaron a la empresa a abandonar una pila autogestionada: contexto persistente a lo largo de interacciones repetidas, acceso auditable a las API de SAP y a los sistemas del cliente, aislamiento de inquilinos, escalado elástico y suficiente registro y trazado para depurar el comportamiento multiagente en entornos empresariales. Son puntos de dolor habituales para los equipos que intentan pasar de copilotos de prueba de concepto a agentes de IA de nivel de producción.

La arquitectura publicada utiliza Amazon Bedrock AgentCore Runtime para alojar los agentes, AgentCore memory para conservar el contexto del proyecto con el tiempo, AgentCore identity para la autenticación y el acceso con privilegio mínimo, y AgentCore observability para enviar registros, métricas y trazas a Amazon CloudWatch. Para el acceso a sistemas externos, los agentes llaman a herramientas a través de la capa Model Context Protocol del gateway de AgentCore. AWS afirma que el tráfico hacia Amazon Bedrock y AgentCore puede mantenerse fuera de Internet pública mediante AWS PrivateLink y endpoints de interfaz de VPC.

La implementación de KTern.AI también depende de la configuración en lugar de código de orquestación personalizado, según la publicación de AWS. Cada agente se define mediante prompts, enlaces de herramientas y patrones de orquestación, y la empresa utiliza patrones del SDK Strands Agents como swarm, workflow y graph según la carga de trabajo. Ese es un detalle arquitectónico importante: AWS no solo está proponiendo modelos aquí, sino una capa de ejecución y operación administrada para sistemas de agentes.

AWS está construyendo una historia más amplia de AgentCore

El caso de KTern.AI no aparece de forma aislada. Otras publicaciones recientes del blog de Machine Learning de AWS apuntan a un esfuerzo más amplio por posicionar Amazon Bedrock AgentCore como el plano de control de producción para agentes empresariales.

Una publicación describe cómo construir una capa semántica para analítica agentiva con Stardog y Amazon Bedrock AgentCore. En ese ejemplo, AWS sostiene que el desafío central para los agentes empresariales no es simplemente generar SQL o llamar a un modelo, sino razonar de forma consistente sobre datos de negocio fragmentados. La respuesta propuesta es una capa de significado construida con Stardog sobre fuentes como Amazon Aurora y Amazon Redshift, para que los agentes puedan consultar conceptos de negocio gobernados en lugar de sistemas en bruto directamente.

Eso importa para la historia de KTern.AI porque el trabajo de transformación SAP tiene el mismo problema estructural. Los agentes de larga duración necesitan contexto duradero, acceso seguro a los sistemas y algún entendimiento empresarial compartido de procesos, código y excepciones. El mensaje de AWS en ambas publicaciones es coherente: los modelos no bastan por sí solos; los agentes de producción necesitan infraestructura para memoria, herramientas, identidad, gobernanza y acceso a datos.

Una publicación aparte de AWS sobre la protección de Amazon Bedrock AgentCore Runtime con AWS WAF añade otra pista sobre dónde ve AWS las barreras de adopción. Se centra en colocar un Application Load Balancer expuesto a Internet frente a los endpoints de AgentCore, enrutar el tráfico de forma privada a través de un endpoint de VPC y gestionar las complicaciones de comprobación de salud creadas por la autenticación SigV4 y OAuth integradas de AgentCore. El hecho de que AWS publique patrones detallados para la integración de AWS WAF, Amazon Cognito y ALB sugiere que está tratando de eliminar objeciones de seguridad empresarial que a menudo bloquean el despliegue después de un piloto exitoso.

Qué afirma haber logrado KTern.AI

Los resultados numéricos más fuertes del conjunto proceden de la publicación de KTern.AI en el blog de AWS, y deben leerse como mediciones de producción informadas por el proveedor, no como benchmarks verificados de forma independiente.

Según KTern.AI, sus agentes redujeron los plazos generales de los proyectos SAP en un 45 por ciento, recortaron el trabajo de descubrimiento y evaluación entre un 60 y un 70 por ciento, detectaron de forma autónoma el 90 por ciento de las excepciones operativas de finanzas y ventas, y recuperaron 480 horas de ingeniería al mes en engagements de producción. La publicación también dice que el primer agente en producción pudo desplegarse en 4 a 6 horas con cero código de orquestación personalizado, frente a las anteriores 2 a 3 semanas por agente en una configuración autogestionada. AWS y KTern.AI informan además de una reducción del 95 por ciento en el tiempo de configuración de la infraestructura y de un 99,8 por ciento de tiempo de actividad sostenido de los agentes en los despliegues de producción.

Esas cifras pueden ser significativas en términos de dirección para los compradores que evalúan agentes de IA en el trabajo de transformación empresarial, pero la evidencia proporcionada es limitada. La publicación no revela el número de clientes, la metodología, las definiciones de referencia, la mezcla de proyectos ni si las mediciones proceden de un pequeño conjunto de engagements o de una base instalada amplia. Tampoco separa las mejoras causadas por los propios flujos de trabajo de los agentes de las mejoras causadas por pasar a una infraestructura administrada por AWS.

Aun así, incluso con esas salvedades, las afirmaciones destacan el caso de negocio que AWS quiere que los clientes consideren. Si el tiempo de entrega de agentes cae de semanas a horas, la propuesta de valor pasa de proyectos de automatización aislados a carteras internas de agentes reutilizables.

Evidencia, arquitectura y dónde son más débiles las afirmaciones

Los informes aquí se basan casi por completo en fuentes controladas por AWS, incluidas varias publicaciones del blog de Machine Learning de AWS y una nota de AWS Wire. Eso significa que los detalles de la arquitectura del producto son útiles, pero los resultados operativos del artículo deben tratarse con cautela.

Lo que parece bien respaldado por las fuentes es la forma técnica del sistema: KTern.AI utilizó Amazon Bedrock AgentCore, el SDK Strands Agents, Amazon CloudWatch, AWS Lambda, Amazon S3, IAM y redes privadas a través de AWS PrivateLink. AWS también describe claramente los patrones de despliegue relacionados para AWS WAF, ALB y Amazon Cognito cuando los equipos quieren controles de firewall de aplicaciones web delante de AgentCore Runtime.

Lo que está menos respaldado es la historia de rendimiento. Los números de velocidad, esfuerzo, disponibilidad y detección de excepciones se atribuyen por AWS a las mediciones internas de KTern.AI. No hay una auditoría de terceros, ni un testimonio de cliente, ni una metodología de benchmark en el material de origen. La misma cautela se aplica a la afirmación más amplia de la empresa de ofrecer transformaciones 7 veces más rápidas y una reducción del 24 por ciento en el esfuerzo total a través de su plataforma.

Para los lectores que evalúan Amazon Bedrock AgentCore, la conclusión clave no es que estos porcentajes exactos sean generalizables, sino que AWS ya cuenta con al menos una arquitectura de referencia empresarial pública que muestra cómo las aplicaciones multiagente pueden integrarse en sistemas operativos sensibles con contexto persistente y acceso controlado a herramientas.

Qué significa esto para desarrolladores y compradores empresariales

Para los desarrolladores de IA, el ejemplo de KTern.AI refuerza un patrón que se está volviendo más claro en la IA empresarial: muchos de los problemas difíciles son operativos, no puramente relacionados con el modelo. La persistencia de sesión, el aislamiento de inquilinos, la autenticación de herramientas, el trazado y la conectividad gobernada con los sistemas de registro suelen determinar si los agentes de IA sobreviven más allá de una demo de laboratorio.

Para los equipos de producto, destaca el enfoque centrado en la configuración descrito con Strands Agents SDK. Si los nuevos agentes pueden definirse realmente mediante prompts, enlaces de herramientas y patrones de orquestación en lugar de nuevas pilas de infraestructura, los equipos podrían enviar agentes específicos de dominio más rápido y con menos sobrecarga de ingeniería de plataforma. Eso es especialmente relevante en sectores con flujos de trabajo repetibles pero de alto contexto, incluida la modernización de ERP, las operaciones de cumplimiento y la analítica empresarial.

Para los compradores empresariales, la historia es más ambigua. Por un lado, Amazon Bedrock AgentCore parece cada vez más la respuesta de AWS a una pregunta común de adquisición: ¿quién se encarga de las piezas de ejecución aburridas pero esenciales para los agentes de IA en producción? Por otro lado, los compradores todavía deben comprobar si la comodidad administrada compensa el bloqueo, si los controles de AWS son suficientes para su postura de seguridad y si el comportamiento de los agentes es fiable en condiciones reales de programa y no solo en ejemplos seleccionados.

El contenido de AWS que rodea el caso también sugiere que el despliegue de agentes en AWS a menudo incorporará servicios adyacentes como Amazon Aurora, Amazon Redshift, Stardog y el propio Amazon Bedrock. En la práctica, comprar un tiempo de ejecución de agentes puede significar apostar por una arquitectura cloud más amplia para la memoria, la gobernanza, la seguridad de red y la mediación de datos.

Qué vigilar a continuación

La próxima señal a vigilar es si AWS publica más ejemplos de clientes de terceros para Amazon Bedrock AgentCore fuera de las publicaciones del blog escritas por proveedores. Los casos de estudio independientes con referencias de base reveladas fortalecerían el argumento de que la plataforma está ganando tracción real en producción.

Una segunda señal es si AWS sigue ampliando los controles empresariales circundantes. La reciente guía de AWS WAF implica que la seguridad en el punto de entrada y la inspección del tráfico son preocupaciones activas de los clientes. Más patrones empaquetados para auditabilidad, aplicación de políticas y operaciones multiinquilino harían que Amazon Bedrock AgentCore resultara más creíble para cargas de trabajo reguladas.

En tercer lugar, conviene observar cómo AWS conecta AgentCore con los sistemas de datos empresariales. El ejemplo de Stardog muestra una ruta a través de una capa semántica sobre Amazon Aurora y Amazon Redshift. Si ese patrón se extiende, las plataformas de agentes podrían juzgarse menos por la elección del modelo y más por lo seguro que conectan el significado empresarial con sistemas en vivo.

Por último, vale la pena seguir si KTern.AI o AWS ofrecen pruebas de clientes más completas. Despliegues con nombre, métodos más claros y señales de retención o expansión dirían más al mercado sobre si esta arquitectura está produciendo valor duradero en el trabajo de transformación SAP.

Perspectiva de Creati.ai

El caso de estudio de KTern.AI respaldado por AWS es útil no porque demuestre que la IA agentiva ha resuelto la transformación empresarial, sino porque muestra hacia dónde se está moviendo la verdadera batalla de plataformas. El diferenciador ya no es solo el acceso al modelo. Es la capa administrada que hace que los agentes de IA sean operables dentro de programas empresariales complejos y de larga duración.

Para fundadores y líderes de producto, la lección es práctica: si su producto depende de que los agentes de IA interactúen con sistemas de producción, entonces su arquitectura para memoria, identidad, acceso a herramientas, observabilidad y control de red importará tanto como el diseño de prompts. Amazon Bedrock AgentCore es la apuesta de AWS por dominar esa capa. Si los clientes aceptan las compensaciones dependerá de la prueba de que reduce la fricción de despliegue sin crear una nueva clase de dolores de cabeza de ejecución y gobernanza.