La respuesta corta.
AWS define un agente de IA como un programa de software que interactúa con el ambiente, recoge datos y usa esos datos para ejecutar tareas autodirigidas hacia un objetivo predeterminado. La palabra que hace la diferencia es autodirigidas: el agente elige el próximo paso, y por eso llevar uno a producción es un problema de operación, no de modelo.
Un chat se equivoca y alguien lee una respuesta equivocada. Un agente se equivoca y alguien recibe un cobro equivocado, un ticket cerrado sin solución o un correo que no debía haber salido. Es la misma tecnología con otra consecuencia, y la consecuencia es lo que necesita diseño.
Las cuatro piezas de un agente.
Tal como lo describe AWS. Cualquier producto que se llame agente tiene esas cuatro piezas, con nombres comerciales distintos.
Modelo fundacional
El razonamiento. Es el modelo de lenguaje que interpreta el pedido y decide el próximo paso.
Memoria
Retiene información entre interacciones, sesiones o tareas. Es lo que hace que el agente recuerde lo que ya intentó.
Herramientas
La conexión con software, APIs y dispositivos externos. Es por aquí que el agente sale del texto y mueve el mundo.
Planificación
Divide el objetivo en pasos más chicos y los pone en secuencia lógica.
El ciclo que describe AWS tiene tres momentos: definir el objetivo y dividirlo en tareas, buscar la información necesaria para ejecutarlas, y ejecutar evaluando el progreso en cada paso. Es ese último punto, evaluar su propio progreso, lo que hace que un agente sea difícil de probar como se prueba el software común.
Qué separa la demostración de la producción.
Cinco capas. Ninguna aparece en una demostración, y todas aparecen en el primer mes de operación.
Una frontera de aprobación escrita
Qué acciones salen solas y cuáles esperan a una persona. Eso es una decisión de negocio, no de ingeniería, y tiene que estar en un documento que alguien firma, no en un comentario dentro del código.
El cálculo fuera del modelo
El score, el valor, la comisión y el plazo los calcula código probado. El agente escribe el texto alrededor del número; nunca produce el número. Los dos caminos se comparan antes de ir a producción.
Rastro de cada paso
Qué herramienta llamó el agente, con qué argumento, con qué resultado. Sin ese rastro, investigar un error se vuelve arqueología y la respuesta tarda días en lugar de minutos.
Costo por ejecución
Un agente que reintenta hasta lograrlo puede costar diez veces lo previsto en un día malo. Medir el costo por ejecución y tener un techo por tarea es control de operación, no un detalle técnico.
El procedimiento para cuando se equivoca
A quién se avisa, en cuánto tiempo, cómo se apaga el agente sin tumbar el resto, y cómo se deshace lo que hizo. Un piloto que se equivoca se vuelve chiste interno; un sistema en producción que se equivoca necesita a alguien con nombre y un botón.
Cuatro preguntas antes de sacar el tuyo del piloto.
Si no puedes responder las cuatro por escrito, el agente todavía no está listo, y el problema no va a aparecer en la demostración.
¿Cuál es la acción más cara que puede tomar solo hoy?
¿De dónde viene cada número que muestra, y se puede verificar en un clic?
¿Cuánto cuesta una ejecución, y cuál es el techo diario?
¿A quién se avisa cuando se equivoca, y en cuánto tiempo se puede apagar?
Preguntas sobre agentes de IA.
¿Qué es un agente de IA?
AWS define un agente de IA como un programa de software capaz de interactuar con el ambiente, recoger datos y usar esos datos para ejecutar tareas autodirigidas que cumplen objetivos predeterminados. La diferencia con un chat es esa: el agente decide el próximo paso y actúa, en vez de solo responder.
¿Qué tiene un agente por dentro?
Cuatro piezas, en la descripción de AWS: un modelo fundacional, que hace el razonamiento; un módulo de memoria, que retiene información entre interacciones, sesiones o tareas; integración con herramientas, que conecta al agente con software, APIs y dispositivos externos; y un módulo de planificación, que divide el objetivo en pasos más chicos y los ordena.
¿Cuál es la diferencia entre un agente y RAG?
RAG recupera información para que el modelo responda mejor. El agente usa herramientas para hacer que algo pase: abrir un ticket, actualizar un registro, disparar un cobro. Casi todo agente útil tiene RAG adentro; lo inverso no es cierto.
¿Un agente puede actuar solo en mi operación?
Puede, y la pregunta correcta es dónde. La regla que aplicamos es simple: donde equivocarse sale caro, una persona aprueba antes de que la acción salga. Lo que es reversible y barato, el agente lo ejecuta directo. Esa frontera es decisión del cliente, queda escrita, y es lo primero que definimos antes de construir.
¿Cuáles son los riesgos que nombra AWS?
Cuatro: privacidad de los datos, porque los agentes manejan grandes volúmenes de información; resultados sesgados o imprecisos venidos del modelo; complejidad técnica, que exige experiencia específica en aprendizaje automático; y consumo de recursos computacionales.
¿Por qué el piloto de un agente no llega a producción?
Porque la demostración la evalúa una persona que quiere verlo funcionar, y la producción la evalúan diez que necesitan confiar. Lo que falta casi siempre es lo mismo: nadie definió quién aprueba qué, de dónde viene cada número, cuánto cuesta una ejecución, y qué pasa el día en que el agente se equivoca.
¿Tienes un agente detenido en piloto?
El diagnóstico responde las cuatro preguntas de arriba con evidencia de tu caso, y dice qué falta para que entre en producción con dueño. Dos semanas, un documento, una cotización cerrada.
Fuentes
Las definiciones, las cuatro piezas, el ciclo de ejecución y los riesgos citados vienen de las páginas de AWS, abiertas el 9 de agosto de 2026. Las cinco capas de producción y las cuatro preguntas son práctica de implantación de Moonxi, y están escritas como práctica.