Execução da esteira: caminho, erro e recuperação

Como o caminho é escolhido

Quando uma etapa termina e escolhe um final, saem dela as conexões daquele final — mais as que valem sempre, se houver. Se nenhum final bateu com uma conexão, vale o caminho padrão.

O que roda ao mesmo tempo

Duas ou mais conexões saindo do mesmo final fazem as etapas rodarem em paralelo, cada uma no seu próprio trabalho.

E há ponto de encontro: uma etapa que recebe várias entradas só começa quando todas estiverem resolvidas, e pelo menos uma tiver de fato acontecido. Se todos os caminhos que levavam até ela foram descartados, ela não roda — e isso segue adiante, para o que vinha depois dela.

Repetir uma etapa

Uma conexão que aponta para uma etapa que já rodou faz ela rodar de novo, e a repetição reusa a mesma conversa: o agente lembra do que já tinha feito.

Desenhar a volta não basta. O limite de repetições começa em um, então uma volta no mapa sem aumentar esse número derruba a execução na primeira vez que ela tentar repetir. O editor avisa, e a etapa aparece marcada como "volta, mas só roda uma vez" — em vez de prometer o que falharia no primeiro disparo.

Quando a esteira termina

Termina com sucesso quando não há mais nada rodando nem agendado. Termina com falha na primeira etapa que falha sem ter para onde ir.

Vale como regra de modelagem: erro de negócio deve ser um final, não uma falha. Um teste que reprovou não é a esteira quebrando — é um desfecho previsto, e o caminho dele faz parte do desenho.

Falha como caminho, e não como fim

Falhar é o agente quebrar, o ambiente morrer, o tempo estourar, ou a etapa terminar sem escolher um final. Sem tratamento, qualquer uma delas derruba a execução inteira e cancela em cascata o que estava rodando junto.

Ligando uma saída de erro na etapa, a falha vira caminho: o fluxo continua por ali, e o resto do mapa segue valendo. A etapa continua marcada como falhada no histórico — a execução termina com sucesso e a tela diz que houve falha tratada, em vez de esconder.

• A etapa que trata o erro recebe o motivo da falha e pode agir sobre ele.
• Saída de erro apontando para a própria etapa significa tentar de novo — e aí o limite de repetições precisa ser pelo menos dois, porque a tentativa que falhou também conta.
• Só a etapa que tem saída de erro é poupada. Falha em outra continua derrubando a execução.

Uma execução nunca é dada como concluída pela metade

Havia um caso em que um ponto de encontro esperava para sempre por um caminho que nunca chegaria, e a execução era selada como concluída com a etapa nunca executada — aconteceu em 44 de 50 execuções antes da correção.

Hoje existe uma rede de segurança: a esteira nunca marca sucesso deixando etapa abandonada para trás.

Etapas continuam o trabalho umas das outras (29/08/2026)

Uma esteira encadeia etapas que dependem do que a anterior deixou pronto — a que revisa um código precisa do que a que implementa acabou de clonar e mudar. Sem tratamento especial, cada etapa rodaria no computador da conversa dela, e a segunda reclonaria do zero o que a primeira já tinha.

Existe um escopo de ambiente próprio para isso, preso à execução da esteira — não à conversa nem ao agente. Ele é ligado na definição da esteira, e ainda não tem controle no editor. Com ele ligado, etapas da mesma execução que caem no mesmo agente dividem o mesmo computador: repositório já clonado, navegador já aberto. É o mesmo efeito do ambiente compartilhado entre as conversas de um agente, mas valendo por execução em vez de valer para o agente inteiro.

Quando as duas coisas estão ligadas, a da execução vence: uma esteira nunca altera a bancada permanente de um agente em proveito de uma execução só.

O limite é assumido, não escondido: ramificar a esteira em etapas paralelas com ambiente compartilhado é recusado. Duas etapas ao mesmo tempo, mexendo no mesmo repositório e no mesmo diretório, corromperiam o trabalho uma da outra — pior do que clonar de novo. A esteira bloqueia esse desenho antes de rodar, em vez de deixar quebrar no meio.

O repositório que cada etapa usa também pode vir do disparo, e não da configuração do agente. As duas capacidades — repositório por execução e ambiente por execução — nasceram juntas, pela mesma razão: um agente que executa esteiras atende pedidos diferentes a cada disparo, e configuração fixa serve mal a esse padrão.

Recuperação de execução travada

Uma rotina roda a cada minuto e cuida de quatro casos: a conversa de uma etapa morreu, uma etapa passou do tempo, a execução ficou sem nada vivo, ou a execução inteira passou do tempo máximo.

Uma correção de 19/08/2026 vale saber, porque mudou o que a tela mostra: execução que estoura o tempo total agora termina falhada, com o motivo registrado. Antes ela terminava marcada como "Cancelada", com o erro em branco — o que escondia que o motivo real tinha sido o tempo.