Por qué los agentes de IA en producción necesitan más que un buen prompt
Los agentes de IA de producción necesitan algo más que un buen prompt: contexto, herramientas, memoria, manejo de fallos, capacidad de observación, pruebas y autonomía acordes al riesgo real.
Fuentes: AI Agents Are Easy to Demo. Production Is the Hard Part.
En una demostración, un agente de IA parece casi demasiado sencillo. Se le da a un LLM un objetivo, se conectan algunas herramientas, se añade algo de memoria y todo se envuelve en un bucle. De repente, el agente razona, llama a APIs, busca documentos y completa tareas, y la primera versión parece algo mágica. Es en la producción donde comienza el verdadero trabajo de ingeniería.
Si se invierte suficiente tiempo en los sistemas de agentes, el problema central cambia. Hacer que el modelo sea lo suficientemente inteligente deja de ser la parte difícil. La pregunta más complicada es cómo envolver un componente astuto pero no determinista en un sistema cuyo comportamiento general siga siendo predecible. Casi todas las decisiones arquitectónicas surgen de eso.
Más que un LLM con herramientas
La forma abreviada habitual dice que un agente es un LLM más herramientas más memoria. Eso sirve para explicar la idea, pero es insuficiente en entornos de producción, donde aplica una fórmula más completa: razonamiento, contexto, herramientas, estado, flujo de trabajo, límites, observabilidad y recuperación. El LLM es importante, pero solo es un componente.
Tomemos como ejemplo un agente de análisis de documentos. Un usuario sube un archivo y solicita su análisis. Detrás de esa única solicitud, el sistema puede tener que:
- Verificar que la solicitud sea válida.
- Extraer información del documento.
- Obtener el contexto relevante.
- Elaborar el prompt adecuado.
- Hacer que el modelo razoné sobre las pruebas.
- Verificar lo que devolvió el modelo.
- Ejecutar herramientas adicionales.
- Calcular resultados que deben ser exactos.
- Guardar el resultado final.
- Informar sobre el progreso a la interfaz.
- Volver a intentar cualquier tarea que haya fallado.
En ese punto, el trabajo ya no se trata de diseño rápido. Se trata del diseño de un sistema distribuido que casualmente contiene un LLM. Una división clara de responsabilidades ayuda.
Entrada y contexto
El contexto abarca todo lo que el agente sabe sobre la tarea en cuestión: instrucciones del usuario, documentos, registros de base de datos, estado del flujo de trabajo de pasos anteriores, conocimiento recuperado y metadatos de la aplicación. La lección principal es que, por defecto, añadir más contexto no ayuda. Proporcionarle al modelo todo genera ruido, aumenta los costos y hace más difícil predecir su razonamiento. Busque el contexto más reducido que aún permita tomar una decisión.
La capa de razonamiento
Aquí es donde el LLM gana su sustento. Puede interpretar información ambigua, leer documentos, comparar pruebas, elegir una herramienta, redactar explicaciones, clasificar cosas y planificar el siguiente paso. Hay una regla que merece énfasis: no le encomiende al modelo ninguna decisión que el código ordinario pueda tomar de manera fiable.
Supongamos que una regla empresarial dice varianza <= 5% → APROBADO. Nadie necesita un LLM para decidir si el 3,8% es menor al 5%. Basta con calcularlo. Utilice el modelo cuando sea necesario razonar y código cuando sea posible lograr determinismo. Esa separación hace que los sistemas de agentes sean mucho más fáciles de probar.
Las herramientas hacen que los agentes sean útiles
Un LLM sin herramientas se limita a describir acciones. Al contar con herramientas, puede llevarlas a cabo. Las herramientas típicas son la búsqueda, las bases de datos, las APIs, la recuperación de documentos, la ejecución de código, los servicios internos y los sistemas de flujo de trabajo. El proceso habitual comienza con la solicitud del usuario, que llega al agente, el cual selecciona una herramienta, la ejecuta, observa los resultados y continúa.
Ese es el núcleo del patrón ReAct: razonar, actuar, observar y luego volver a razonar. Es poderoso porque el agente no necesita tener todos los datos desde el principio y puede buscar lo que necesita durante la tarea.
Cada herramienta también representa otro punto de fallo. Una API puede agotar su tiempo de espera, las credenciales pueden vencerse, una base de datos puede dejar de funcionar, una herramienta puede devolver datos mal formados y el modelo puede recibir argumentos incorrectos. Llamar a una herramienta nunca debería significar enviar la solicitud del LLM a una API y esperar lo mejor. La ejecución en entornos de producción requiere validación, tiempos de espera, intentos repetidos, manejo de errores, permisos y estados de fallo bien definidos.
La memoria no es un ejercicio de acumulación
La memoria es una de las partes más malentendidas en el diseño de agentes. La intuición sugiere que un agente que recuerda más se vuelve más inteligente. A menudo no es así. Si se almacenan todas las interacciones para siempre e se incluyen en solicitudes posteriores, el agente recibe ruido en lugar de memoria útil.
Es útil pensar en capas:
- Memoria de trabajo almacena lo que necesita la tarea actual, como el estado del flujo de trabajo, los resultados recientes de las herramientas y los cálculos intermedios.
- Memoria a largo plazo guarda lo que es útil en diferentes tareas, como preferencias, hechos confirmados anteriormente y resultados históricos.
- Conocimiento externo son datos que ya se encuentran en otro lugar y solo se obtienen cuando se solicitan, como documentos, políticas, registros de bases de datos y resultados de búsquedas vectoriales.
La pregunta que hay que plantearse no es cuánto puede recordar el agente, sino qué necesita saber en este momento. Ese pequeño cambio puede simplificar notablemente una arquitectura.
Tenga cuidado con muchos agentes
Los diseños multiagente son fascinantes. Un coordinador puede dividirse en un agente para documentos, uno de investigación, uno de validación y uno de informes, cada uno encargado de una parte específica del problema. Aunque el diagrama resulte atractivo, no debería ser el punto de partida por defecto.
Cada agente adicional introduce otra instrucción, otra transición de estado, otro modo de fallo, otro límite de comunicación, más latencia y algo más que depurar. A menudo, un agente con tres herramientas adecuadas es mejor que cuatro agentes que se comunican entre sí.
Una regla práctica es comenzar con el diseño más simple que resuelva el problema y añadir un agente solo cuando sea posible establecer claramente su necesidad de razonamiento o responsabilidad independiente. El diseño multiagente debe resolver un problema arquitectónico y no solo buscar que el esquema se vea impresionante.
Planificación para fallos
Imagínese un flujo de trabajo que sube un documento, extrae su contenido, obtiene el contexto, lo analiza, llama a una herramienta y genera un informe. Ahora, el agente se cae justo después del análisis. ¿Se reinicia todo? ¿Algo ya fue escrito en la base de datos? ¿Es seguro ejecutar la operación dos veces? ¿La interfaz sigue mostrando que la tarea está en ejecución? ¿Puede otro trabajador retomarla?
Aquí la ingeniería tradicional de backend se vuelve esencial. Los agentes en producción necesitan:
- Reintentos, para que los fallos temporales no arruinen el flujo de trabajo.
- Idempotencia, para que un reintento no genere efectos secundarios duplicados.
- Puntos de control, para que un flujo de trabajo largo sepa qué pasos ya se han completado.
- Tiempo de espera, porque un agente no debería seguir funcionando indefinidamente.
QUEUED → RUNNING → COMPLETED o QUEUED → RUNNING → FAILED → RETRYING.Nada de esto suena tan emocionante como la ingeniería de prompts, pero es el trabajo que hace que los agentes sean confiables.
Viendo lo que hizo el agente
Las aplicaciones comunes ya necesitan registros y métricas. Los agentes necesitan aún más. Cuando uno produce un resultado deficiente, saber que la solicitud HTTP devolvió 200 OK casi no dice nada. Lo importante es todo el proceso: la solicitud, el contexto recuperado, la formulación del prompt, la llamada al modelo, la herramienta seleccionada, su ejecución, la evaluación del resultado y la respuesta final.
Para cada ejecución, un equipo debería poder recuperar lo siguiente:
- El contexto que se le dio al agente
- El modelo que se ejecutó
- Las herramientas que se invocaron y en qué orden
- El tiempo dedicado a cada paso
- Consumo de tokens
- La causa de una falla, ya sea por problemas en la infraestructura o en el razonamiento
- El veredicto de la fase de evaluación
Esa es una de las razones por las cuales el rastreo y la evaluación se han convertido en partes tan importantes del ecosistema de agentes. Lo que no puede observarse no puede mejorarse.
Pruebas de comportamiento no determinista
El software clásico ofrece una regla reconfortante: la entrada A produce la salida B. Los LLM no cumplen necesariamente con esto, ya que dos respuestas válidas pueden expresarse de maneras completamente diferentes. Por lo tanto, las pruebas requieren varios niveles.
Las partes deterministas se prueban de la forma habitual: APIs, cálculos, esquemas, transiciones de estado y operaciones en la base de datos. Las partes basadas en modelos se evalúan en cuanto a corrección factual, completitud, relevancia, calidad del razonamiento, selección de herramientas y seguimiento de instrucciones. Los flujos de trabajo realistas de extremo a extremo deben ejecutarse con datos representativos, ya que detectan problemas que las solicitudes aisladas pasan por alto. Incluso un conjunto sólido de herramientas no puede abarcar todas las entradas del mundo real, por lo que el ciclo de evaluación continúa después del despliegue.
La autonomía debe hacer seguimiento al riesgo
Algunos suponen que un agente “real” debe ser completamente autónomo. Esa visión ignora el papel del riesgo. Compare tres acciones: resumir un documento, recomendar un cambio en un registro financiero y ejecutar automáticamente una transacción de alto impacto. No deberían compartir el mismo modelo de aprobación. Una disposición práctica sería la siguiente:
- Bajo riesgo: ejecutar automáticamente.
- Riesgo medio: ejecutar y luego registrar o revisar.
- Riesgo alto: requerir aprobación humana antes de ejecutar.
El objetivo no es la máxima autonomía, sino una autonomía útil con riesgo controlado.
En conjunto, la imagen es clara, y el LLM resulta ser un componente relativamente pequeño dentro de ella. Eso es intencional.
Preguntas antes de elegir un marco
Antes de seleccionar un marco o redactar una instrucción detallada, vale la pena plantearse algunas preguntas:
- ¿Qué decisión realmente necesita IA? Un solo paso de razonamiento no hace que todo el flujo de trabajo sea inteligente.
- ¿Qué puede mantenerse determinista? Los cálculos, la validación, los permisos y las reglas empresariales críticas deben estar en el código.
La ingeniería de prompts, la selección de modelos y RAG siguen siendo importantes. Pero la producción exige una disciplina más amplia: una arquitectura de software basada en inteligencia probabilística. El diseño más sólido no es el que cuenta con la mayor cantidad de agentes, el modelo más grande o el framework de orquestación más sofisticado. Es aquel en el que se puede especificar qué sabe el agente, qué puede y no puede hacer, cómo se mide la corrección, qué ocurre en caso de fallo y cómo se recupera el sistema. Es entonces cuando un agente de IA deja de ser una simple demostración para convertirse en software digno de confianza.
Lecturas relacionadas
- Sobrevivir a los picos de tráfico en sistemas multi-agente con un contrato de tres capas — Cómo mantener fiable el grafo de agentes cuando la carga se multiplica por diez: un controlador de colas, limitación del uso de herramientas y verificaciones síncronas de políticas, además de métricas y un análisis detallado de los picos de tráfico.
- Transmisión en tiempo real de LangChain Deep Agents: planes en vivo, llamadas a herramientas y tokens — Reemplazar una llamada bloqueante por una transmisión en tiempo real para que los usuarios vean cómo funciona un agente avanzado: los tres modos de transmisión, nombres de espacio para subagentes y filtrado de tokens de resumen.