Paralelizar Agentes

Disparar vários agentes ao mesmo tempo e seguir trabalhando enquanto eles rodam; conferir como terminaram com o Aguardar Agentes (opcional); e o segundo nível de paralelismo: uma execução por item de uma lista.

Em resumo

• Paralelizar Agentes dispara até seis agentes de uma vez, cada um com os seus próprios parâmetros de entrada, comportamento a cada disparo e retorno. O fluxo só segue quando todos os que ele espera terminam; os disparados em Não esperar rodam por conta própria, não seguram ninguém e não exigem nada depois.
• Os agentes da lista rodam em paralelo entre si e com o fluxo do agente principal. A etapa Aguardar Agentes é opcional e independente: funciona com disparos de um Paralelizar Agentes ou de um Chamar Agente em Não esperar. Num ponto do fluxo, espera as execuções escolhidas terminarem e informa como terminaram, sem interromper o fluxo até ali.
• Disparar por cada item de uma lista é o segundo nível de paralelismo: qualquer agente da etapa (e também uma etapa Chamar Agente sozinha) se multiplica por uma lista, uma execução por item, todas ao mesmo tempo. Os dois níveis se somam: três agentes, um deles sobre uma lista de duzentos itens, são duzentas e duas execuções saindo de uma única etapa. Uma execução que falha não interrompe as outras: a lista roda até o fim e só então a etapa falha, dizendo quais itens.
• Paralelizar Agentes existe a partir do plano Professional. No Free a etapa aparece travada no +, com o motivo; Chamar Agente, inclusive com Disparar por cada item de uma lista, e Aguardar Agentes existem, e o runtime roda uma execução por vez. Detalhes: Planos.
• Num runtime com Enfileirar Jobs, as execuções disparadas por um agente entram na fila e no teto da máquina como as outras, na frente das execuções de sempre, e o chamador que espera por elas solta a vaga dele enquanto isso. Limitar quantas saem da lista de uma vez (seção Modo de enfileiramento do disparo): Enfileirar Agentes. Repartir entre máquinas (seção Distribuição do processamento): Balancear Carga dos Agentes.
• Parâmetros de entrada, comportamento a cada disparo, retorno e dado sensível funcionam em cada agente como na etapa Chamar Agente. Detalhes: Subprocesso de Agentes. Esta página descreve o que muda quando são vários.

Para que serve: especialistas em paralelo

Pense num agente que fecha pedidos. Antes de confirmar cada pedido ele precisa de três respostas que vêm de sistemas diferentes: o limite de crédito do cliente, no ERP; a disponibilidade em estoque, no sistema do armazém; e a validação do endereço de entrega, no portal da transportadora. Cada consulta é um agente especialista, com dono, versão, testes e Gestão de Erros próprios, e cada uma leva o seu tempo: trinta segundos aqui, um minuto ali.

Chamados um atrás do outro, os três somam o tempo deles, e o fechamento do pedido fica parado esperando. Com Paralelizar Agentes, os três saem juntos, e o tempo total é o do mais lento. E o agente principal não precisa ficar parado: enquanto os especialistas rodam, ele calcula os totais, aplica a tabela de preços e monta o resumo do pedido, etapas que não dependem de nenhuma das três respostas. Só na hora de decidir se o pedido é aprovado é que ele precisa das três respostas. Ali, ele pode ler as variáveis de retorno direto (o status de cada uma diz se ela já terminou) ou, para ter certeza de que as três terminaram antes de decidir, pôr um Aguardar Agentes.

Há mais de um jeito de montar isso, e a escolha é o Comportamento a cada disparo de cada agente:

• Todos em Esperar finalizar. A própria etapa segura o fluxo até o último terminar, e as variáveis de retorno já estão prontas na etapa seguinte. Indicado quando o agente principal não tem outra coisa a fazer enquanto espera.
• Todos em Não esperar, lendo as variáveis mais à frente. A etapa dispara e o fluxo segue na hora. No ponto em que precisa de uma resposta, uma Decisão de Rota lê o status daquele agente: FINALIZED, ERROR, ou RUNNING se ele ainda não terminou. O fluxo principal não para.
• Todos em Não esperar, mais um Aguardar Agentes. Igual ao anterior, com um Aguardar Agentes no ponto em que todos precisam ter terminado: ele espera o que faltar (com teto, se configurado) e informa quantos terminaram bem, quantos falharam e quais ainda rodavam.
• Misturado. O que é rápido e indispensável espera; o que é lento, ou só um aviso, dispara e segue. Cada agente da lista tem a sua própria espera.

O mesmo raciocínio vale quando as competências são iguais e o que muda é o volume: cinquenta notas para emitir não precisam ir uma atrás da outra. Nesse caso o paralelismo não é entre agentes diferentes, e sim do mesmo agente sobre uma lista, o segundo nível.

Como se cria

1. Publique os agentes que serão chamados. Só a versão publicada pode ser chamada. Um agente ainda em desenvolvimento aparece na lista, mas desabilitado, com o motivo.
2. No fluxo do pai, clique no + (no fim do fluxo, ou no + de uma seta para inserir no meio) e, no grupo Orquestração de Agentes, escolha Paralelizar Agentes.
3. Abra a etapa e adicione os agentes, um a um, com + Adicionar agente. A lista traz os agentes do dono deste processo e os compartilhados com ele com permissão de executar. Um agente não pode chamar a si mesmo. Arrastar um agente do painel Agentes para o card da etapa também o acrescenta (No fluxo visual).
4. Opcional: um Aguardar Agentes. Para esperar, num ponto do fluxo, os disparos em Não esperar, crie a etapa naquele ponto, pelo mesmo menu. Sem ela, as variáveis de retorno chegam sozinhas, em segundo plano.

As duas etapas nascem como etapas de Execução com a ação já definida e não trocam de tipo depois. Elas não têm nome próprio: aparecem no fluxo, no log e nos seletores de variáveis como Paralelizar Agentes 1, 2, 3 e Aguardar Agentes 1, 2, na ordem em que estão no fluxo. A opção Clonar do menu não lista as etapas de agentes: elas se criam de novo, escolhendo os agentes.

No fluxo visual

• O card de Paralelizar Agentes é um losango alongado com a marca + e o título no centro: diferente do losango com X da Decisão de Rota, em que só um caminho é percorrido, aqui todos rodam. Dentro dele fica um avatar por agente, cada um com o anel na cor da sua rota (A a F), o nick do agente e, embaixo, menor, o nome do processo. Passar o mouse em cada um abre o resumo daquele agente: processo, descrição, o que recebe, o que devolve e como o pai espera.
• O card de Aguardar Agentes tem o mesmo layout, com os lados côncavos por onde as setas convergem e a bandeira de chegada no canto: mostra o avatar e o nome de quem está sendo aguardado (até seis; acima disso, empilhados) e o teto, quando há.
• Arrastar um agente do painel Agentes (menu superior) para dentro do card do Paralelizar Agentes o acrescenta, até seis: o card acende em âmbar, um trilho tracejado corre por baixo dos agentes e aparece a vaga do agente novo. O Aguardar Agentes não recebe agente, e o card fica vermelho. Um conector solto em qualquer das duas etapas é recusado. Detalhes do painel: Subprocesso de Agentes → O painel Agentes.
• Os dois cards só têm o botão Configurar: não existem Objetos nem Mapeamentos nessas etapas.
• No debug, enquanto a etapa espera, o card mostra quantas execuções já voltaram (por exemplo 2/3), e no Aguardar Agentes também quanto falta do teto. No Paralelizar Agentes, um trilho tracejado corre em verde por baixo dos agentes enquanto a etapa roda e some quando ela termina ou a execução para.
• Clicar no avatar de um agente leva ao editor dele, na mesma janela, com a volta ao chamador na faixa de contexto do alto da tela.
• Etapa incompleta (agente sem escolher, retorno sem variável, agente que sumiu ou ainda não publicado, Aguardar Agentes sem Prefixo Identificador desta Etapa, com "só estas" sem etapa marcada, sem nenhum disparo em Não esperar antes dele, ou com um agente escolhido que não existe mais antes dele, disparo em lotes com Não esperar sem um Aguardar Agentes mais à frente que o aguarde) entra na lista de pendências e impede a publicação, como um script com erro.

Como se configura

No painel da etapa, + Adicionar agente abre a lista, e cada agente escolhido vira um bloco com a letra da rota (A a F), o avatar, o nick do agente e, embaixo, o nome do processo dele e um resumo do comportamento a cada disparo. O bloco recolhe e expande pelo cabeçalho, o ícone de setas troca o agente daquele bloco mantendo o que já foi configurado nele, e o ícone de lixeira o remove. O mesmo agente pode entrar mais de uma vez, cada vez com os seus próprios parâmetros de entrada, comportamento a cada disparo e retorno; para muitas execuções iguais a partir de uma lista, use o disparo por item, abaixo.

Dentro de cada bloco estão as mesmas seções da etapa Chamar Agente, com o mesmo comportamento:

• Parâmetros de entrada do agente chamado: o valor no pai para cada parâmetro do agente. Ver Subprocesso de Agentes → Como se configura.
• Comportamento a cada disparo: o centro do mecanismo. Cada agente da lista tem a sua, Não esperar, Esperar finalizar, Esperar até um prazo ou Esperar a resposta antecipada, e é a combinação delas que desenha o paralelismo, como no caso do começo da página. Detalhes dos quatro modos e de qual usar: Subprocesso de Agentes → A espera: o mecanismo central.
• Retorno do agente chamado: variável do agente, corpo do Webhook Response, status, mensagem de erro, etapa em que falhou. Ver Retorno do agente chamado e O que volta ao pai. Em Não esperar, o retorno chega em segundo plano.
• Disparar por cada item de uma lista: o segundo nível, na seção seguinte.
• Distribuição do processamento: sempre presente no Paralelizar, porque a etapa dispara mais de uma execução. Ver Balancear Carga dos Agentes.

O fluxo do pai só segue quando todos os agentes que ele espera terminarem. Um agente da lista falhou? A etapa falha, e o log do pai diz qual. Os outros continuam até o fim, a menos que o pai seja parado. No log, cada agente aparece pelo nome dado com o avatar, seguido do nome do processo que ele executa entre parênteses.

Onde se altera depois

Sempre no painel da etapa do pai, bloco por bloco. O nick, o nome do processo, o avatar e a descrição vêm do cadastro de cada agente chamado, e os parâmetros também: um parâmetro criado pelo dono do agente aparece nos Parâmetros de entrada do bloco na próxima vez que você abrir a etapa.

O segundo nível: Disparar por cada item de uma lista

O primeiro nível de paralelismo é a lista de agentes do Paralelizar: agentes diferentes, lado a lado. O segundo nível é a seção Disparar por cada item de uma lista, que existe em cada bloco do Paralelizar e também na etapa Chamar Agente: o mesmo agente, multiplicado por uma lista, uma execução por item, todas disparadas ao mesmo tempo. Os dois níveis se somam. Um Paralelizar com três agentes, em que um deles dispara por uma lista de duzentos pedidos, tira duzentas e duas execuções de uma única etapa. Os tetos são seis agentes por etapa, cinco mil itens por lista e cinco mil execuções por etapa, somando tudo.

Ligue a chave e informe a lista. O campo aceita três formas:

Uma variável de tipo declarado que nunca é lista (Moeda, Número, Verdadeiro/Falso, Secreto e as contagens do Aguardar Agentes) aparece no menu travada, com o motivo. Escrita à mão no campo, o painel avisa, o salvar recusa, o card vira pendência e, na execução, a etapa falha antes de disparar. Com isso, uma Moeda de 1.234,90 não vira duas execuções, "1.234" e "90".

São dois lugares, com papéis diferentes: na seção fica a lista; nos Parâmetros de entrada do agente chamado, cada parâmetro diz o que recebe em cada execução:

• O item da vez, inteiro: o item como ele é, um número, um texto ou um objeto.
• Um campo do item da vez: quando o item é um objeto, como cnpj numa lista de {cnpj, nome}. Aceita caminho, como endereco.cep. O que acontece quando o item não traz o campo está em Quando o item não traz o valor.
• Não vem da lista: valor fixo ou variável: um texto ou uma variável do pai, igual em todas as execuções. Um parâmetro do agente que não muda de um item para outro.
• Não enviar nada (o padrão de um parâmetro que você não preencheu): o parâmetro fica fora do envio e o agente chamado usa o valor padrão dele. É diferente de enviar vazio, que sobrescreve o padrão com um texto em branco.

Nos bastidores as duas primeiras viram {item} e {item.campo}. O erro mais comum é pôr a lista inteira também nos Parâmetros de entrada: o painel avisa na hora, com o nome dos parâmetros que precisam receber o item em vez da lista.

Quando o item não traz o valor

Nos parâmetros que recebem o item da vez, inteiro ou um campo do item da vez, o painel mostra Se vier vazio ou faltar no item. Vale para o valor em branco, nulo, ou o campo que não existe naquele item:

Nas três opções, o log do agente principal diz, por parâmetro, em quantos e em quais itens o valor faltou e o que foi feito, só com a posição dos itens, sem o valor.

Quando nenhum item tem o campo pedido e está claro que é engano, a etapa falha antes de disparar qualquer execução, e nada é cobrado. Isso acontece em dois casos: os itens da lista não são registros (objetos com campos), ou existe nos itens um campo de grafia parecida, como cnpj para CNPJ ou cpnj, e razao_social para RazaoSocial. A mensagem diz o campo que existe. Um campo que falta em todos os itens, sem nenhum parecido, segue a opção escolhida acima, como qualquer valor vazio.

Exemplo: uma lista de empresas, com um campo de cada empresa em cada parâmetro

O agente principal recebe, pela API, a Matrix empresas, do tipo Lista, com uma empresa por item. Cada item é um objeto, e a terceira empresa não tem endereço:

[
  { "cnpj": "12.345.678/0001-90", "razao": "ACME Ltda", "endereco": { "cidade": "São Paulo", "uf": "SP" } },
  { "cnpj": "98.765.432/0001-10", "razao": "Beta S.A.", "endereco": { "cidade": "Recife", "uf": "PE" } },
  { "cnpj": "11.222.333/0001-44", "razao": "Gama ME" }
]

A etapa Chamar Agente chama o agente Consulta CNPJ com Disparar por cada item de uma lista ligado e a lista {matrix.empresas}. Nos Parâmetros de entrada do agente chamado, cada parâmetro escolhe o que recebe:

São três execuções, uma por empresa, e cada uma recebe:

A Gama ME não tem endereco, então uf chega vazio na terceira execução, e o log do agente principal diz que o parâmetro uf ficou sem valor no item 3. Com Usar o valor padrão do parâmetro no agente, a terceira execução sai sem uf e o agente usa o valor padrão dele; com Não disparar a execução deste item, saem só as duas primeiras, o terceiro registro fica ERROR e a etapa falha no fim, depois de as duas terminarem. O nome do campo é escrito como está no item, com as mesmas maiúsculas e minúsculas, e o ponto separa os níveis. Com o retorno Variável do agente situacao_cadastral gravado no registro como situacao, e consultas em Armazenar cada retorno em uma lista, o primeiro registro de {consultas} fica assim (o registro é explicado a seguir):

{
  "indice": 1,
  "item": { "cnpj": "12.345.678/0001-90", "razao": "ACME Ltda", "endereco": { "cidade": "São Paulo", "uf": "SP" } },
  "entrada": {
    "cnpj": "12.345.678/0001-90",
    "uf": "SP",
    "empresa": { "cnpj": "12.345.678/0001-90", "razao": "ACME Ltda", "endereco": { "cidade": "São Paulo", "uf": "SP" } },
    "canal": "portal"
  },
  "status": "FINALIZED",
  "erro": "",
  "etapa": "",
  "situacao": "ATIVA"
}

observacao fica fora de entrada porque não foi enviado. No terceiro registro, entrada.uf é "".

O retorno vira uma lista de registros

Com o disparo por item, em vez de uma variável por linha você informa, em Armazenar cada retorno em uma lista, uma variável do pai que recebe a lista de resultados, com um registro por execução, na ordem dos itens. Cada registro traz indice, item (o item da lista), entrada (o que foi enviado, parâmetro por parâmetro; o que não foi enviado não aparece), status, erro, etapa (a etapa do agente em que falhou) e os campos que você pedir: variáveis do agente ou o corpo do Webhook Response, cada um com o nome que você der dentro do registro. Nada é sobrescrito de uma execução para outra: a que deu certo traz os dados, a que falhou traz o erro e onde parou, e as duas trazem o que foi enviado. A lista se percorre com um Loop. Uma execução que falhou não interrompe as outras: todas as execuções da lista rodam até o fim, e só então a etapa falha, com o item identificado no log. Com a lista saindo uma quantidade específica por vez, a falha de uma execução também não para a lista.

Em Não esperar, a lista de resultados nasce com um registro RUNNING por item, e cada registro é trocado quando a execução dele termina, em segundo plano. Lista vazia é erro: nada é disparado e a etapa falha, entrando na Gestão de Erros. A variável da lista que nenhuma etapa gravou também, com a mensagem de que ela não existe nesta execução. Quase sempre a lista vazia é a etapa anterior que não gravou nada, e seguir em silêncio só empurraria o problema para a frente. No Paralelizar, uma lista vazia em qualquer agente impede o disparo de todos.

Cada item é uma execução e custa 1 crédito. Antes de disparar o sistema confere o saldo para a etapa inteira: se ele não cobrir todos os itens de todos os agentes, nenhum é disparado. Como todas as execuções saem ao mesmo tempo, a seção Distribuição do processamento reparte o lote entre máquinas. Detalhes: Balancear Carga dos Agentes.

Runtime em modo fila: como o agente chamado entra na conta

Um Ambiente Runtime com Enfileirar Jobs ligado tem um teto de execuções ao mesmo tempo (o campo Execuções ao mesmo tempo do cadastro; 1 é uma por vez, em ordem). Uma execução disparada por outro agente, seja pelo Chamar Agente, pelo Paralelizar ou pelo disparo por item, entra nessa conta e nessa fila como qualquer outra, com duas regras próprias:

• Ela passa na frente. Na fila, o agente chamado entra antes das execuções de sempre (API, agendamento, webhook, Control Room, execução manual) que estavam esperando. Ele é parte de um trabalho que já está de pé, e terminar o que está de pé libera a máquina mais cedo.
• Quem espera por ele não ocupa vaga. O agente que chamou, enquanto espera o retorno (nesta etapa, ou num Aguardar Agentes), solta a vaga dele e a pede de volta quando o retorno chega, com prioridade sobre tudo que espera na fila. Sem isso, um teto de 1 seria um impasse: o chamador ocupando a única vaga e o chamado esperando atrás dele para sempre. O navegador do chamador continua aberto nesse meio-tempo.

O que isso significa na prática:

• O teto vale para o lote. Uma lista de duzentos itens numa máquina com teto 3 abre três execuções de cada vez; as outras esperam a vez na fila, e o log do chamador diz "iniciada" quando o Router entregou cada uma ao runtime, mesmo que ela ainda esteja esperando vaga lá. Escolher quantas saem da lista de uma vez, independentemente da máquina (seção Modo de enfileiramento do disparo): Enfileirar Agentes. Repartir entre máquinas: Balancear Carga dos Agentes.
• O agente chamado também tem o teto dele. As configurações do agente (Execuções ao mesmo tempo) limitam quantas execuções daquele agente ficam de pé numa máquina, venham de onde vierem. Uma que não cabe espera na fila sem tomar a vez dos outros agentes.
• Anular fila por exceção vale só para as execuções de sempre: um agente chamado que falha não cancela a fila do runtime, e uma execução de sempre que falha não cancela agente chamado.
• Runtime desligado. Sem Manter fluxo offline no ambiente do agente chamado, o disparo é recusado na hora e a etapa falha. Com ela ligada, as execuções ficam guardadas no ambiente até o runtime voltar, e quando ele volta entram na fila dele como as outras. Um chamador que espera sem prazo espera até o runtime voltar e a execução terminar, ou até a plataforma desistir dela (30 minutos sem o runtime, em Quando o runtime do agente chamado sai do ar); com prazo, espera até o prazo. O log do chamador diz quantas execuções ficaram nessa situação.
• Plano Free. O runtime é sempre em fila, uma por vez, e as regras acima valem do mesmo jeito: um Chamar Agente funciona mesmo com teto 1, porque o chamador solta a vaga enquanto espera. Paralelizar Agentes não existe no plano Free (veja Planos); Chamar Agente e Aguardar Agentes existem, e funcionam mesmo com teto 1.

Aguardar Agentes: o ponto de encontro

A etapa Aguardar Agentes é opcional. Ela espera as execuções disparadas em Não esperar, venham de um Paralelizar Agentes ou de um Chamar Agente, e serve a dois usos: garantir que as execuções escolhidas terminaram antes de um ponto do fluxo, e conferir como terminaram, num lugar só. Sem ela, as execuções rodam do mesmo jeito e o retorno pedido chega em segundo plano.

No ponto em que está, ela para o fluxo até as execuções escolhidas terminarem, ou até um teto, e então segue. Só espera o que foi disparado antes dela no fluxo. Um fluxo pode ter Paralelizar sem Aguardar, Aguardar sem Paralelizar (com disparos de etapas Chamar Agente em Não esperar), ou os dois. Com uma etapa Chamar Agente sozinha: Subprocesso de Agentes → Aguardar Agentes com uma chamada só.

No painel:

• O que aguardar: todos os agentes disparados sem esperar antes desta etapa, ou só alguns, agente a agente (uma entrada do Paralelizar pode ser escolhida sozinha). Cada agente listado mostra as variáveis que o disparo dele grava: é ali que fica o desfecho individual. Um agente sem retorno mapeado no disparo é avisado: você saberá que terminou, mas não como. Um agente escolhido cuja etapa foi apagada, movida para depois do Aguardar ou deixou de ser Não esperar sai da escolha ao salvar a etapa; até lá, o Aguardar fica na lista de pendências.
• Teto de espera: sem teto, a etapa espera até a última execução terminar, e a plataforma garante que essa espera acabe mesmo que o runtime de um dos agentes saia do ar (veja Quando o runtime do agente chamado sai do ar); e, para uma execução que segue viva sem terminar, a espera sem teto desiste em 24 horas, com o status TIMEOUT. Com teto, em segundos, até 24 horas, ela sai quando a última terminar ou quando o teto acabar, o que vier primeiro.
• Se o teto estourar: seguir o fluxo (as execuções continuam rodando e as variáveis delas chegam depois) ou falhar a etapa, que então entra na Gestão de Erros.
• Se algum aguardado terminar com falha: seguir o fluxo (e decidir depois pelas variáveis de cada agente) ou falhar a etapa, com a mensagem dizendo quem falhou, o status, o erro e a etapa do agente chamado.
• Prefixo Identificador desta Etapa, obrigatório e sempre em caixa baixa (letras, números e _): identifica a etapa nas variáveis que ela grava, descritas a seguir. Com duas esperas no mesmo fluxo, cada uma tem o seu prefixo e as suas variáveis.

Por conta própria, o Aguardar não leva nada ao chamador: um disparo sem esperar não falha a etapa que o disparou, e o Aguardar só espera. O que aconteceu em cada agente (terminou bem, falhou, em que etapa, com que erro, e os dados que ele devolveu) está nas variáveis mapeadas no disparo dele, uma a uma; com o disparo por item, na lista de registros. É por elas que o fluxo decide depois do ponto de encontro, e a etapa só falha se você escolher isso no teto ou na falha.

As variáveis da espera

A etapa grava uma família de variáveis com o prefixo que você deu, no padrão agentWaiter.<prefixo>.<campo>, do mesmo jeito que matrix. e connector.. Elas aparecem nos seletores de variável do fluxo assim que você sai do campo Prefixo Identificador desta Etapa, sem precisar salvar antes, com a marca de lista onde cabe, e servem para decidir logo depois do ponto de encontro. Para o prefixo fin:

Cada registro das três listas tem a mesma forma: agent (o nome do agente), step (a etapa que o disparou), item (o número do item, no disparo por item; vazio fora dele), status, error, failedAt (a etapa do agente chamado em que falhou) e vars, o retrato das variáveis que o disparo daquele agente mapeou, já com os valores que chegaram. Com o disparo por item, vars traz o registro daquela execução dentro da lista de resultados, não a lista inteira.

Três cenários, com dois agentes aguardados, Consulta CNPJ e Emitir NF:

Na prática: uma Decisão de Rota logo depois compara {agentWaiter.fin.status} com FINALIZED para seguir o caminho feliz, ou {agentWaiter.fin.failed} maior que zero para desviar ao tratamento; uma Regra Customizada percorre {agentWaiter.fin.errors} e monta o aviso com agent, error e failedAt de cada um. A etapa nunca falha por conta própria: enquanto nenhuma das duas escolhas "Falhar a etapa" está marcada, o painel nem mostra a Gestão de Erros, porque não haveria o que tratar.

"Terminou" é o retorno da execução chegar ao pai. Por isso, quando há um Aguardar Agentes no fluxo, todo disparo em Não esperar fica acompanhado, mesmo sem retorno pedido. Um disparo que já terminou quando a etapa começa conta do mesmo jeito: entra em total e na lista que lhe cabe, e a etapa segue na hora se não sobrou ninguém rodando. Se nenhum disparo aconteceu antes da etapa (um caminho do fluxo que contorna a chamada, por exemplo), ela avisa no log, grava total zero e o fluxo segue. Duas esperas no mesmo fluxo precisam de prefixos diferentes; o painel recusa o prefixo repetido. Ao sair da etapa, as variáveis mapeadas nos disparos (status, erro, etapa, dados) já estão preenchidas para o que terminou. A etapa vira pendência se ficar sem o Prefixo Identificador desta Etapa ou se "só estas" ficar sem etapa marcada. Parar o pai enquanto ela espera solta a espera; as execuções disparadas seguem sozinhas. O log, no terminal de debug e no log oficial, diz quem estava sendo aguardado e com que teto, como cada um terminou, e quais variáveis a etapa gravou, com o status e as contagens.

Planos

Paralelizar Agentes existe a partir do plano Professional, o plano com paralelismo. Nos planos sem paralelismo a opção aparece travada no + do fluxo, com o motivo e o convite ao upgrade; um fluxo que já tem a etapa (importado, ou de quando o plano comportava) mostra a etapa como pendência, não publica, e a execução é recusada com a mensagem do plano. As outras duas etapas do grupo existem em todos os planos: Chamar Agente funciona numa máquina de teto 1 porque o chamador solta a vaga enquanto espera, e Aguardar Agentes não depende de plano.

Limites, créditos e ciclo de vida

• Créditos. Cada execução consome 1 crédito da empresa, além do crédito do pai. O saldo é conferido antes do disparo para a etapa inteira: se não cobrir, nada é disparado e a etapa falha dizendo quantos faltam.
• Parar e pausar. Parar o pai enquanto ele espera para também o que ele está esperando. Pausar pausa, retomar retoma. Execuções disparadas em Não esperar não são alcançadas por nada disso, e parar o pai durante um Aguardar Agentes só solta a espera.
• Debug. No ▶ do pai as chamadas são reais: os agentes rodam em produção, cobrados. Para não chamar de verdade num teste, fixe a saída da etapa (📌) com valores de exemplo, ou ignore a etapa (🚫).
• Sandbox, runtime antigo, compartilhamento, exportação. Valem as mesmas regras da etapa Chamar Agente. Detalhes: Subprocesso de Agentes → Ciclo de vida. A etapa Aguardar Agentes não depende de nada fora do fluxo e vai na exportação sem ajuste.

Quando algo dá errado

Situações de uma chamada (agente que falhou, prazo, dado sensível, runtime do pai que reiniciou): Subprocesso de Agentes → Quando algo dá errado. Abaixo, o que é próprio de vários agentes e de várias execuções:

Tudo isso fica no log do pai: "Paralelizando agentes", quantas execuções cada agente iniciou e em que runtime, "Aguardando", quem terminou como, e o que foi recebido e retido. Os valores em si não aparecem no log.