Post
Flow por fora, Agents onde a autonomia agrega
Como usar Flow para controlar o processo, Agents para interpretar e Crew apenas quando existe colaboração dinâmica.
No primeiro texto desta série, propus uma separação:
Agent é autonomia. Crew é colaboração. Flow é orquestração.
Essa distinção fica útil quando uma pergunta aparentemente simples começa a misturar responsabilidades.
Considere:
Quanto tenho em aberto e ainda não vencido?
Para responder, o sistema pode precisar interpretar o significado de “não vencido”, definir o período, consultar os registros, calcular o total, validar os dados e redigir a resposta.
É possível colocar tudo dentro de um Agent. A possibilidade, porém, não decide se essa é uma boa fronteira.
O Flow controla o caminho
Eu começaria descrevendo o processo sem escolher uma biblioteca:
1
2
3
4
5
6
7
8
9
Flow
├── interpretar intenção
├── validar parâmetros
├── consultar dados
├── calcular
├── validar
├── analisar contexto
└── comunicar
Depois atribuiria uma implementação a cada etapa:
1
2
3
4
5
6
7
interpretar_intencao → LLM ou Agent
validar_parametros → código
consultar_dados → Tool / API
calcular → código
validar → código
analisar_contexto → Agent ou Crew
comunicar → LLM
O Flow não é “a parte determinística”. Ele é o lugar onde a ordem, as dependências, as exceções e as regras de parada ficam visíveis. Dentro dele podem existir etapas probabilísticas e determinísticas.
Pergunta simples: Agent solo
Se a pergunta pertence claramente a um único domínio, eu chamaria o especialista diretamente:
1
2
3
4
5
6
7
Flow
↓
Agent especializado
↓
verificação
↓
resposta
Não há motivo automático para criar uma Crew. O Agent pode interpretar a solicitação e pedir à Tool os dados necessários. O Flow ainda mantém a verificação e decide o que fazer se ela falhar.
Essa rota também reduz o custo de uma decisão desnecessária: um manager não precisa escolher entre especialistas que não têm relação com a pergunta.
Pergunta combinada: fan-out e fan-in
Agora imagine:
Como meus próximos pagamentos se relacionam com o caixa previsto para o período?
Há pelo menos dois domínios. Uma Crew pode ser uma opção, mas eu perguntaria primeiro se os Agents precisam conversar ou delegar entre si.
Se cada análise puder ser feita de forma independente, o Flow pode coordenar o trabalho:
1
2
3
4
5
6
7
8
9
10
11
Flow
│
┌───────┴───────┐
↓ ↓
Agent Caixa Agent Pagamentos
│ │
└───────┬───────┘
↓
merge
↓
análise
Eu chamaria esse desenho de fan-out/fan-in: o processo distribui as partes, espera os resultados e os reúne. Os Agents trabalham em paralelo, mas não precisam ser apresentados como uma equipe se não existe colaboração entre eles.
O merge também precisa de um contrato. O Flow deve saber quais campos cada
Agent precisa retornar, como representar ausência de dados e o que fazer quando
uma das análises falha.
Recomendação de solução: Crew
A Crew aparece quando a investigação muda conforme as contribuições dos especialistas.
Considere:
Que alternativas temos para reduzir a pressão financeira das próximas semanas?
Um Agent responsável por soluções pode decidir quais alternativas avaliar:
1
2
3
4
5
6
7
8
Crew Soluções
Manager
│
decide e delega
┌─────┼─────┐
↓ ↓ ↓
Agent A Agent B Agent C
Aqui há uma razão concreta para a Crew: delegação dinâmica. Um especialista pode escolher uma combinação de executores e usar o resultado de uma análise para orientar a próxima.
Na proposta que motivou esta série, esse era o caso mais claro de colaboração. O desenho ainda não tinha sido aplicado em produção; portanto, não apresento ganhos de velocidade ou qualidade como resultado medido. A proposta apenas separa o lugar em que a Crew parece necessária dos caminhos que podem ser coordenados pelo Flow.
Auditoria qualitativa e verificação factual
O mesmo cuidado vale para um Agent auditor.
Um auditor pode avaliar:
- se a conclusão é coerente com os dados apresentados;
- se a recomendação respeita as restrições;
- se alguma premissa foi ignorada;
- se há contradição ou problema de comunicação.
Isso é diferente de verificar:
1
40 registros somam 985626.84?
Para essa pergunta, eu usaria:
1
sum(records) == reported_total
Minha recomendação é deixar a auditoria qualitativa no Agent e a verificação computável no código. Um segundo LLM pode produzir uma crítica útil, mas não é uma fonte independente para a soma que o primeiro LLM fez.
Regras de parada também pertencem ao Flow
Quando uma resposta é contestada, “tente novamente” não deveria ser a política inteira:
1
2
3
4
5
novo resultado
↓
nova contestação
↓
outro resultado
O Flow pode transformar o caso em uma regra explícita:
1
2
3
4
5
6
7
8
9
10
11
resultado divergiu?
↓
recalcular por caminho determinístico
↓
continua divergindo?
┌───────┴───────┐
não sim
↓ ↓
seguir interromper
↓
revisão humana
Uma divergência factual não deve ser tratada como convite para sortear um novo número. Ela precisa de uma nova consulta, de um cálculo independente ou de uma interrupção.
O risco que o Flow introduz
Separar caminhos também cria um novo ponto de falha: o classificador de intenção. Se ele mandar uma pergunta combinada para um Agent solo, a resposta pode parecer completa e deixar um domínio de fora.
Eu testaria essa fronteira antes de afirmar que o novo desenho melhorou o sistema. Um conjunto pequeno já ajuda: variações de fraseado para a mesma pergunta, contas com volumes diferentes e casos que exigem paginação. O critério não seria apenas uma resposta correta; seria também encaminhar cada caso para o caminho que consegue responder por inteiro.
Flow por fora não é uma defesa contra Agents. É uma forma de reservar autonomia para as decisões que precisam dela e manter o processo observável quando as peças começam a interagir.
No terceiro texto, trato da fronteira mais concreta dessa arquitetura: o LLM pode decidir qual cálculo deve acontecer, mas não deveria ser a calculadora.