Graph, loop ou híbrido? Como escolher orquestração sem entregar o controle ao modelo

Um agente recebe um objetivo e escolhe sozinho quantas vezes tentar, quais ferramentas chamar, que subagentes criar e quando considerar o trabalho concluído. A flexibilidade parece inteligente. Ela também permite que o executor altere a própria autoridade durante a execução.

Orquestração é decisão de arquitetura e policy. O modelo participa; não se autoconcede controle.

Resumo executivo

Escolha o modo pela estrutura do problema:

O default recomendado é: determinístico onde sabemos, probabilístico onde precisamos, humano onde o efeito ou a incerteza exigem.

Chain: simples e observável

Uma chain executa uma sequência conhecida:

coletar -> classificar -> redigir -> verificar -> encaminhar

Vantagens:

• custo e latência previsíveis;
• pontos de falha claros;
• testes por etapa;
• retries localizados.

Use quando a variação está dentro das etapas, não na topologia. Evite forçar chain quando o problema exige voltar, comparar ou buscar evidência adicional.

Graph: estado como contrato

Um graph representa caminhos, condições e transições:

intake -> risco baixo -> execução -> verificação
       -> risco alto  -> aprovação humana -> execução -> assurance

Vantagens:

• authority e estado ficam visíveis;
• branches podem ter policies diferentes;
• retomada e auditoria são mais claras;
• caminhos negativos recebem tratamento explícito.

O perigo é desenhar um grafo enorme antes de observar o fluxo real. Comece com estados de negócio e risco, não com cada chamada interna do modelo.

Loop: exploração com budget

Um loop observa, decide, age e reavalia até atingir condição de parada:

observe -> plan -> act -> verify -> stop | retry | escalate

Use em pesquisa, debugging, navegação e tarefas cujo caminho não pode ser totalmente previsto. Todo loop precisa de:

• objetivo e critério de sucesso;
• ferramentas e capabilities permitidas;
• budget de passos, custo e tempo;
• condições de parada e falha;
• checkpoints;
• escalation;
• evidence por tentativa material.

Sem esses limites, “autonomia” pode ser apenas ausência de controle.

Hybrid: liberdade dentro de cercas

O híbrido combina graph determinístico e loop limitado. Exemplo:

1. graph classifica risco e seleciona fontes;
2. loop pesquisa até satisfazer cobertura ou budget;
3. graph valida claims e exige revisão;
4. loop de correção tem no máximo duas tentativas;
5. graph promove ou escala.

Essa forma preserva adaptação sem deixar o modelo decidir a própria fronteira.

O modelo pode propor, a policy decide

Um modelo pode dizer “preciso buscar outra fonte” ou “esta tarefa exige especialista”. O harness avalia a proposta contra:

• allowlist de ferramentas;
• classe de dado;
• risco e reversibilidade;
• budget;
• identidade e authority;
• maturidade do ambiente;
• necessidade de gate humano.

Histórico de sessão, policy de orquestração e isolamento precisam continuar explícitos; adapter ou canal não pode virar security boundary. [HARNESS31-C2]

Como escolher em sete perguntas

1. O caminho é conhecido antes de executar?
2. Quais estados importam ao negócio ou ao risco?
3. Onde adaptação realmente melhora o resultado?
4. Qual é o efeito máximo de uma ação errada?
5. Como o sistema prova progresso?
6. Qual budget e escalation existem?
7. Quem pode aceitar o resultado?

Se o caminho é conhecido, prefira chain. Se os estados e authorities variam, graph. Se o caminho precisa emergir, loop limitado. Se apenas uma parte exige exploração, hybrid.

Um exemplo: pesquisa source-bound

Chain pura

Buscar três fontes, resumir e publicar. Simples, mas pode parar com fontes duplicadas ou fracas.

Loop puro

Pesquisar até o agente julgar suficiente. Flexível, mas cobertura e custo ficam subjetivos.

Hybrid

• graph exige fonte primária, contraponto e validade;
• loop busca dentro de domínios e budget aprovados;
• checker valida URL, receipt e claim binding;
• humano aprova inferência material;
• publication gate libera o asset exato.

O híbrido não é automaticamente melhor. É adequado quando requirements fixos cercam descoberta variável.

Mais camadas exigem ablação

Planner, generator e evaluator podem melhorar uma tarefa longa e elevar substancialmente custo e latência. Um experimento de fornecedor mostrou esse trade-off; o resultado dependeu do modelo, benchmark e aplicação. Antes de tornar uma camada obrigatória, compare com a arquitetura mais simples que pode funcionar. [HARNESS31-C3]

Teste:

• baseline sem a camada;
• resultado por classe de caso;
• custo e latência marginais;
• falhas novas introduzidas;
• dependência do modelo;
• valor da separação de authority.

Arquitetura agentic envelhece junto com modelos. Remova scaffolding que deixou de ser necessário sem remover controles que protegem propriedades duráveis.

Anti-padrões

O que este artigo prova — e o que não prova

Padrões públicos de agents distinguem workflows predefinidos de agents dinâmicos e recomendam começar pela solução mais simples. Experimentos de harness mostram ganhos e custos dependentes da tarefa. A FORGE transforma essas observações em uma regra de policy e authority.

O artigo não determina que graph ou hybrid é universalmente superior, nem que loops são inseguros por definição. A escolha precisa de threat model, eval e operação do produto.

Conclusão

Chain, graph e loop são formas de organizar incerteza. A decisão importante não é qual framework usar, mas onde o caminho pode variar, quem governa essa variação e que evidência libera o próximo efeito.

O modelo pode explorar o caminho. O sistema continua dono das cercas.

Leitura anterior: Agentes de longa duração. Próxima leitura sugerida: Autonomia proporcional ao risco.