Tu flujo de trabajo de IA está funcionando ahora mismo.
Lo que no sabes es que dejó de funcionar hace tres días.
Sigue activo. Sigue quemando créditos de API. Sigue generando 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 te envíe una captura de pantalla 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 crean flujos de trabajo de IA y los publican en Twitter.
El demo se ve impecable. El hilo recibe likes. Los comentarios dicen "esto es el futuro".
Treinta días después, el flujo de trabajo está muerto.
No eliminado. No reemplazado. Muerto y todavía funcionando. Cobrando a la tarjeta. Sin producir nada útil. El fundador siguió adelante. El agente no recibió el mensaje.
El 90% de los flujos de trabajo de IA creados hoy no sobrevivirán su primer mes en producción. No porque los modelos sean malos. No porque las ideas estén equivocadas. Sino porque los creadores cometieron tres errores que garantizan el fracaso — y nadie les dijo cuáles eran esos errores antes de lanzarlos.
Ese es este artículo.
Por Qué Mueren
Así es la anatomía de la muerte de un flujo de trabajo. Siempre es la misma secuencia.
Día 1: Lo construyes. Funciona perfectamente en el demo. Sientes que descubriste 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 se modifica ligeramente. Una fuente que leía 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. El resultado se degrada silenciosamente. Nadie lo nota.
Día 14: El flujo de trabajo ahora produce resultados que técnicamente son una respuesta, pero sustancialmente inútiles. Sigue funcionando. Sigues pagando por ello.
Día 23: Un cliente o un colega menciona que algo anda mal. Investigas. Encuentras 12 días de resultados defectuosos que pensabas que se estaban 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 al fin de semana.
Una descripción del puesto tiene cinco partes:
Lo que vigila. El activador o calendario específico. "Cada 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 estas tres fuentes 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 protección. "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 al 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. El resultado llega. El formato es correcto. El contenido está mal — ligeramente, luego más, luego completamente — y como 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 configuraste para que las programe automáticamente si 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 puntúan 82 ahora son mediocres según tu estándar real. Salen de todas formas. Tu interacción baja. Culpas al algoritmo.
Tu agente de investigación envía un informe semanal. En el día 11, una de las fuentes que leía cambia su estructura de URL. El agente falla al obtenerla silenciosamente. Llena el vacío con datos cacheados más antiguos y no marca la brecha. 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, empieza a categorizar 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 casualmente comparte 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 la salida. Cada agente necesita tres cosas:
Una salida canario. Un campo en cada salida que sea fácil de verificar y difícil de falsificar. Una marca de tiempo de la fuente más reciente que leyó. Un conteo de elementos que procesó. Una puntuación de confianza. Algo que puedas ver en dos segundos y sepas 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é puede que no haya encontrado nada." Nada siempre es más útil que un resultado vacío convincente.
Una verificación puntual semanal. Elige una salida por semana por agente. Lée completo. Compáralo con lo que tú mismo habrías escrito. Esto toma cuatro minutos. Detecta la deriva antes de que se convierta en fracaso.
Los agentes no fallan ruidosamente. Construye para las roturas silenciosas.
Regla 3 — Tu laptop no es infraestructura
Aquí es donde muere el 90% de los creadores.
Construyen localmente. El demo funciona. Publican el hilo en Twitter. Alguien pregunta si está corriendo en producción. Dicen que sí. Lo que quieren decir es: está corriendo en su MacBook, que está actualmente abierta, en su escritorio, en su departamento, conectada a su WiFi de casa, y dejará de funcionar cuando cierren la tapa para ir al aeropuerto el jueves.
Tu laptop no es infraestructura. Es un entorno de desarrollo que casualmente está ejecutando algo importante ahora mismo.
Esto es lo que les pasa a los agentes alojados en laptops:
macOS empuja 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. Seis horas de flujos de trabajo perdidos. El agente de clasificación de bandeja de entrada no clasificó. El cazador de bugs no cazó. El agente de la reunión diaria no envió nada.
Tu WiFi de casa se cae durante veinte minutos. El agente reintenta. Falla. Sigue adelante. No registra nada. La ventana que debía capturar ya pasó.
Te vas de vacaciones. La laptop se queda en casa. Todo se queda en casa con ella.
La infraestructura real funciona cuando no estás mirando. Funciona cuando estás dormido, en un avión, cenando, 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 permitirte que pierda un ciclo, no vive en tu laptop.
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 cae, PM2 lo reinicia automáticamente. Si el servidor se reinicia, PM2 lo inicia al arrancar. Barato. Confiable. No es glamoroso. 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 activados por EventBridge o Cloud Scheduler. Cero infraestructura que gestionar. Pagas por ejecución. Escala a cero cuando no se ejecuta. 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 te salvará de la actualización de macOS a las 4 a.m. que mata a tus agentes y a tu lunes por la mañana.
Cierra la laptop. 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: Cada lunes a las 7 a.m., lee los últimos 7 días de publicaciones 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 superado las 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 alerta: "semana tranquila — esto es lo que se revisó". Entrega en esta página de Notion y envía una notificación de Slack.
La salida canario: Cada informe incluye: "Fuentes revisadas: 8. Elementos procesados: [N]. Marca de tiempo del elemento más reciente: [marca de tiempo]." 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 cae, 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 desviaciones 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 día nueve.
La Verdad Incómoda
La mayoría de la gente leerá esto, asentirá y construirá su próximo agente de la misma manera que construyó el anterior.
Un prompt. Un demo. Un hilo en 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 el 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 laptop 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 al fin de semana. Define qué vigila, qué lee, qué produce, qué 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 canario, una alerta de fallo silencioso y una verificación puntual semanal en cada agente.
Regla 3 — Tu laptop 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 bien construidos.
