Workflows agénticos: guía práctica de implementación
Cómo construir agentes IA que realmente funcionen en producción. Patrones, anti-patrones, y lecciones de deployments reales.
El trimestre pasado Pharosyne ayudó a una empresa de logística a automatizar su proceso de escalado de servicio al cliente. Querían un sistema de IA que pudiera leer tickets entrantes, obtener contexto de su CRM y sistema de pedidos, intentar resolución, y escalar a humanos cuando fuera necesario.
La primera versión era un solo prompt. Funcionaba para el 40% de los tickets. El otro 60% fallaba silenciosamente o producía respuestas incorrectas con alta confianza.
La versión final usa cuatro agentes especializados coordinados por un router. Maneja el 78% de los tickets correctamente y sabe cuándo escalar. La diferencia no fueron prompts más inteligentes. Fue mejor arquitectura.
Qué significa realmente "agéntico"
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 prompt-respuesta, los agentes operan en loops.
El loop 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 la iteración. Escribir código, testearlo, arreglar errores, testear de nuevo. El loop 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 workflow es fijo. Si los pasos A, B, C siempre ocurren en ese orden con las mismas herramientas, simplemente ejecútalos secuencialmente. No se necesita agente.
La latencia es crítica. Los loops de agente toman tiempo. Cada paso es una llamada LLM más ejecución de herramienta. Si necesitas respuestas sub-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: Loops de razonamiento que no van a ninguna parte. El agente piensa y piensa pero nunca actúa. Establece iteraciones máximas y monitorea longitud promedio de loop.
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: Overhead de coordinación. Cuantos más agentes, más posibilidades de miscomunicación. Mantén el número pequeño (3-5 suele ser el sweet spot).
Lecciones de implementación en producción
1. Las herramientas son más importantes que los prompts
Pharosyne dedica el 70% del tiempo de desarrollo al diseño de herramientas, 30% a prompts. Una herramienta bien diseñada con schemas de input/output claros hace el trabajo del agente fácil. Una herramienta vaga lleva a parámetros alucinados 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
En la experiencia de Pharosyne, 30-40% de fallos de agente vienen de edge cases no manejados. 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 fallbacks elegantes. "Si no puedes recuperar el estado del pedido, informa al cliente que estás verificando manualmente y harás seguimiento."
3. La observabilidad no es negociable
Necesitas ver:
- Cada pensamiento/acción/observación en el loop
- Qué herramientas se llamaron con qué parámetros
- Cuánto tiempo tomó cada paso
- Dónde ocurrieron los fallos
Sin esto, debuggear comportamiento de agentes es adivinación. Pharosyne usa logging estructurado donde cada paso del agente genera un evento JSON que puede 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 output. Antes de enviar una respuesta al cliente, verifícala contra políticas de contenido. Marca cualquier cosa que parezca incorrecta para revisión humana.
Triggers human-in-the-loop. Define condiciones donde el agente debe escalar: baja confianza, decisiones de alto impacto, incertidumbre explícita.
5. Empieza simple, añade complejidad solo cuando sea necesario
El primer agente de Pharosyne para cualquier caso de uso es un solo loop ReAct con 3-4 herramientas. Eso es todo. 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 workflows agénticos son caros. Cada paso de razonamiento es una llamada LLM. Un loop de agente de 5 pasos con GPT-4 cuesta aproximadamente $0.05-0.15 por tarea. A 10,000 tareas por día, eso es $500-1500/día solo en costes LLM.
La latencia también suma. Cada paso son 1-3 segundos para el LLM más tiempo de ejecución de herramienta. Un loop de 5 pasos puede tomar 10-20 segundos en total.
Estrategias de optimización:
- Usa modelos más baratos para pasos simples (GPT-4o-mini para routing, GPT-4 para razonamiento complejo)
- Cachea consultas comunes
- Paraleliza llamadas a herramientas independientes
- Precomputa donde sea posible
Modos de fallo comunes
El loop infinito. El agente sigue intentando la misma acción esperando resultados diferentes. Fix: trackea historial de acciones, detecta repetición, fuerza enfoque diferente o escalación.
Llamadas a herramientas alucinadas. El agente inventa parámetros que no existen. Fix: validación estricta de schema, mensajes de error claros, ejemplos en descripciones 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.
Sobreconfianza. El agente produce respuesta incorrecta pero la presenta con confianza total. Fix: training de calibración, señales de incertidumbre, validación de output, revisión humana para edge cases.
Scope creep. El agente intenta ayudar con cosas fuera de sus capacidades. Fix: límites de scope explícitos en system prompt, detección de fuera-de-scope, rechazo elegante.
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 loop ReAct simple
- Ejecuta 100 casos de test, mide tasa de éxito
- Analiza fallos, añade fixes específicos
- Itera hasta alcanzar tu target 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 sistemas agénticos y quieres una segunda opinión sobre tu arquitectura, contacta con Pharosyne. Pharosyne ha desplegado agentes en producción para logística, servicio al cliente, procesamiento de documentos, y generación de código. Para más información sobre cuándo arquitecturas multi-agente tienen sentido, consulta la guía sobre sistemas multi-agente en empresa, o explora los servicios de consultoría disponibles.
¿HABLAMOS?
Si este artículo te ha resultado útil y quieres explorar cómo aplicar estas ideas en tu empresa, agenda una llamada.
Iniciar proyecto