O que é de fato um fluxo de trabalho aqui
A maioria das ferramentas de «fluxo de trabalho» no espaço de IA é encadeamento de prompts com uma camada fina em cima. O construtor do ToRun é um grafo acíclico dirigido (DAG) de etapas tipadas: você liga invocações de modelo, chamadas de ferramentas, ramificações condicionais, laços e subfluxos em um grafo, e o motor os executa em ordem de dependência, em paralelo onde o grafo permite.
Cada etapa é uma entidade de primeira classe com sua própria configuração: tipo de etapa (chamada de LLM, busca na web, execução de código, geração de imagem, recuperação, transformação etc.), esquema de entrada, política de erro (falhar rápido, repetir com espera, cair em uma alternativa), teto de orçamento de execução por etapa e tempo limite.
O roteamento de modelo dentro de cada etapa de LLM passa pelo mesmo pipeline de capacidades de todo o resto no ToRun. Você declara o que precisa — saída estruturada, visão, uso de ferramentas, raciocínio, uma janela de contexto de pelo menos N tokens — e o executor resolve o modelo que melhor corresponde entre os fornecedores disponíveis naquele momento. Se o seu fornecedor preferido devolver um 5xx, a cadeia de fallback assume automaticamente.
Executores com qualidade em primeiro lugar e o que isso muda na prática
Quando você roda um fluxo, o executor escolhe deliberadamente modelos de nível de qualidade em vez da opção mais barata. Duas razões: automações produzem artefatos (relatórios, conteúdo gerado, código) que ninguém revisa na hora, então falhas de qualidade se acumulam em silêncio; e em volume moderado a diferença de custo é menor do que o preço de uma saída ruim que obriga a rodar de novo ou corrigir na mão.
Na prática isso significa que um fluxo de «resumir pesquisa e redigir um relatório» vai preferir um modelo de raciocínio sólido para o resumo e um modelo de texto de alta qualidade para a redação, em vez de correr para o piso de preço. Você pode sobrescrever por etapa se souber que ali basta um modelo leve.
A cobrança segue o resto do ToRun: cada invocação de modelo dentro de um fluxo grava exatamente um registro com um instantâneo de tarifa congelado. Uma execução que chama três modelos diferentes em cinco etapas produz cinco registros. Você pode auditar o custo exato de cada execução, detalhado por etapa, depois do fato — mesmo meses depois, quando os preços do fornecedor já tiverem se mexido.
Depurar uma execução
Cada execução de fluxo produz um rastreamento estruturado. O rastreamento mostra o DAG com cada nó anotado: hora de início, hora de fim, modelo resolvido, contagem de tokens de entrada e saída, chamadas de ferramentas feitas e o erro, se houve. Nas etapas de LLM você pode expandir o prompt exato enviado e a resposta bruta recebida.
Se uma etapa falha, o rastreamento diz se o erro veio da chamada ao modelo (erro do fornecedor, estouro de contexto, recusa por política de conteúdo), de uma ferramenta seguinte (tempo limite de rede, falha de validação de esquema) ou da sua própria lógica condicional. Você não precisa adicionar log: é capturado no nível de infraestrutura em toda execução.
Qualquer execução pode ser repetida com a mesma entrada, o que torna direto reproduzir uma falha.
Um pequeno exemplo: fluxo semanal de inteligência competitiva
Imagine um fluxo que você inicia toda segunda-feira de manhã:
- Etapa de busca na web — procura cobertura recente de um conjunto de palavras-chave de concorrentes e devolve uma lista de endereços e trechos.
- Etapa de recuperação — traz os últimos quatro relatórios de uma base de conhecimento para fixar o contexto de partida.
- Etapa de resumo (LLM) — destila os resultados da busca em constatações estruturadas: recursos novos, mudanças de preço, anúncios relevantes.
- Etapa de redação (LLM) — escreve um informe interno conciso em um estilo de casa consistente, fundamentado nas constatações resumidas.
- Etapa de entrega — publica o informe em um endpoint de webhook configurado.
O grafo tem uma dependência natural: a etapa 3 depende da 1 e da 2 (que podem rodar em paralelo), a 4 depende da 3, a 5 depende da 4. O executor procede assim sem nenhuma configuração explícita de paralelismo: ele lê as arestas.