Agentes IA en producción: guía de arquitectura
Cómo diseñar agentes IA con herramientas, estado, trazas, evaluación, límites y escalado humano antes de llevarlos a producción.
Un proyecto de agentes suele empezar así: un equipo quiere que un sistema de IA lea tickets, recupere contexto del CRM y del sistema de pedidos, intente resolver el caso y escale a una persona cuando haga falta.
La primera versión suele ser un solo prompt. Funciona en demo y falla en los bordes que importan. A veces falla en silencio. A veces da una respuesta incorrecta con mucha seguridad.
La solución no siempre es "más agentes". La solución suele ser mejor arquitectura: herramientas claras, estado explícito, límites de bucle, trazas, evaluación y reglas de escalado humano.
Decisión rápida
Usa un agente cuando el modelo tenga que actuar, mirar el resultado y decidir el siguiente paso. No uses un agente cuando una sola llamada LLM, un flujo determinista o una respuesta RAG sencilla sean suficientes.
Para quien está contratando ayuda, este es el primer filtro. Un flujo de agentes es un sistema de producción, no una técnica de prompt. Si puede llamar herramientas, necesita permisos. Si puede entrar en bucle, necesita límites. Si puede afectar a un cliente o a un registro interno, necesita condiciones de revisión humana.
Qué significa realmente "agente"
Un agente es un LLM que puede tomar acciones, observar resultados y decidir qué hacer después. A diferencia de un patrón simple de pregunta-respuesta, los agentes operan en bucles.
El bucle básico:
- Recibir un objetivo
- Decidir una acción
- Ejecutar la acción (llamar a una herramienta, consultar base de datos, hacer una llamada API)
- Observar el resultado
- Decidir si el objetivo se ha logrado
- Si no, ir al paso 2
Esto suena simple. La complejidad viene de todo lo que puede ir mal en los pasos 2-6.
Cuándo usar agentes (y cuándo no)
Los agentes son apropiados cuando:
La tarea requiere múltiples pasos con dependencias. Investigar un tema, luego escribir un resumen, luego verificar contra fuentes. Cada paso depende de resultados anteriores.
El camino no es predecible. No puedes escribir un diagrama de flujo porque los pasos requeridos dependen de lo que descubras por el camino.
La tarea se beneficia de iterar. Escribir código, probarlo, arreglar errores y volver a probar. El bucle importa.
El uso de herramientas es central. El LLM necesita buscar en bases de datos, llamar APIs, o interactuar con sistemas externos para completar la tarea.
Los agentes NO son apropiados cuando:
Un solo prompt funciona. Si puedes obtener resultados fiables con una sola llamada LLM, añadir complejidad de agente es desperdicio.
El flujo es fijo. Si los pasos A, B y C siempre ocurren en ese orden con las mismas herramientas, ejecútalos secuencialmente. No necesitas un agente.
La latencia es crítica. Los bucles de agente toman tiempo. Cada paso es una llamada LLM más ejecución de herramienta. Si necesitas respuestas por debajo del segundo, los agentes normalmente no encajan.
Los requisitos de fiabilidad son extremos. Los agentes pueden fallar de formas inesperadas. Para sistemas críticos de seguridad, la lógica programada explícita es más segura.
Los tres patrones de agente que funcionan
Patrón 1: ReAct (Reasoning + Acting)
El agente razona sobre qué hacer, toma una acción, observa el resultado, luego razona de nuevo.
Pensamiento: Necesito encontrar el historial de pedidos del cliente
Acción: query_crm(customer_id="12345")
Observación: El cliente tiene 3 pedidos: #1001 (entregado), #1002 (en tránsito), #1003 (cancelado)
Pensamiento: El cliente pregunta por el pedido #1002 que está en tránsito
Acción: get_tracking(order_id="1002")
Observación: El paquete está en el centro de distribución, ETA mañana
Pensamiento: Tengo la información necesaria para responder
Acción: respond("Su pedido #1002 está en nuestro centro de distribución y llegará mañana")
Cuándo usarlo: Tareas de propósito general donde el agente necesita descubrir el enfoque sobre la marcha. Bueno para servicio al cliente, tareas de investigación, análisis de datos.
Cuidado con: Bucles de razonamiento que no van a ninguna parte. El agente piensa y piensa pero nunca actúa. Establece iteraciones máximas y vigila la longitud media del bucle.
Patrón 2: Planificar y Ejecutar
El agente primero crea un plan, luego ejecuta cada paso. El plan puede revisarse si algo falla.
Plan:
1. Obtener detalles del cliente del CRM
2. Verificar estado del pedido en sistema de fulfillment
3. Si hay retraso, consultar API de logística por motivo
4. Componer respuesta con estado y cualquier compensación disponible
Ejecutar paso 1: query_crm(...)
Ejecutar paso 2: check_order_status(...)
...
Cuándo usarlo: Tareas complejas con múltiples fases. Escribir documentos, análisis multi-paso, tareas que se benefician de estructura explícita.
Cuidado con: Planes demasiado rígidos. Si el paso 2 falla, el agente podría no saber cómo adaptarse. Incluye triggers de replanificación.
Patrón 3: Colaboración multi-agente
Múltiples agentes especializados trabajan juntos. Un router u orquestador decide qué agente maneja qué.
Router recibe: "Quiero devolver el pedido #1002 y también tengo una pregunta de facturación"
Análisis del Router: Dos issues separados detectados
- Enrutar a: Agente de Devoluciones (solicitud de devolución)
- Enrutar a: Agente de Facturación (pregunta de facturación)
Agente de Devoluciones maneja la devolución...
Agente de Facturación maneja facturación...
Router combina respuestas
Cuándo usarlo: Cuando diferentes subtareas requieren diferentes capacidades, herramientas, o system prompts. Cuando quieres mantener cada agente enfocado y simple.
Cuidado con: Coste de coordinación. Cuantos más agentes, más posibilidades de malentendidos. Mantén el número pequeño, normalmente entre 3 y 5.
Lecciones de implementación en producción
1. Las herramientas son más importantes que los prompts
En producción, el diseño de herramientas suele importar más que los prompts. Una herramienta bien diseñada, con esquemas claros de entrada y salida, facilita el trabajo del agente. Una herramienta vaga lleva a parámetros inventados y llamadas fallidas.
Buena definición de herramienta:
{
"name": "get_order_status",
"description": "Obtener estado actual de un pedido de cliente",
"parameters": {
"order_id": {
"type": "string",
"description": "ID de pedido en formato ORD-XXXXX",
"pattern": "^ORD-[0-9]{5}$"
}
},
"returns": {
"status": "pending | processing | shipped | delivered | cancelled",
"last_updated": "ISO 8601 timestamp"
}
}
Mala definición de herramienta:
{
"name": "check_order",
"description": "Verificar algo sobre un pedido",
"parameters": {
"id": { "type": "string" }
}
}
2. El manejo de errores determina la tasa de éxito
Muchos fallos de agentes vienen de casos límite no gestionados. La herramienta devuelve un error, el agente no sabe qué hacer y toda la tarea falla.
Construye manejo de errores explícito:
- ¿Qué pasa si la API está caída?
- ¿Qué pasa si el customer ID no existe?
- ¿Qué pasa si el agente intenta una acción que no tiene permitida?
Dale al agente una salida digna. "Si no puedes recuperar el estado del pedido, informa al cliente de que lo estás verificando manualmente y harás seguimiento."
3. La observabilidad no es negociable
Necesitas ver:
- Cada pensamiento, acción y observación dentro del bucle
- Qué herramientas se llamaron con qué parámetros
- Cuánto tiempo tomó cada paso
- Dónde ocurrieron los fallos
Sin esto, depurar el comportamiento de agentes es adivinación. Cada paso del agente debería generar un evento estructurado que pueda consultarse después.
4. Los guardrails previenen desastres
Los agentes pueden hacer cosas inesperadas. Construye guardrails:
Límites de acciones. Máximo N llamadas a herramientas por tarea. Máximo M tokens generados. Máximo T segundos de runtime.
Límites de permisos. El agente puede LEER del CRM pero no puede ESCRIBIR. Puede consultar pedidos pero no puede cancelarlos.
Validación de salida. Antes de enviar una respuesta al cliente, verifícala contra políticas de contenido. Marca cualquier cosa que parezca incorrecta para revisión humana.
Condiciones de revisión humana. Define cuándo el agente debe escalar: baja confianza, decisiones de alto impacto o incertidumbre explícita.
5. Empieza simple, añade complejidad solo cuando sea necesario
El primer agente para casi cualquier caso de uso debería ser un solo bucle ReAct con 3-4 herramientas. Mide dónde falla. Luego añade complejidad específicamente para abordar esos fallos.
No diseñes un sistema multi-agente sofisticado el día uno. Todavía no sabes lo que necesitas.
Realidad de costes y latencia
Los flujos de agentes son caros. Cada paso de razonamiento es una llamada LLM. Un bucle de 5 pasos con un modelo grande puede costar bastante por tarea. A mucho volumen, el coste diario se dispara si no hay enrutado, caché y límites.
La latencia también suma. Cada paso son 1-3 segundos para el LLM más tiempo de ejecución de herramienta. Un bucle de 5 pasos puede tardar 10-20 segundos en total.
Estrategias de optimización:
- Usa modelos más baratos para pasos simples y reserva los caros para razonamiento complejo
- Cachea consultas comunes
- Paraleliza llamadas a herramientas independientes
- Precomputa donde sea posible
Modos de fallo comunes
El bucle infinito. El agente sigue intentando la misma acción esperando resultados diferentes. Solución: guarda historial de acciones, detecta repetición y fuerza otro enfoque o escalado.
Llamadas a herramientas inventadas. El agente inventa parámetros que no existen. Solución: validación estricta de esquema, mensajes de error claros y ejemplos en la descripción de herramientas.
Contexto perdido. En conversaciones largas, el agente olvida información anterior. Fix: ventanas de contexto explícitas, resumen entre pasos, retrieval vectorial para contexto largo.
Exceso de confianza. El agente produce una respuesta incorrecta pero la presenta con seguridad total. Solución: señales de incertidumbre, validación de salida y revisión humana para casos límite.
Alcance descontrolado. El agente intenta ayudar con cosas fuera de sus capacidades. Solución: límites explícitos en el prompt de sistema, detección de fuera de alcance y rechazo claro.
Para empezar
Si estás construyendo tu primer agente:
- Elige UNA tarea específica con criterios de éxito claros
- Define 3-5 herramientas que el agente necesita
- Construye un bucle ReAct simple
- Ejecuta 100 casos de test, mide tasa de éxito
- Analiza fallos y añade correcciones específicas
- Itera hasta alcanzar tu objetivo de precisión
- Solo entonces considera multi-agente o patrones más complejos
La mayoría de equipos sobre-complican demasiado pronto. Un agente simple bien afinado gana a un sistema complejo mal afinado cada vez.
Si estás trabajando en un sistema de agentes y quieres una segunda opinión antes de llevarlo a usuarios reales, contacta con Pharosyne. Para ver cuándo tiene sentido partir en varios agentes, lee la guía sobre sistemas multi-agente en empresa, revisa el servicio de sistemas multi-agente o usa la guía de auditoría técnica de IA.
Contacto
Si este artículo te ha resultado útil y quieres explorar cómo aplicar estas ideas en tu empresa, agenda una llamada.
Empezar proyecto