La automatización tradicional funciona o no funciona. Un zap de Zapier mueve datos de A a B — si la llamada API falla, reintenta. El output es el mismo cada vez.
Los workflows de IA son diferentes. Un modelo podría agotar el tiempo bajo carga. Un límite de velocidad podría limitar sus solicitudes. El output podría ser válido pero no dar en el blanco. Y como los workflows de IA frecuentemente tienen múltiples pasos, un fallo en el paso 3 no debería perder los resultados exitosos de los pasos 1 y 2.
Diseñar para estas realidades es la diferencia entre workflows en los que su equipo confía y workflows que abandonan después de la primera mala experiencia.
Reintentos automáticos con backoff
JieGou reintenta automáticamente los pasos de recipe fallidos con backoff exponencial. Cuando un paso falla debido a un error transitorio — límites de velocidad (429), errores del servidor (502, 503) o timeouts — el sistema espera y reintenta, haciendo backoff exponencialmente (2s, 4s, 8s, hasta 30s) con jitter aleatorio para evitar problemas de estampida.
Usted configura el conteo máximo de reintentos por paso. Para la mayoría de las recipes, 2-3 reintentos manejan los errores transitorios sin retrasar significativamente el workflow. Para workflows de alto volumen donde los límites de velocidad son comunes, podría configurar conteos de reintentos más altos.
Los errores permanentes — input inválido, fallos de autenticación, rechazos del modelo — omiten los reintentos por completo. No tiene sentido reintentar una solicitud que fallará de la misma manera cada vez.
La clasificación de errores importa
No todos los fallos son iguales. JieGou clasifica los errores en categorías para que el workflow pueda responder apropiadamente:
- Errores transitorios (reintentables): Límites de velocidad, sobrecargas del servidor, timeouts de red. Estos se resuelven solos con reintentos.
- Errores permanentes (no reintentables): Input incorrecto, fallos de autenticación, violaciones de política de contenido. Estos requieren intervención humana o cambios en el input.
- Éxito parcial: La IA devolvió output, pero no coincide completamente con el esquema esperado. El workflow puede continuar con lo que tiene o señalar el problema para revisión.
Esta clasificación es automática. No necesita escribir lógica de manejo de errores — el ejecutor sabe qué códigos de estado HTTP son transitorios y cuáles son permanentes.
Puertas de aprobación como redes de seguridad
Los pasos de aprobación no son solo para la firma de procesos de negocio. También son puntos de control de confiabilidad.
Coloque una puerta de aprobación después de cualquier paso donde la calidad del output importa para los pasos posteriores. Por ejemplo:
- Investigar prospecto (paso de recipe)
- Revisar calidad de la investigación (puerta de aprobación)
- Redactar alcance basado en la investigación (paso de recipe)
Si el paso de investigación devuelve resultados escasos — quizás la empresa es pequeña y hay información pública limitada — la puerta de aprobación permite que un humano decida si proceder con lo disponible o proporcionar contexto adicional antes del borrador de alcance.
Sin la puerta, el paso de alcance generaría un correo basado en investigación incompleta, produciendo un mensaje genérico que anula el propósito de la automatización.
Pasos de condición para validación de output
Use pasos de condición para verificar la calidad del output antes de proceder:
- Extraer datos de factura (paso de recipe)
- Condición: Si total_amount existe y line_items no está vacío (paso de condición)
- Entonces: Continuar a verificación de discrepancias
- De lo contrario: Marcar para procesamiento manual
Esto captura casos donde la IA no logró extraer campos clave — quizás el formato de factura era inusual o el texto fue mal escaneado. En lugar de pasar datos incompletos al siguiente paso, el workflow lo enruta a un humano.
Notificaciones webhook en caso de fallo
Los workflows pueden enviar notificaciones webhook cuando se completan — ya sea exitosamente o con errores. Configure un webhook de salida para notificar a su equipo cuando un workflow falle:
- Publique en un canal de Slack cuando un workflow programado encuentre un error
- Envíe a PagerDuty para workflows críticos que necesitan atención inmediata
- Actualice un panel de estado con la salud del workflow
La carga del webhook incluye el ID de ejecución, estado, qué paso falló y los detalles del error. Su equipo recibe información accionable, no solo “algo se rompió”.
Ejecución paralela y fallos parciales
Los pasos paralelos ejecutan múltiples ramas concurrentemente. Si una rama falla, las otras ramas continúan. Esto es por diseño — un fallo en una rama independiente no debería bloquear trabajo no relacionado.
Después de que la ejecución paralela se completa, puede verificar qué ramas tuvieron éxito y cuáles fallaron. Un paso de condición después del bloque paralelo puede enrutar el workflow basándose en si todas las ramas se completaron o algunas fallaron.
Diseñando para el percentil 95
La mayoría de las llamadas a IA tienen éxito en el primer intento. La mayoría de los outputs coinciden con el esquema esperado. La mayoría de los workflows se ejecutan sin problemas. Pero “la mayoría” no es suficiente cuando está ejecutando workflows diariamente para un equipo que depende de los resultados.
Diseñe sus workflows para el caso del 5%:
- Agregue reintentos a cada paso de recipe. El costo de unas pocas llamadas API extra en caso de fallo es insignificante comparado con el costo de una ejecución de workflow fallida.
- Agregue puertas de aprobación antes de outputs de alto impacto. Si el workflow está generando contenido que va a clientes o ejecutivos, un humano debería verificarlo.
- Agregue verificaciones de condición después de pasos de extracción. Verifique que la IA realmente extrajo los datos que necesita antes de pasarlos adelante.
- Configure notificaciones webhook para workflows programados y activados. Si nadie está observando la UI, necesita alertas cuando las cosas salen mal.
El objetivo son workflows que se degraden con gracia — mostrando los problemas a los humanos en lugar de producir silenciosamente output malo.