Flows: pipelines de agentes no COGNIX[WS]
Um flow liga gatilhos, agentes, decisões e pessoas num grafo que roda sozinho e para onde uma pessoa precisa decidir. Ele usa as peças que já existem (automações, mensagens, Inbox, Review e Merge, Channels), e os agentes montam flows pelas mesmas ferramentas que você usa na tela.
Onde o Flows entra no COGNIX[WS]
Flows ganha uma página própria em Tools e uma aba em cada workspace. Na maior parte do tempo, porém, a pessoa encontra os flows pelo Inbox, pela Home e pelo Assistente, e os agentes pelas ferramentas. Clique em cada ponto de entrada.
| Endereço | O que abre | Back |
|---|---|---|
#/flows | Lista de flows, com filtro por workspace | Para onde você veio |
#/flows/runs · #/flows/starters | Abas da página (trocar de aba substitui o endereço) | Sai da página, não aba por aba |
#/flows/new?starter=…&workspace=… | Editor vazio ou de um starter | Volta à lista ou ao workspace |
#/flows/<id> · …/runs · …/versions · …/settings | Editor e suas abas | Para onde você veio (Inbox, Home, workspace) |
#/flows/<id>/runs/<n> | O run aberto no editor, como Abrir no editor | Para o Inbox, se veio de lá |
#/workspaces/<id>/flows | Aba Flows do workspace | Sai do workspace |
Catálogo de nós
Cada nó, o que se configura nele, o que entra e sai, e o que acontece quando dá errado. As variáveis {{input}}, {{trigger.body.campo}} e {{<nó>.output}} entram em qualquer texto; o painel oferece as do nó anterior.
Como roda
Não há um orquestrador vivo. O flow é uma automação cujo trabalho é um grafo. Cada run copia o grafo de quando começou e grava cada passo como uma linha no banco. Uma passada lê os passos, fecha os que terminaram e começa todo nó cujas entradas chegaram. As passadas acontecem quando o feed anuncia algo (um agente terminou o turno, alguém aprovou no Inbox, um merge caiu) e quando o app abre. Desligar o computador no meio não perde nada: aprovações e passos de agente continuam de onde pararam, como as automações já fazem hoje.
| Nó | Porta que já existe | Termina quando |
|---|---|---|
| Agente novo | create_agent com tarefa: qualquer um dos 9 CLIs, template, worktree, sandbox ou VM | a resposta à mensagem de tarefa chega |
| Agente que já roda | send_message + wait_for_reply | a resposta chega |
| Vários agentes | fan-out de wait_for_reply com vários ids | todos responderam, ou o primeiro (escolha do nó) |
| Assistente | automação que roda um Assistente | o turno sela; [[no-update]] vira saída vazia |
| Script | run de script das automações | sai com código |
| Condição | modelo sem ferramentas (sim/não) ou campo do JSON (sem modelo) | na resposta; segue um ramo |
| Aprovação | Inbox, como ask_human | a pessoa decide, em qualquer superfície |
| Review | Review + Merge sobre a branch que o agente entregou | aprovado ou com pedidos de mudança |
| Merge | land na fila | make ci verde e fast-forward |
| Saídas | aviso no Inbox, post no Channels, artifact, webhook de saída | entregue (post incerto não é reenviado) |
Agente, pessoa e sistema
O agente
Usa a ferramenta MCP flow: draft, validate, propose, run, status. Um flow proposto chega ao Inbox com o grafo exato e não roda antes da aprovação, como as automações. Um agente só põe num flow os agentes e ferramentas que ele mesmo pode usar.
A pessoa
Desenha ou aprova o flow, vê o run passo a passo no mesmo canvas e decide nos nós de aprovação e review pelo Inbox, inclusive no celular. Pode rodar um nó sozinho ou recomeçar a partir de um nó.
O sistema
Grava flows, runs e passos com evento no feed, no mesmo commit. Aplica limites (voltas de loop, tempo, gasto). Inclui tudo no backup. As permissões de um flow são a soma das permissões dos passos, aprovadas uma vez.
O que fazemos melhor que o OpenBot
| Ponto | OpenBot v0.56 (código lido) | COGNIX[WS] |
|---|---|---|
| Quem monta | Só a pessoa: agentes têm ferramenta de rotina, não de workflow | Agente propõe pela ferramenta flow, a pessoa aprova o grafo exato |
| Loop | Sem limite de voltas | Máximo de voltas por loop e teto de gasto por run |
| Saída de código | Só texto, imagem e arquivo | Porta branch: agente entrega worktree, Review e Merge recebem |
| Paralelo | Um nó por agente | Nó de vários agentes (fan-out) com "todos" ou "primeiro" |
| Onde roda | Agentes do servidor | Este PC, outra máquina, sandbox ou VM, por nó |
| Gatilho de evento | Mensagem ainda não suportada | Channels, webhook com filtro e dedupe, eventos do feed (merge, run terminou) |
O que veio do n8n
| No n8n | No flow do COGNIX[WS] | Onde ver na página |
|---|---|---|
| Dados de cada passo, Debug in editor, pin data | Abas Entrada e Saída em cada nó; abrir um run antigo no canvas; fixar a saída de um nó para testar o resto sem rodar o agente | Painel vazio: Runs recentes. Nó: abas Entrada e Saída |
| Continue on fail (saída de erro), Error workflow | Ramo vermelho "falhou" em qualquer nó que trabalha; gatilho Erro em outro flow | Exemplos Uma correção por issue e Flow como ferramenta |
| Loop Over Items, Merge, Switch | Para cada item (com limite de itens ao mesmo tempo), Juntar, Switch com até 4 ramos e outro | Exemplo Uma correção por issue; paleta, grupo Decisão |
| Execute Workflow, MCP Server Trigger | Subflow; gatilho Chamado por agente: o flow vira uma ferramenta MCP que os agentes chamam e recebem a resposta | Exemplo Flow como ferramenta |
| Wait | Esperar um tempo, uma data ou um evento; o run dorme no banco | Paleta, grupo Decisão |
| Expressões com prévia | Campos com {{…}} mostram o valor com os dados do último run; clicar num campo da Entrada insere a expressão | Nó Corrigir o bug: aba Configurar |
| Retry on fail | Tentativas e espera entre elas (crescente) em todo nó que trabalha | Seção Execução do nó |
Fica de fora: o nó AI Agent com sub-nós (aqui o agente é um dos 9 CLIs) e os nós de integração (entram por extensão ou pelo registro de MCP).
Fatias
- F0 — ADR e modelo. Tabelas
flows,flow_runs,flow_steps; regras de portas compartilhadas pelo Go e pela UI; inventário de backup e fixture. - F1 — Motor. Passadas sobre o feed; nós Gatilho manual/agenda, Agente, Condição, Aprovação, Aviso no Inbox; ramo falhou, tentativas com espera e gatilho Erro em outro flow. Tabela de decisão de cada estado de passo com testes.
- F2 — Editor. Rota
#/flowscom React Flow, run ao vivo no canvas, abas Entrada e Saída, fixar saída, abrir run antigo, prévia das expressões, rodar nó sozinho, versões; guia e superfície no atlas. - F3 — Agentes. Ferramenta
flow(propor, validar, rodar) com proposta pelo Inbox; Subflow; gatilho Chamado por agente com Responder a quem chamou; avaliação commake tool-eval. - F4 — Listas e código. Para cada item, Juntar, Switch, Esperar; Branch, Review, Merge, fan-out; webhook e Channels como gatilho; saídas para Channels e artifact.
Decisões para você
| Pergunta | Recomendo | |
|---|---|---|
| D1 | Flow é um tipo novo de automação ou uma página própria? | Página própria #/flows, mesmo motor de agenda e webhook das automações |
| D2 | React Flow como dependência do web/? | Sim: MIT, ~150 KB, o padrão de canvas de nós (vale a linha de justificativa) |
| D3 | Agente pode rodar um flow aprovado sem pedir de novo? | Sim, com o grafo travado na versão aprovada; editar pede nova aprovação |
| D4 | Condição por modelo usa qual modelo? | O do Assistente padrão; o nó pode trocar |
| D5 | Começar pelo pipeline de código (F4) ou pelo genérico (F1)? | F1 primeiro: é a base; o de código vem logo depois |
| D6 | Um flow como ferramenta aparece para quem? | Só para agentes do mesmo workspace por padrão; outros workspaces e Assistentes marcados no gatilho |
| D8 | Flows tem página própria em Tools ou vira uma aba de Automations? | Página própria, com aviso cruzado em Automations; juntar as duas só se o uso pedir |
| D9 | Um flow pertence a um workspace? | Sim: os agentes nascem na pasta e na confiança dele; a lista geral filtra por workspace |
| D7 | Para cada item com agentes: qual limite padrão de itens ao mesmo tempo? | 3, e no máximo 20 itens por run; cada item é um agente vivo e gasta |
Os exemplos do canvas são ilustração. A simulação não chama nenhum agente.