Resumen ejecutivo
Levantar un agente de IA en tu computador toma diez líneas de código. Llevarlo a producción es un problema completamente distinto — y ahí es donde aparecen los desafíos reales. Juan Irrazábal recorre la evolución del chatbot al agente autónomo, explica qué componentes hacen falta para operar agentes de verdad —runtime, identidad, memoria, pasarela de herramientas, observabilidad, evaluación y catálogo— y muestra cómo una plataforma en la nube resuelve cada uno. El mensaje que atraviesa la charla es un disclaimer que conviene tomarse en serio: es muy distinto ejecutarlo de forma local que llevarlo a un entorno productivo.
1. De chatbot a agente autónomo
La charla ordena tres generaciones que hoy se confunden en la conversación pública:
| Generación | Qué hace |
|---|---|
| Chatbot | Pregunta y respuesta, sin contexto, sin memoria, sin ejecutar acciones. Útil para contenido estático. |
| Agente | Razona y planifica, ejecuta herramientas y maneja memoria limitada. |
| Agente autónomo | Memoria persistente, autodescubrimiento de herramientas mediante protocolos estándar, pasarelas para conectarse a otros sistemas, identidad, seguridad, política y observabilidad. |
La diferencia esencial entre un modelo de lenguaje y un agente es de naturaleza, no de grado: el primero procesa y genera —responde preguntas, entrega información—; el segundo toma la iniciativa y ejecuta acciones en un ciclo continuo hasta alcanzar un resultado. De ahí que hoy la conversación ya no sea sobre un agente sino sobre múltiples agentes, orquestación y herramientas conectadas por protocolo.
Y eso cambia el paradigma de desarrollo: ya no se puede tratar como un sistema de software convencional con requerimientos cerrados — cambia incluso la forma de llevar el proyecto.
2. Los componentes que exige operar agentes
La parte más aprovechable de la charla es el inventario de qué hace falta para pasar del experimento a la operación. Cada componente resuelve un problema concreto:
- Runtime — el entorno donde el agente efectivamente corre, con inicio rápido y aislamiento de sesión.
- Identidad — gestión de identidad y credenciales del agente. La pregunta clave: ¿quién puede usarlo y cómo garantizamos que solo el personal autorizado lo haga?
- Gateway — el puente hacia el resto del mundo: convierte APIs existentes en herramientas invocables, se apoya en el protocolo MCP para el descubrimiento y conecta con funciones y servicios internos o externos.
- Memoria — con sus estrategias y su infraestructura, que es el punto que la charla desarrolla en detalle.
- Observabilidad — trazado nativo, compatible con el estándar abierto de telemetría, con tableros para ver qué está pasando.
- Evaluación — monitoreo de calidad con evaluadores que verifican si el agente cumple su objetivo y detectan alucinaciones, más el ángulo de cumplimiento.
- Registro — un catálogo centralizado de todos los agentes y herramientas desplegados, con sus estados. En una organización con varios agentes en producción, este maestro deja de ser un lujo.
- Herramientas adicionales — navegación web controlada para que el agente consulte y analice contenido, y un sandbox aislado para pruebas.
Un punto que Irrazábal subraya y que conviene retener al elegir plataforma: el enfoque es agnóstico — permite trabajar con distintos SDK de mercado, abiertos o comerciales, y conectarse a múltiples proveedores de modelos. No es un servicio suelto: es una plataforma que engloba el ciclo completo de construir, desplegar y operar.
3. Memoria: no existe «la» memoria
Una de las confusiones más caras al diseñar agentes es tratar la memoria como una sola cosa. La charla distingue tres tipos, cada uno con su tecnología y su propósito:
- Memoria de corto plazo — el contexto de la sesión actual. Se resuelve con almacenes en memoria de acceso rápido, priorizando latencia baja.
- Memoria de largo plazo — hechos históricos y preferencias del usuario, que persisten entre sesiones.
- Memoria semántica — búsqueda por significado, no por coincidencia exacta. Normalmente implica una base de datos vectorial.
Y elegir bien no es un detalle: la decisión de dónde desplegarla y con qué tecnología define la latencia percibida del agente. En la práctica, el flujo es: crear el contexto de memoria con su nombre, descripción, estrategia y región, y luego asociarlo al agente desde el código. El agente que ya existía en diez líneas gana memoria persistente con unas pocas líneas más.
4. De diez líneas a un agente funcionando
La demostración práctica es deliberadamente humilde, y ese es su valor. El punto de partida son dos comandos: instalar el kit de herramientas y generar el andamiaje del agente indicando nombre, plantilla, framework y proveedor de modelo. Con eso queda el entorno listo.
La estructura base en Python es igual de sobria: importar la librería, declarar las herramientas, definir el punto de entrada mediante un decorador, y escribir el código que instancia y ejecuta. Siete a diez líneas bastan para tener un agente respondiendo conectado a un modelo. Y para probarlo, se levanta localmente en un puerto o se invoca directamente pasándole una consulta.
El siguiente paso es conectarlo al mundo real mediante la pasarela: autenticación, enlace con otros agentes por protocolo, funciones y APIs de servicio convertidas en herramientas. El patrón se repite —crear el recurso, asociarlo al agente— y es lo que convierte un asistente aislado en algo capaz de operar sobre sistemas reales.
5. La advertencia: local no es producción
El disclaimer que Irrazábal repite es el corazón de la charla: es muy distinto ejecutar un agente de forma local que llevarlo a un entorno productivo. En local basta con que responda. En producción hay que resolver identidad y control de acceso, aislamiento de sesiones, latencia de memoria, trazabilidad de cada decisión, evaluación continua de la calidad, cumplimiento normativo y un catálogo que permita saber qué está corriendo y en qué estado.
Sobre seguridad, la charla reconoce con honestidad algo que atravesó todo el congreso: la identidad y la seguridad de los agentes se abordaron tarde en la evolución de estas plataformas, y recién ahora ocupan el lugar que les corresponde en el diseño.
6. Conclusiones
Tres ideas para llevarse. Primero, el agente es la parte fácil; la plataforma es el trabajo — diez líneas producen un agente, pero operarlo exige runtime, identidad, memoria, pasarela, observabilidad, evaluación y catálogo. Segundo, la memoria es una decisión de arquitectura, no una casilla: corto plazo, largo plazo y semántica resuelven problemas distintos y se implementan con tecnologías distintas. Tercero, y es la que más se repitió en todo el congreso: esto ya no es un tema del área de tecnología — los agentes son transversales a la industria, y los casos de uso están apareciendo en todas partes.
Para equipos latinoamericanos, la lectura práctica es que la barrera de entrada bajó de forma dramática: la infraestructura para operar agentes profesionalmente está disponible como servicio, y la distancia entre un experimento y un sistema en producción hoy se mide en decisiones de diseño más que en presupuesto.
Referencias
- Irrazábal, J. (2026). Construir agentes con tecnología AWS Cloud [charla]. I Congreso IA-LATAM. Video en el canal de Comunidad IA LATAM.
- Documentación oficial de Amazon Bedrock AgentCore — componentes de runtime, identidad, memoria, gateway, observabilidad, evaluación, registro y herramientas.
- Model Context Protocol (MCP) — estándar de descubrimiento e invocación de herramientas mencionado en la charla.
- OpenTelemetry — estándar abierto de observabilidad compatible con la plataforma descrita.
Sobre el autor
Juan Irrazábal es arquitecto de soluciones en Cencosud (Chile), con foco en arquitectura en la nube, plataformas de agentes de inteligencia artificial y despliegue de sistemas en entornos productivos de gran escala. LinkedIn
Artículo elaborado por la Comunidad IA LATAM a partir de la transcripción del video de la charla. Esta presentación no cuenta con material de diapositivas publicado, por lo que el artículo se basa exclusivamente en la exposición grabada. Los nombres de servicios y componentes corresponden a los descritos por el autor; algunos se encontraban en fase de vista previa al momento de la charla.