Agentes de IA en produccion: lo que nadie te cuenta antes de implementarlos
Los agentes de IA son la nueva frontera del software. Pero entre el hype de las demos y la realidad de producción hay una brecha enorme. Entre pruebas propias, documentación técnica y aprendizajes compartidos por equipos que ya los operan, hay lecciones que conviene tener claras antes de lanzarse.
Cuando revisas demos, postmortems, documentacion de vendors y despliegues publicos de equipos que comparten aprendizajes, los mismos patrones de error aparecen una y otra vez. Cambia el caso de uso, pero no cambian tanto los fallos de arquitectura, observabilidad y coste.
Este artículo no es una introducción teórica a los agentes de IA. Para eso hay miles de posts. Esto es lo que suele pasar cuando un agente sale del playground y se enfrenta a usuarios, latencia, costes y datos cambiantes.
Qué es realmente un agente de IA (y qué no es)
Antes de entrar en los errores, alineemos conceptos. Un agente de IA no es un chatbot avanzado. La diferencia fundamental es la capacidad de acción: un agente puede invocar herramientas, tomar decisiones en bucle y modificar el entorno en función de los resultados.
La arquitectura base de cualquier agente tiene tres componentes esenciales:
Un agente es cualquier sistema donde el LLM decide dinámicamente cuántas veces se ejecuta un loop y qué herramientas invoca en cada iteración. Si el flujo de ejecución está hardcodeado, es un pipeline, no un agente.
Error #1 - La demo funciona perfectamente. Producción, no tanto.
Este es el patrón más común que vemos. En el entorno de desarrollo todo va perfecto: el agente completa la tarea en 3 o 4 pasos, el LLM razona correctamente y las tools responden en milisegundos. Llegas a producción y:
Nunca evalúes un agente solo con inputs que tú has diseñado. Antes de producción, expón el sistema a un grupo reducido de usuarios reales durante al menos 2 semanas. Los patrones de uso real te van a sorprender siempre.
La solución: shadow mode antes del lanzamiento
Lo que hacemos ahora en todos los proyectos es un periodo de shadow mode: el agente procesa peticiones reales en paralelo al sistema existente, pero sus respuestas no se muestran al usuario. Recogemos todas las ejecuciones, las evaluamos offline y ajustamos el system prompt y las tools antes del lanzamiento real.
Error #2 - El system prompt que "funcionaba" deja de funcionar
El system prompt es la columna vertebral de cualquier agente. Defines la personalidad, las restricciones, el formato de respuesta y la lógica de decisión. El problema: los system prompts son frágiles.
¿Qué significa frágiles? Que pequeños cambios en el modelo, en el contexto de entrada o incluso en el orden de los mensajes pueden cambiar significativamente el comportamiento del agente.
# Sistema fragil: system prompt hardcodeado system_prompt = "Eres un asistente que ayuda a los usuarios..." # Sistema robusto: prompts versionados y testeados class AgentConfig: VERSION = "v2.4.1" def get_system_prompt(self, context: dict) -> str: base = self._load_prompt_template("agent_base") constraints = self._load_constraints(context["user_tier"]) return f"""{base} ## Restricciones activas (tier: {context['user_tier']}) {constraints} ## Herramientas disponibles {self._format_tools(context['available_tools'])} ## Contexto de sesion - Usuario: {context['user_id']} - Sesion iniciada: {context['session_start']} - Historial de interacciones: {context['interaction_count']} """ # Test automatizado del prompt def test_prompt_regression(config, test_suite): results = [] for test in test_suite: response = run_agent(config, test["input"]) results.append({ "passed": evaluate_response(response, test["expected"]), "test": test["name"] }) return results
La práctica que recomendamos: tratar los system prompts como código. Control de versiones en Git, tests de regresión automatizados antes de cada cambio y un sistema de evaluación que detecte degradaciones de comportamiento.
Error #3 - Tools mal diseñadas que confunden al agente
El 60% de los problemas de comportamiento de un agente no vienen del LLM sino de las tools. Un LLM potente con tools mal definidas produce resultados terribles. Un LLM modesto con tools bien diseñadas produce resultados sorprendentemente buenos.
| Característica | Tool mal diseñada | Tool bien diseñada |
|---|---|---|
| Nombre | get_data(), process() | search_customer_orders_by_date() |
| Descripción | "Obtiene datos del sistema" | "Busca pedidos de un cliente en un rango de fechas. Devuelve lista ordenada por fecha descendente. Máx. 50 resultados." |
| Parámetros | json genérico sin tipado | Tipados, con ejemplos y validación |
| Errores | Excepción sin contexto | Error descriptivo con acción sugerida |
| Idempotencia | No garantizada | Garantizada para reads, controlada para writes |
Si el nombre de una tool no deja completamente claro qué hace, cuándo usarla y qué devuelve, el agente va a usarla mal. Escribe las descripciones de tools como si le explicaras a un colega nuevo exactamente cuándo y por qué usar esa función.
# Tool vaga que confunde al agente bad_tool = { "name": "send_message", "description": "Sends a message to a user", "parameters": {"type": "object", "properties": { "data": {"type": "string"} }} } # Tool clara que el agente usa correctamente good_tool = { "name": "send_email_notification_to_customer", "description": """Envia un email de notificacion al cliente. USAR CUANDO: el usuario solicite notificar a un cliente sobre el estado de su pedido, una actualizacion o un problema resuelto. NO USAR PARA: mensajes internos del equipo o notificaciones masivas. IMPORTANTE: siempre confirmar con el usuario antes de enviar si el contexto no lo especifica claramente.""", "parameters": { "type": "object", "properties": { "customer_id": { "type": "string", "description": "ID del cliente en el sistema CRM" }, "subject": { "type": "string", "description": "Asunto del email. Max. 80 caracteres." }, "body": { "type": "string", "description": "Cuerpo del email en texto plano o HTML." }, "priority": { "type": "string", "enum": ["low", "normal", "high"], "default": "normal" } }, "required": ["customer_id", "subject", "body"] } }
Error #4 - Ignorar el coste hasta que ya es tarde
Los agentes son inherentemente más caros que las llamadas simples a un LLM. Un agente que completa una tarea puede generar entre 5 y 20 llamadas al modelo, cada una con el contexto acumulado de las anteriores. El coste escala de forma no lineal.
Este patrón aparece con frecuencia en equipos que pasan de una demo prometedora a uso real sin modelar el coste. La estimación inicial parece razonable, pero el agente acaba resolviendo cada tarea con muchas más llamadas al modelo y con contextos mucho más largos de lo esperado.
La solución tiene varios vectores:
Error #5 - Sin observabilidad, estás volando a ciegas
En una aplicación web tradicional, si algo falla tienes logs, trazas y métricas. En un agente, el problema es que el LLM puede "fallar" de formas que no generan errores: respuestas plausibles pero incorrectas, decisiones subóptimas o comportamientos inesperados con inputs edge-case.
Lo que implementamos en todos los proyectos de agentes es un stack de observabilidad completo:
Las métricas que monitorizamos en cada despliegue: latencia p50, p95 y p99 por tipo de tarea, coste por tarea con alertas de anomalía, tasa de escalado a humano, score de calidad evaluado por un LLM separado y feedback explícito del usuario.
Error #6 - Human-in-the-loop como afterthought
En las demos de agentes nadie falla. En producción, el agente va a encontrar situaciones que no puede resolver correctamente. La pregunta no es si va a pasar, sino qué haces cuando pasa.
Diseñar el human-in-the-loop desde el principio es crítico. No como un "por si acaso", sino como una parte integral del sistema. El agente debe saber cuándo escalarse a sí mismo, cómo comunicar el motivo y cómo transferir el contexto al humano de forma que pueda continuar sin fricción.
Escalado por confianza: el agente calcula internamente un score de confianza en su respuesta. Si está por debajo de un umbral, en lugar de responder con algo potencialmente incorrecto, notifica al usuario que va a escalar la consulta a un agente humano. Esto es infinitamente mejor que una respuesta confiada y equivocada.
Cuándo recomendamos (y cuándo no) implementar un agente
Un agente no es siempre la respuesta correcta. Después de varios proyectos, estos son los criterios que usamos para decidir:
| Criterio | Agente: sí | Agente: no (todavía) |
|---|---|---|
| Flujo de trabajo | Variable, depende del input | Siempre el mismo, predecible |
| Herramientas necesarias | Múltiples, combinables | Una sola acción |
| Tolerancia al error | Alta, con human-in-the-loop | Cero; procesos críticos sin revisión |
| Volumen esperado | Bajo o medio con tareas complejas | Muy alto con tareas simples |
| Presupuesto de latencia | Segundos son aceptables | Milisegundos requeridos |
| Datos disponibles | Suficientes para evaluar calidad | Sin forma de medir si funciona bien |
Conclusión: los agentes no son magia, son ingeniería
El hype alrededor de los agentes de IA lleva a muchos equipos a subestimar la complejidad de llevarlos a producción. No son una solución plug-and-play. Son sistemas de software complejos que requieren diseño cuidadoso, testing exhaustivo, observabilidad completa y una estrategia de degradación elegante cuando las cosas salen mal.
Dicho esto, cuando están bien implementados, los agentes pueden automatizar tareas que antes requerían horas de trabajo humano cualificado. La rentabilidad puede ser extraordinaria. El truco está en no saltarse los pasos.
Si estás evaluando implementar un agente de IA en tu empresa, empieza pequeño: un caso de uso bien delimitado, datos suficientes para medir calidad y human-in-the-loop desde el día uno. Luego escala.
Si estás valorando si un agente encaja en tu caso de uso, escríbenos sin compromiso. Podemos ayudarte a aterrizar alcance, riesgos y siguiente paso antes de construir.