Seu fluxo de trabalho de IA está rodando agora.
Só que você não sabe que ele parou de funcionar há três dias.
Ele ainda está rodando. Ainda queimando créditos de API. Ainda gerando saídas que ninguém está lendo. O agente que você passou dois fins de semana construindo está produzindo lixo a $0,40 por monte de lixo — e você só vai descobrir quando um cliente tirar um print e te mandar numa terça-feira.
Isso não é azar. É o resultado padrão.
Salve isso. Você vai ler duas vezes.
O Cemitério de 30 Dias
Toda semana, centenas de fundadores constroem fluxos de trabalho de IA e postam no Twitter.
A demo parece limpa. O tópico ganha likes. As respostas dizem "isso é o futuro."
Trinta dias depois, o fluxo de trabalho está morto.
Não deletado. Não substituído. Morto e ainda rodando. Cobrando no cartão. Produzindo nada de útil. O fundador seguiu em frente. O agente não recebeu o aviso.
90% dos fluxos de trabalho de IA construídos hoje não sobreviverão ao primeiro mês em produção. Não porque os modelos são ruins. Não porque as ideias estão erradas. Porque os construtores cometeram três erros que garantem o fracasso — e ninguém disse a eles quais eram esses erros antes de eles lançarem.
Este é esse artigo.
Por Que Eles Morrem
Aqui está a anatomia da morte de um fluxo de trabalho. É sempre a mesma sequência.
Dia 1: Você constrói. Funciona perfeitamente na demo. Você sente que desbloqueou algo.
Dia 3: Ainda funciona. Você para de verificar com tanto cuidado.
Dia 9: Algo muda. O formato de uma resposta da API muda ligeiramente. Uma fonte que ele estava lendo fica atrás de um login. O modelo interpreta um caso extremo de forma diferente do que no primeiro dia. A saída degrada silenciosamente. Ninguém percebe.
Dia 14: O fluxo de trabalho agora está produzindo saídas que são tecnicamente uma resposta, mas substancialmente inúteis. Ainda está rodando. Você ainda está pagando por ele.
Dia 23: Um cliente ou colega menciona que algo está errado. Você investiga. Encontra 12 dias de saídas quebradas que você achava que estavam sendo tratadas.
Dia 30: Você o mata. Diz a si mesmo que a IA não está pronta. Segue em frente.
O modelo não falhou com você. A construção falhou com o modelo.
As 3 Regras Que Separam os 10% de Todos os Outros
Os fundadores cujos fluxos de trabalho sobrevivem 30 dias, 90 dias, um ano — eles não são mais inteligentes. Não têm prompts melhores. Eles constroem com três regras que todo mundo ignora.
Regra 1 — Sem Descrição de Cargo, Sem Agente
A maioria das pessoas constrói agentes com uma vibe.
"Ajude-me com conteúdo." "Monitore concorrentes." "Cuide de e-mails de clientes."
Isso não é uma descrição de cargo. Isso é um desejo. E desejos não sobrevivem ao fim de semana.
Uma descrição de cargo tem cinco partes:
O que ele monitora. O gatilho ou cronograma específico. "Toda segunda às 7h" ou "toda vez que uma nova issue do GitHub for aberta com a label 'bug'" ou "toda vez que um e-mail chegar de um domínio que não está na minha lista de contatos." Não "às vezes" ou "quando relevante."
O que ele lê. As fontes exatas. Não "verifique a internet." "Puxe destes três feeds RSS, desta base do Airtable e dos últimos 7 dias deste canal do Slack." Específico. Delimitado. Sem ambiguidade.
O que ele produz. O formato exato da saída. Não "um resumo." "Um briefing de três seções: descoberta principal em uma frase, três bullets de apoio com uma fonte cada, uma ação recomendada. Menos de 300 palavras. Neste Google Doc."
O que ele não faz. As salvaguardas. "Nunca envie um e-mail externo sem aprovação humana." "Nunca modifique o banco de dados de produção." "Nunca publique diretamente. Sempre salve em rascunhos." As coisas que você assume como óbvias são as que vão te queimar.
Como você sabe que funcionou. A condição de sucesso. "Se o briefing estiver vazio, me envie uma mensagem no Slack dizendo que nenhuma atualização relevante foi encontrada. Não envie um briefing vazio."
Vibes não sobrevivem ao fim de semana. Descrições de cargo, sim.
Todo fluxo de trabalho que você construir a partir de hoje começa com uma descrição de cargo. Não um prompt. Uma descrição de cargo.
Regra 2 — Falha Silenciosa É a Única Falha Que Te Mata
Falhas barulhentas são ok. Falhas barulhentas enviam um erro. Elas param o fluxo de trabalho. Elas te acordam. Você as corrige.
Falhas silenciosas são as que matam negócios.
Uma falha silenciosa parece sucesso. O fluxo de trabalho roda. A saída chega. O formato está correto. O conteúdo está errado — ligeiramente, depois mais, depois completamente — e porque parece certo, ninguém verifica.
Aqui está como a falha silenciosa acontece na prática:
Seu agente de conteúdo escreve 30 posts. Você o configurou para agendar automaticamente os que pontuam acima de 80 na sua rubrica interna. A rubrica foi calibrada nos seus primeiros 20 posts. No dia 15, o modelo começa a interpretar sua rubrica de forma diferente. Posts que pontuam 82 agora são medíocres pelo seu padrão real. Eles vão ao ar mesmo assim. Seu engajamento cai. Você culpa o algoritmo.
Seu agente de pesquisa envia um briefing semanal. No dia 11, uma das fontes que ele estava lendo muda sua estrutura de URL. O agente falha ao buscá-la silenciosamente. Ele preenche a lacuna com dados de cache mais antigos e não sinaliza a lacuna. Você lê um briefing baseado em informações desatualizadas e toma uma decisão com base nele.
Seu agente de triagem de caixa de entrada rascunha respostas. No dia 8, ele começa a categorizar um certo tipo de e-mail como baixa prioridade porque o nome do remetente corresponde a um padrão em seu treinamento. Você perde três e-mails importantes de um novo cliente que, por acaso, compartilha o sobrenome com uma newsletter que você nunca lê.
Em todos os casos: o fluxo de trabalho rodou. Nenhum erro foi lançado. Você perdeu mesmo assim.
A correção é a verificação obrigatória da saída. Todo agente precisa de três coisas:
Uma saída canário. Um campo em cada saída que seja fácil de verificar e difícil de falsificar. Um timestamp da fonte mais recente que leu. Uma contagem de itens que processou. Uma pontuação de confiança. Algo que você possa ver em dois segundos e saber que o agente realmente fez o trabalho.
Um alerta de falha silenciosa. Se o agente não produzir nada, ou produzir algo abaixo de um limite, ele não envia uma saída vazia. Ele te envia um alerta. "Nenhum resultado encontrado neste ciclo — aqui está o que verifiquei e por que posso não ter encontrado nada." Nada é sempre mais útil do que um resultado vazio convincente.
Uma verificação pontual semanal. Escolha uma saída por semana por agente. Leia-a completamente. Compare-a com o que você teria escrito. Isso leva quatro minutos. Pega o desvio antes que o desvio se torne falha.
Agentes não falham alto. Construa para as quebras silenciosas.
Regra 3 — Seu Laptop Não É Infraestrutura
É aqui que 90% dos construtores morrem.
Eles constroem localmente. A demo funciona. Eles lançam o tópico no Twitter. Alguém pergunta se está rodando em produção. Eles dizem que sim. O que querem dizer é: está rodando no MacBook deles, que está aberto, na mesa, no apartamento deles, conectado ao WiFi de casa, e vai parar de funcionar quando fecharem a tampa para ir ao aeroporto na quinta-feira.
Seu laptop não é infraestrutura. É um ambiente de desenvolvimento que, por acaso, está rodando algo importante agora.
Aqui está o que acontece com agentes hospedados em laptops:
O macOS envia uma atualização às 4h. A máquina reinicia. O agente para. Ninguém sabe até segunda-feira.
Você fecha a tampa em um voo. Seis horas de fluxos de trabalho perdidos. O agente de triagem da caixa de entrada não fez a triagem. O caçador de bugs não caçou. O agente de daily não enviou nada.
Seu WiFi de casa cai por vinte minutos. O agente tenta novamente. Falha. Segue em frente. Não registra nada. A janela que ele deveria capturar se foi.
Você sai de férias. O laptop fica em casa. Tudo fica em casa com ele.
Infraestrutura de verdade roda quando você não está olhando. Roda quando você está dormindo, num avião, no jantar, inatingível por um fim de semana. Não precisa de você para manter a tampa aberta.
A regra é simples: se o fluxo de trabalho precisa rodar mais de uma vez e você não pode perder um ciclo, ele não mora no seu laptop.
As três opções de infraestrutura que realmente funcionam:
Um VPS com um gerenciador de processos. Um servidor de $12/mês rodando PM2 ou Supervisor. Seu agente roda como um processo gerenciado. Se cair, o PM2 o reinicia automaticamente. Se o servidor reiniciar, o PM2 o inicia na inicialização. Barato. Confiável. Não é glamoroso. Funciona.
Uma plataforma de agente gerenciada. Feita sob medida para isso. Cuida das reinicializações, do monitoramento, dos alertas. Custa mais que um VPS. Te poupa os fins de semana que você passaria debugando por que o processo morreu. Vale a pena quando seus agentes estão gerando valor real.
Serverless com um agendador. AWS Lambda ou Google Cloud Functions acionados por EventBridge ou Cloud Scheduler. Zero infraestrutura para gerenciar. Você paga por execução. Escala a zero quando não está rodando. Melhor opção para agentes que rodam em um cronograma fixo, em vez de continuamente.
Nenhuma dessas é complicada. Todas exigem quinze minutos de configuração. Cada uma delas vai te salvar da atualização do macOS às 4h que mata seus agentes e sua segunda-feira de manhã.
Feche o laptop. Os agentes devem continuar rodando.
O Fluxo de Trabalho Que Sobrevive
Aqui está a aparência de um fluxo de trabalho de 90 dias quando todas as três regras são aplicadas.
A descrição de cargo:Toda segunda às 7h, leia os últimos 7 dias de posts destas 5 contas de concorrentes e destas 3 newsletters do setor. Extraia quaisquer anúncios de produtos, mudanças de preço ou conteúdo que teve mais de 500 engajamentos. Compare com o briefing da semana passada. Sinalize qualquer novidade. Gere um briefing de três seções: o que mudou, o que está ganhando tração, que lacuna eles deixaram aberta. Se nenhuma mudança for encontrada, envie um alerta: "semana tranquila — aqui está o que foi verificado." Entregue nesta página do Notion e envie uma notificação no Slack.
A saída canário:Todo briefing inclui: "Fontes verificadas: 8. Itens processados: [N]. Timestamp do item mais recente: [timestamp]." Se N for zero ou o timestamp tiver mais de 8 dias, envia um alerta em vez de um briefing.
A infraestrutura:Rodando em um VPS de $12/mês. O PM2 gerencia o processo. Se cair, reinicia em 30 segundos. Uma revisão semanal dos logs leva 3 minutos toda sexta-feira.
A verificação pontual:Toda sexta-feira, um briefing é lido completamente. Leva 4 minutos. Já pegou desvio duas vezes em seis meses.
Esse fluxo de trabalho está rodando há seis meses. Perdeu dois ciclos — em ambos os casos, enviou um alerta explicando o porquê. Nunca falhou silenciosamente.
Essa é a diferença entre um fluxo de trabalho que sobrevive e um que morre no nono dia.
A Verdade Desconfortável
A maioria das pessoas vai ler isso, concordar com a cabeça e construir seu próximo agente da mesma forma que construiu o último.
Um prompt. Uma demo. Um tópico no Twitter. Trinta dias de silêncio. Um fluxo de trabalho morto que ninguém matou oficialmente.
As três regras não são complicadas. Uma descrição de cargo leva vinte minutos para escrever. A verificação da saída leva um campo e um condicional. A infraestrutura leva quinze minutos para configurar.
A lacuna não é conhecimento. A lacuna é se você faz isso antes de lançar ou depois que o fluxo de trabalho falhar.
Cada agente que você construir sem uma descrição de cargo é um agente que você vai reconstruir. Cada agente sem verificação de saída é um agente que vai falhar silenciosamente. Cada agente no seu laptop é um agente que vai morrer na próxima vez que você fechar a tampa.
Construa-os corretamente uma vez. Eles rodam para sempre.
Siga @sairahul1 para mais manuais completos sobre como construir fluxos de trabalho de IA que sobrevivem ao contato com o mundo real.
TL;DR
90% dos fluxos de trabalho de IA morrem em 30 dias. Sempre os mesmos três motivos.
Regra 1 — Sem descrição de cargo, sem agente.Vibes não sobrevivem ao fim de semana. Defina o que ele monitora, lê, produz, evita e como você sabe que funcionou. Antes de escrever um único prompt.
Regra 2 — Falha silenciosa é a única falha que te mata.Falhas barulhentas são ok. Falhas silenciosas parecem sucesso até um cliente encontrá-las. Construa uma saída canário, um alerta de falha silenciosa e uma verificação pontual semanal em cada agente.
Regra 3 — Seu laptop não é infraestrutura.Ele roda quando a tampa está aberta. Agentes de verdade rodam quando você está dormindo, num avião, inatingível por um fim de semana. VPS, plataforma gerenciada ou serverless. Escolha um. Configure antes de lançar.
Os agentes que sobrevivem não são mais inteligentes. Eles são construídos corretamente.
