Tu flujo de trabajo de IA está funcionando ahora mismo.
Lo que no sabes es que dejó de funcionar hace tres días.
Todavía se está ejecutando. Todavía está gastando créditos de API. Todavía está enviando resultados que nadie lee.
El agente que pasaste dos fines de semana construyendo está produciendo basura a $0.40 por montón de basura — y no te enterarás hasta que un cliente le haga una captura de pantalla y te la envíe un martes.
Esto no es mala suerte. Es el resultado por defecto.
Guarda esto. Lo leerás dos veces.
El cementerio de los 30 días
Cada semana, cientos de fundadores construyen flujos de trabajo de IA y los publican en Twitter.
La demo se ve limpia. El hilo recibe likes. Las respuestas dicen «esto es el futuro».
Treinta días después, el flujo de trabajo está muerto.
No eliminado. No reemplazado. Muerto y todavía ejecutándose. Cobrando en la tarjeta. Sin producir nada útil. El fundador siguió adelante. El agente no se enteró.
El 90% de los flujos de trabajo de IA construidos hoy no sobrevivirán su primer mes en producción. No porque los modelos sean malos. No porque las ideas sean incorrectas. Porque los constructores cometieron tres errores que garantizan el fracaso — y nadie les dijo cuáles eran esos errores antes de lanzarlos.
Este es ese artículo.
Por qué mueren
Aquí está la anatomía de la muerte de un flujo de trabajo. Siempre es la misma secuencia.
Día 1: Lo construyes. Funciona perfectamente en la demo. Sientes que has desbloqueado algo.
Día 3: Todavía funciona. Dejas de revisarlo con tanto cuidado.
Día 9: Algo cambia. El formato de respuesta de una API cambia ligeramente. Una fuente que estaba leyendo se pone detrás de un muro de inicio de sesión. El modelo interpreta un caso límite de manera diferente a como lo hizo el primer día. La salida se degrada silenciosamente. Nadie lo nota.
Día 14: El flujo de trabajo ahora produce una salida que técnicamente es una respuesta, pero sustancialmente inútil. Todavía se está ejecutando. Todavía estás pagando por ello.
Día 23: Un cliente o un colega menciona que algo anda mal. Investidas. Encuentras 12 días de salida defectuosa que pensabas que se estaba manejando.
Día 30: Lo matas. Te dices a ti mismo que la IA no está lista. Sigues adelante.
El modelo no te falló. La construcción falló al modelo.
Las 3 reglas que separan al 10% del resto
Los fundadores cuyos flujos de trabajo sobreviven 30 días, 90 días, un año — no son más inteligentes. No tienen mejores prompts. Construyen con tres reglas que todos los demás ignoran.
Regla 1 — Sin descripción del puesto, no hay agente
La mayoría de la gente construye agentes con una vibra.
«Ayúdame con contenido». «Monitorea competidores». «Maneja correos de clientes».
Eso no es una descripción del puesto. Es un deseo. Y los deseos no sobreviven el fin de semana.
Una descripción del puesto tiene cinco partes:
Lo que observa. El desencadenante o horario específico. «Todos los lunes a las 7 a.m.» o «cada vez que se abre un nuevo issue de GitHub con la etiqueta "bug"» o «cada vez que llega un correo de un dominio que no está en mi lista de contactos». No «a veces» o «cuando sea relevante».
Lo que lee. Las fuentes exactas. No «revisa internet». «Toma de estos tres feeds RSS, esta base de Airtable y los últimos 7 días de este canal de Slack». Específico. Acotado. Sin ambigüedad.
Lo que produce. El formato exacto de salida. No «un resumen». «Un informe de tres secciones: hallazgo principal en una oración, tres viñetas de apoyo con una fuente cada una, una acción recomendada. Menos de 300 palabras. En este Google Doc».
Lo que no hace. Las barreras de seguridad. «Nunca enviar un correo externo sin aprobación humana». «Nunca modificar la base de datos de producción». «Nunca publicar directamente. Siempre guardar en borradores». Las cosas que asumes que son obvias son las que te quemarán.
Cómo sabes que funcionó. La condición de éxito. «Si el informe está vacío, envíame un mensaje de Slack diciendo que no se encontraron actualizaciones relevantes. No envíes un informe vacío».
Las vibras no sobreviven el fin de semana. Las descripciones del puesto sí.
Cada flujo de trabajo que construyas de ahora en adelante comienza con una descripción del puesto. No un prompt. Una descripción del puesto.
Regla 2 — El fallo silencioso es el único fallo que te mata
Los fallos ruidosos están bien. Los fallos ruidosos envían un error. Detienen el flujo de trabajo. Te despiertan. Los arreglas.
Los fallos silenciosos son los que matan negocios.
Un fallo silencioso parece un éxito. El flujo de trabajo se ejecuta. La salida llega. El formato es correcto. El contenido está mal — ligeramente, luego más, luego completamente — y porque se ve bien, nadie lo revisa.
Así es como ocurre un fallo silencioso en la práctica:
Tu agente de contenido escribe 30 publicaciones. Lo configuras para auto-programar las que obtienen una puntuación superior a 80 en tu rúbrica interna. La rúbrica se calibró con tus primeras 20 publicaciones. En el día 15, el modelo comienza a interpretar tu rúbrica de manera diferente. Las publicaciones que obtienen 82 ahora son mediocres según tu estándar real. Salen de todas formas. Tu engagement baja. Culpas al algoritmo.
Tu agente de investigación envía un informe semanal. En el día 11, una de las fuentes que estaba leyendo cambia su estructura de URL. El agente falla al obtenerla silenciosamente. Rellena el vacío con datos antiguos en caché y no marca el vacío. Lees un informe basado en información desactualizada y tomas una decisión basada en él.
Tu agente de clasificación de bandeja de entrada redacta respuestas. En el día 8, comienza a categorizar un cierto tipo de correo como baja prioridad porque el nombre del remitente coincide con un patrón en su entrenamiento. Te pierdes tres correos importantes de un nuevo cliente que resulta compartir apellido con un boletín que nunca lees.
En cada caso: el flujo de trabajo se ejecutó. No se lanzó ningún error. Perdiste de todas formas.
La solución es la verificación obligatoria de salida. Cada agente necesita tres cosas:
Una salida canary. Un campo en cada salida que sea fácil de verificar y difícil de falsear. Una marca de tiempo de la fuente más reciente que leyó. Un recuento de elementos que procesó. Una puntuación de confianza. Algo que puedas revisar en dos segundos y saber que el agente realmente hizo el trabajo.
Una alerta de fallo silencioso. Si el agente no produce nada, o produce algo por debajo de un umbral, no envía una salida vacía. Te envía una alerta. «No se encontraron resultados en este ciclo — esto es lo que revisé y por qué quizás no encontré nada». Nada es siempre más útil que un resultado vacío convincente.
Una verificación puntual semanal. Elige una salida por semana por agente. Léele completamente. Compárala con lo que tú mismo habrías escrito. Esto toma cuatro minutos. Detecta la deriva antes de que la deriva se convierta en fallo.
Los agentes no fallan ruidosamente. Construye para las roturas silenciosas.
Regla 3 — Tu portátil no es infraestructura
Aquí es donde muere el 90% de los constructores.
Construyen localmente. La demo funciona. Publican el hilo de Twitter. Alguien pregunta si está funcionando en producción. Dicen que sí. Lo que quieren decir es: está funcionando en su MacBook, que está abierta, en su escritorio, en su apartamento, conectada a su WiFi doméstico, y dejará de funcionar cuando cierren la tapa para ir al aeropuerto el jueves.
Tu portátil no es infraestructura. Es un entorno de desarrollo que resulta estar ejecutando algo importante en este momento.
Esto es lo que les pasa a los agentes alojados en portátiles:
MacOS envía una actualización a las 4 a.m. La máquina se reinicia. El agente se detiene. Nadie lo sabe hasta el lunes.
Cierras la tapa en un vuelo. Se pierden seis horas de flujos de trabajo. El agente de clasificación de bandeja de entrada no clasificó. El cazador de errores no cazó. El agente de standup no envió nada.
Tu WiFi doméstico se cae durante veinte minutos. El agente reintenta. Falla. Sigue adelante. No registra nada. La ventana que debía capturar se ha ido.
Te vas de vacaciones. El portátil se queda en casa. Todo se queda en casa con él.
La infraestructura real funciona cuando no estás mirando. Funciona cuando estás dormido, en un avión, en la cena, inalcanzable durante un fin de semana. No necesita que mantengas la tapa abierta.
La regla es simple: si el flujo de trabajo necesita ejecutarse más de una vez y no puedes permitir que pierda un ciclo, no vive en tu portátil.
Las tres opciones de infraestructura que realmente funcionan:
Un VPS con un gestor de procesos. Un servidor de $12/mes ejecutando PM2 o Supervisor. Tu agente se ejecuta como un proceso gestionado. Si se bloquea, PM2 lo reinicia automáticamente. Si el servidor se reinicia, PM2 lo inicia al arrancar. Barato. Fiable. No glamuroso. Funciona.
Una plataforma de agentes gestionada. Construida específicamente para esto. Maneja los reinicios, la monitorización, las alertas. Cuesta más que un VPS. Te ahorra los fines de semana que pasarías depurando por qué murió el proceso. Vale la pena una vez que tus agentes generan valor real.
Serverless con un programador. AWS Lambda o Google Cloud Functions activadas por EventBridge o Cloud Scheduler. Cero infraestructura que gestionar. Pagas por ejecución. Escala a cero cuando no está funcionando. Mejor opción para agentes que se ejecutan en un horario fijo en lugar de continuamente.
Ninguna de estas es complicada. Todas requieren quince minutos de configuración. Cada una de ellas te salvará de la actualización de macOS a las 4 a.m. que mata a tus agentes y tu lunes por la mañana.
Cierra el portátil. Los agentes deberían seguir funcionando.
El flujo de trabajo que sobrevive
Así es como se ve un flujo de trabajo de 90 días cuando se aplican las tres reglas.
La descripción del puesto: «Todos los lunes a las 7 a.m., lee las publicaciones de los últimos 7 días de estas 5 cuentas de la competencia y estos 3 boletines de la industria. Extrae cualquier anuncio de producto, cambio de precio o contenido que haya tenido más de 500 interacciones. Compara con el informe de la semana pasada. Marca cualquier novedad. Genera un informe de tres secciones: qué cambió, qué está ganando tracción, qué brecha dejaron abierta. Si no se encuentran cambios, envía una alerta: "semana tranquila — esto es lo que se revisó". Entrégalo a esta página de Notion y envía una notificación de Slack».
La salida canary: «Cada informe incluye: "Fuentes revisadas: 8. Elementos procesados: [N]. Marca de tiempo del elemento más reciente: [timestamp]". Si N es cero o la marca de tiempo tiene más de 8 días, envía una alerta en lugar de un informe».
La infraestructura: «Ejecutándose en un VPS de $12/mes. PM2 gestiona el proceso. Si se bloquea, se reinicia en 30 segundos. Una revisión semanal de registros toma 3 minutos cada viernes».
La verificación puntual: «Cada viernes, se lee un informe completo. Toma 4 minutos. Ha detectado deriva dos veces en seis meses».
Ese flujo de trabajo ha estado funcionando durante seis meses. Ha perdido dos ciclos — ambas veces envió una alerta explicando por qué. Nunca ha fallado silenciosamente.
Esa es la diferencia entre un flujo de trabajo que sobrevive y uno que muere en el noveno día.
La verdad incómoda
La mayoría de la gente leerá esto, asentirá y construirá su próximo agente de la misma manera que construyeron el anterior.
Un prompt. Una demo. Un hilo de Twitter. Treinta días de silencio. Un flujo de trabajo muerto que nadie mató oficialmente.
Las tres reglas no son complicadas. Una descripción del puesto toma veinte minutos escribirla. La verificación de salida toma un campo y un condicional. La infraestructura toma quince minutos configurarla.
La brecha no es conocimiento. La brecha es si lo haces antes de lanzar o después de que el flujo de trabajo falle.
Cada agente que construyas sin una descripción del puesto es un agente que reconstruirás. Cada agente sin verificación de salida es un agente que fallará silenciosamente. Cada agente en tu portátil es un agente que morirá la próxima vez que cierres la tapa.
Constrúyelos bien una vez. Funcionan para siempre.
Sigue a @sairahul1 para más guías completas sobre cómo construir flujos de trabajo de IA que sobrevivan al contacto con el mundo real.
TL;DR
El 90% de los flujos de trabajo de IA mueren en 30 días. Siempre las mismas tres razones.
Regla 1 — Sin descripción del puesto, no hay agente. Las vibras no sobreviven el fin de semana. Define qué observa, lee, produce, evita y cómo sabes que funcionó. Antes de escribir un solo prompt.
Regla 2 — El fallo silencioso es el único fallo que te mata. Los fallos ruidosos están bien. Los fallos silenciosos parecen éxito hasta que un cliente los encuentra. Construye una salida canary, una alerta de fallo silencioso y una verificación puntual semanal en cada agente.
Regla 3 — Tu portátil no es infraestructura. Funciona cuando la tapa está abierta. Los agentes reales funcionan cuando estás dormido, en un avión, inalcanzable durante un fin de semana. VPS, plataforma gestionada o serverless. Elige uno. Configúralo antes de lanzar.
Los agentes que sobreviven no son más inteligentes. Están construidos correctamente.
