Seu fluxo de trabalho de IA está rodando agora mesmo.
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 enviando saídas que ninguém está lendo. O agente que você passou dois fins de semana construindo está produzindo lixo a R$ 0,40 por monte de lixo — e você só vai descobrir quando um cliente tirar um print e te enviar numa terça-feira.
Isso não é azar. Esse é o resultado padrão.
Salve isto. Você vai ler duas vezes.
O Cemitério de 30 Dias
Toda semana, centenas de founders constroem fluxos de trabalho de IA e postam no Twitter.
A demo é bonita. O thread 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. Não produzindo nada útil. O founder seguiu em frente. O agente não recebeu o recado.
90% dos fluxos de trabalho de IA construídos hoje não sobrevivem 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 lançarem.
Este é esse artigo.
Por Que Eles Morrem
Aqui está a anatomia de uma morte de 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 resposta de uma API muda ligeiramente. Uma fonte que ele estava lendo fica atrás de um login. O modelo interpreta um caso limítrofe de forma diferente do que no dia um. A saída degrada silenciosamente. Ninguém percebe.
Dia 14: O fluxo de trabalho agora está produzindo algo que é tecnicamente uma resposta, mas substancialmente inútil. 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ída quebrada que você achava que estava sendo tratada.
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 founders cujos fluxos de trabalho sobrevivem 30 dias, 90 dias, um ano — eles não são mais inteligentes. Eles não têm prompts melhores. Eles constroem com três regras que todos os outros ignoram.
Regra 1 — Sem Descrição de Cargo, Sem Agente
A maioria das pessoas constrói agentes com uma vibe.
"Me ajude com conteúdo." "Monitore concorrentes." "Gerencie 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-feira à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 Airtable e dos últimos 7 dias deste canal do Slack." Específico. Limitado. Sem ambiguidade.
O que ele produz. O formato de saída exato. 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 conserta.
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 mais antigos em cache e não sinaliza a falha. Você lê um briefing baseado em informações desatualizadas e toma uma decisão com base nele.
Seu agente de triagem de inbox 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 gerado. Você perdeu mesmo assim.
A solução é a verificação obrigatória de 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 olhar 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 ele se torne falha.
Agentes não falham alto. Construa para as quebras silenciosas.
Regra 3 — Seu Notebook Não É Infraestrutura
É aqui que 90% dos construtores morrem.
Eles constroem localmente. A demo funciona. Eles publicam o thread no Twitter. Alguém pergunta se está rodando em produção. Eles dizem que sim. O que eles 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 eles fecharem a tampa para ir ao aeroporto na quinta-feira.
Seu notebook não é infraestrutura. É um ambiente de desenvolvimento que por acaso está rodando algo importante agora.
Aqui está o que acontece com agentes hospedados em notebook:
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 num voo. Seis horas de fluxos de trabalho perdidos. O agente de triagem de inbox 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 notebook fica em casa. Tudo fica em casa com ele.
Infraestrutura de verdade roda quando você não está olhando. Ela roda quando você está dormindo, num avião, no jantar, inatingível por um fim de semana. Ela não precisa que você mantenha a tampa aberta.
A regra é simples: se o fluxo de trabalho precisa rodar mais de uma vez e você não pode pagar para que ele perca um ciclo, ele não vive no seu notebook.
As três opções de infraestrutura que realmente funcionam:
Um VPS com um gerenciador de processos. Um servidor de R$ 60/mês rodando PM2 ou Supervisor. Seu agente roda como um processo gerenciado. Se ele cair, o PM2 o reinicia automaticamente. Se o servidor reiniciar, o PM2 o inicia na inicialização. Barato. Confiável. Não é glamouroso. Funciona.
Uma plataforma de agentes gerenciada. Construída para isso. Cuida das reinicializações, do monitoramento, dos alertas. Custa mais que um VPS. Te salva dos fins de semana que você passaria debugando por que o processo morreu. Vale a pena assim que seus agentes estiverem 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 para 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 notebook. 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-feira à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 tenha performado acima de 500 engajamentos. Compare com o briefing da semana passada. Sinalize qualquer novidade. Produza um briefing de três seções: o que mudou, o que está ganhando tração, qual lacuna eles deixaram em aberto. 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, ele envia um alerta em vez de um briefing.
A infraestrutura:Rodando em um VPS de R$ 60/mês. O PM2 gerencia o processo. Se ele cair, reinicia em 30 segundos. Uma revisão semanal de 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. Ele perdeu dois ciclos — em ambas as vezes 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 thread 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 de 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 notebook é 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 guias completos sobre como construir fluxos de trabalho de IA que sobrevivem ao contato com o mundo real.
Resumo
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 notebook não é infraestrutura.Ele roda enquanto 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.
