Reflexiones sobre el AWS Ambassador Summit

Introducción

Este es el segundo año que puedo asistir al AWS Ambassador Summit en Seattle gracias a Logicalis Spain.

El AWS Ambassador Summit es un evento de 3 días en el que todos los AWS Ambassador podemos ir a aprender y hacer comunidad.

En estos 3 días AWS nos cuenta muchas cosas que están bajo NDA y que no puedo contar, pero hay otras que sí.

El evento tiene diferentes tipos de charlas, desde charlas más estratégicas para Partners (recordad que esto me lo sponsoriza mi empresa), charlas sobre nuevos servicios o novedades (NDA), charlas estratégicas sobre AWS (hacia dónde vamos), mesas redondas con los Service Teams de AWS (muchas preguntas y roadmap), un workshop de agentes (basado en la FIFA World Cup 2026) y varios eventos para socializar.

Además, durante este evento podemos disfrutar del conocimiento de mucha gente importante de AWS que participa en las diferentes charlas como Rahul Pathak, Rudy Chetty, Jigar Thakkar, Laura Grit, e incluso este año tuvimos la suerte de que se pasara a saludar Swami Sivasubramanian.

Pero qué es lo más importante del evento, no son ni las charlas ni los roadmaps, ni estar en las oficinas de AWS en Seattle, ni conocer a Jeff Barr en persona (aunque esto último mola mucho).

Lo más importante es que nos juntamos más de 120 Ambassadors de 40 países diferentes y podemos compartir nuestros puntos de vista, nuestros problemas (que se parecen mucho) y cómo vemos las cosas a futuro.

Esto último puede parecer hasta contraproducente para nuestras empresas, pero realmente es todo lo contrario, porque en casi el 95% de los casos no compartimos región de negocio e incluso si lo compartimos no solemos competir directamente, además de que obviamente no nos contamos las estrategias de nuestras empresas, pero sí discutimos sobre lo que vemos.

Os puedo decir que no hay otro sitio en el que sienta un síndrome del impostor tan grande como aquí y esto no es falsa humildad, sé que soy excepcional en mi trabajo, pero es que dentro de este programa está lo mejor de lo mejor, el ser un crack es el mínimo necesario.

Agentes, Agentes y más Agentes.

No creo que os sorprenda si os digo que todo ha girado en torno a los agentes y todas las nuevas capacidades que se van a desbloquear próximamente.

Aquí hay algo que sospechaba: los roadmaps a un año se han terminado. Con toda la revolución Agentic la industria ha llegado a velocidades absurdas. Tanto que ahora mismo pensar en lo que puede venir dentro de un año ha dejado de tener sentido, podemos hacer esbozos de hacia dónde queremos ir, pero no podemos plantearnos revoluciones a un año cuando dentro de unos meses todo puede cambiar.

Pero aquí han surgido varias cosas que me gustaría comentar con más detalle.

La importancia del dato.

Es verdad que la industria se mueve muy rápido, pero a veces nos tenemos que parar a reflexionar. Por mucho que hagamos agentes muy inteligentes que estén coordinados entre sí, que tengan unos prompts increíbles con integraciones vía MCP conectadas a tus APIs, bases de datos y herramientas internas, si el dato que consumen es malo o está desactualizado, no sirven de nada y sus respuestas van a ser malas.

Por poner un ejemplo, un sistema agéntico para automatizar las operaciones, si está tirando de procedimientos desfasados o solapados o incluso a los que les faltan pasos (porque el operador los conoce), va a fallar o realizar cosas que no queremos.

Y hablando entre nosotros, es algo bastante habitual, en muchos casos nos estamos encontrando que el paso de mejorar, gobernar y basarse en datos no se ha realizado, pero queremos implantar sistemas agénticos ya.

Muchas arquitecturas son deficientes.

Cuando dos arquitectos se juntan, siempre van a salir las miserias, así que imaginaros si nos juntamos más de 100.

Por eso salió el caso de PocketSO, es verdad que es un caso muy límite y que el problema no era el agente en sí, ni siquiera que tuviese muchos permisos (aunque parte del problema era).

El problema principal es que la arquitectura de la solución no seguía las buenas prácticas mínimas, los entornos no estaban separados, los backups estaban en los mismos volúmenes y se podían modificar, etc.

Es verdad que dar permisos root a un agente, sin definir límites es un problema, pero hay muy malas arquitecturas en producción, es algo que todos sabemos, que todos sufrimos y que no es algo local, pasa en todo el mundo.

Y esto es algo que vamos a ver mucho por desgracia, de hecho en ocasiones lo vemos sin necesidad de que esté la IA involucrada.

Alguien no sabía que tenía que hacer un ritual arcano antes de una subida a producción y el entorno entero se ha caído durante horas. Suena a broma pero muchas veces hacemos cosas mal hechas simplemente porque ya las tenemos automatizadas y en nuestro contexto, cuando alguien sin ese contexto lo ejecuta, se produce una caída a producción de 20 horas (nunca me ha pasado…).

Esto es algo que en general preocupaba mucho, dar las llaves del calabozo a un agente sin ese contexto y sin solucionar estos problemas puede ser muy problemático.

El Gap entre C-Level y la capa Técnica.

Esto es algo que también ha salido mucho en nuestras conversaciones: hay una presión en los C-Level por usar sistemas agénticos que es desmesurada y en muchas ocasiones absurda.

No me malinterpretéis, probablemente muchos de nosotros llevemos usando agentes, asistentes y GenAI desde el inicio de esta revolución, pero también gracias a esto sabemos de sus limitaciones.

Sabemos cómo usar los prompts, añadir contexto a las steering files, añadir Skills, revisar por qué el prompt se está saltando una instrucción importante, saber que un contexto gigante es casi peor que uno pequeño, aprender a estructurar los contextos para facilitar su uso, etc. Si os habéis pegado con agentes sabéis de qué hablo.

El problema es que todos estamos sufriendo en muchas ocasiones que alguien con un prompt mínimo (y probablemente malo) intenta decirte cómo hacer tu trabajo, cómo montar una arquitectura, incluso retando tus decisiones sin poder defender lo que la IA le ha dicho (la frase de “me lo ha dicho Claude o ChatGPT” se usa demasiado). Esto está produciendo un gap gigante en la implantación agéntica.

En muchos casos la visión ejecutiva es muy sencilla, cuando esta implementación tiene muchas más aristas de las que creemos.

Algo que me ha pasado últimamente es que me llega una arquitectura hecha con IA para validarla porque hay que implementarla ya y resulta que no hay por donde cogerla, no se ha tenido en cuenta nada del contexto de lo que existe actualmente, si preguntas cosas por un modelo de datos o como has pensado la seguridad te miran raro.

El problema no es que use IA para explorar ideas (eso está genial), el problema es confundir un mal output de un LLM con un plan validado (OjO que un agente bien montado lo puede hacer). Y nosotros nos quedamos entre la espada y la pared: o lo rechazamos y parecemos resistentes al cambio, o lo aceptamos y firmamos una deuda técnica que vamos a pagar durante años.

Qué es un Agente.

Los agentes son el futuro, pero todo es un agente.

Esto puede parecer absurdo, pero todos estamos viendo que en muchas ocasiones se habla de agentes, cuando se está usando un automatismo de toda la vida o incluso peor, gente que está convirtiendo en agentes automatizaciones de toda la vida, haciendo llamadas a un LLM solamente para justificar que están usando agentes.

He visto cosas que no creería nadie: un “agente” que llama a un LLM para parsear un JSON que tiene un esquema fijo, otro que usa Claude para decidir si un número es mayor que otro, y mi favorito personal, uno que invoca un modelo de lenguaje para hacer un grep en un fichero de log. Eso no es un agente, eso es quemar dinero con estilo.

Los agentes son fundamentales cuando hay ambigüedad, cuando necesitas razonamiento, cuando el camino no es determinista. Ahí es donde el stack tiene sentido: un modelo en Bedrock que razona, Agent Core que le da identidad y gobernanza, Strands SDK para orquestar el loop, y MCP para conectar con el mundo exterior. Eso es un agente. Pero si tu flujo es “si A entonces B”, eso es un if de toda la vida y no necesita un LLM por detrás.

Creo que todos hemos visto a gente usar agentes y llamadas a un LLM para hacer algo que hace un script o tool que ya existe o que es sencillo de implantar. Y el problema no es solo el coste (que también), sino que estás añadiendo complejidad, indeterminación y latencia a algo que antes era simple, instantáneo y predecible.

El uso de asistentes a nivel de proyecto.

Este fue uno de los últimos temas, además de porque fue algo que vimos el último día con Laura Grit y cómo AWS había usado un approach nuevo para el Proyecto Mantle usando equipos integrados con agentes.

Esto me pareció bastante interesante, porque a día de hoy en la mayoría de proyectos se utilizan los asistentes y agentes de forma masiva, pero en muchas ocasiones sin un control.

Así que me parece interesante abrir este debate y empezar a gestionar los equipos con un enfoque agéntico, sabiendo cómo podemos mejorar y acelerar los proyectos con una calidad adecuada.

Algo interesante era que todo el equipo tiene un steering compartido y por otro lado que hay que revisar el código para conocerlo, entenderlo y poder defenderlo. Si no eres capaz de hacer estas 3 cosas, la calidad de tus proyectos se va a resentir.

Ojo, esto no significa hacerlo todo a mano, sino poder defender las cosas que vas a implantar y no utilizar el comodín de “es que esto me lo pasó mal mi agente de IA”.

Nadie va a pensar en los Juniors.

Esto es algo que me preocupa bastante. Ahora mismo no me gustaría ser alguien que está estudiando con un panorama que puede ser desolador, muchas de las tareas que hacían los perfiles Junior están siendo sustituidas por agentes y estamos perdiendo ese conocimiento.

Si no hay Juniors ahora, no vamos a tener Seniors en el futuro y parece que en muchos casos estamos olvidándonos de esto.

Antes un Junior aprendía a prueba y error, peleándose con su código, entendiendo por qué algo no funcionaba. Esos fallos eran parte del camino para convertirse en Senior. Si no permitimos que los Juniors crezcan, tenemos un problema muy grande.

No tengo una solución. Quizás el rol del Junior evolucione hacia saber dirigir agentes, validar outputs y entender qué está haciendo el agente. Pero eso no es sencillo y creo que estamos muy lejos de estar preparados, además de que estamos obviándolos de esta ecuación.

Conclusión.

Me vuelvo de Seattle con una sensación de que todo se está moviendo muy rápido, quizás demasiado y a lo mejor no todo el mundo está preparado.

Por un lado, la velocidad a la que se mueve todo es emocionante. Los agentes ya no son una promesa, son una realidad en producción que está generando valor medible. Y estar rodeado de 120 personas que viven esto en primera persona, en contextos tan diferentes como Japón, India, Noruega o Brasil, te da una perspectiva que no consigues en ningún otro sitio.

Por otro lado, hay una desconexión preocupante entre lo que la tecnología puede hacer y lo que las organizaciones están preparadas para absorber. Los datos siguen sin gobernarse, las arquitecturas siguen sin seguir buenas prácticas y el gap entre lo que pide la dirección y lo que puede ejecutar la capa técnica sigue creciendo.

Y esto no es solo nuestra impresión. Los datos de 2026 son demoledores: según MIT, el 95% de los pilotos de IA generativa no producen impacto medible en la cuenta de resultados. Forrester confirma que el 88% de los pilotos de agentes nunca llegan a producción. Y el 54% de los C-suite admiten que adoptar IA “está destrozando su empresa” (Writer.com, 2026). El patrón de fracaso no es técnico — es operacional: datos frágiles, gobernanza inexistente y cero feedback loop tras el lanzamiento.

Lo llevamos diciendo años con la migración a cloud, con el modelo de empresas basadas en datos, con los inicios de Machine Learning y parece que con los agentes vamos a repetir los mismos errores (correr antes de saber andar).

Mi takeaway principal: no importa lo inteligente que sea tu agente si le das basura como entrada. Y no importa cuántos agentes despliegues si tu arquitectura es un castillo de naipes.

La revolución agéntica no es solo un problema tecnológico. Es un problema de datos, de arquitectura, de cultura y de personas. Y eso, por mucho que avance la IA, sigue siendo responsabilidad nuestra.

Ahora toca aplicar lo aprendido. Pero no todo fue darle vueltas a la cabeza en Seattle, también hay que desconectar y recordar por qué merece la pena cruzar el charco. Os dejo con el Monte Rainier como prueba de que no todo fueron salas de reuniones.