Padrões: reflection, plan-execute e multi-agente

Reflection é o padrão mais simples do catálogo e, por isso, o mais subestimado. A ideia: depois de gerar uma resposta, o agente faz uma segunda passagem — com um prompt de crítica — e decide se o resultado está bom o suficiente ou precisa de revisão.

Pense como um desenvolvedor que escreve código e depois lê de novo antes de abrir o PR. O modelo não muda de natureza; ele só recebe o contexto de "revisor" em vez de "autor".

Como implementar: você passa a saída anterior de volta ao modelo com uma instrução como "Revise a resposta abaixo. Identifique erros factuais, lacunas de raciocínio e inconsistências. Se estiver correta, responda APROVADO. Caso contrário, reescreva." Você pode iterar N vezes ou até receber APROVADO.

Quando usar: geração de código, relatórios, respostas longas onde alucinação pontual é cara. O custo é uma chamada extra ao modelo — barato comparado a entregar lixo ao usuário.

Cuidado com loops infinitos: defina sempre um max_iterations. Sem isso, um modelo que nunca converge vai consumir tokens indefinidamente. Reflection não garante correção — garante uma segunda chance de perceber o erro.

No loop ReAct padrão (visto na lição 11), o agente decide a próxima ação a cada passo — é um raciocínio guloso, passo a passo. Isso funciona bem para tarefas curtas, mas em tarefas longas o agente pode perder o fio da meada, mudar de estratégia no meio do caminho ou gastar tokens repetindo contexto.

Plan-and-Execute separa as responsabilidades em duas fases:

1. Fase de planejamento: o modelo recebe o objetivo e produz um plano estruturado — uma lista de subtarefas ordenadas. Nenhuma ferramenta é chamada ainda.
2. Fase de execução: cada subtarefa do plano é executada em sequência (ou em paralelo, se independentes), possivelmente por agentes especializados.

A vantagem é clareza: o plano é um artefato inspecionável. Você pode logar, validar e até mostrar ao usuário antes de executar — o que abre espaço para o padrão human-in-the-loop que veremos adiante.

A desvantagem é rigidez: se o mundo muda durante a execução (uma ferramenta retorna erro, um dado não existe), o plano original pode ficar inválido. Boas implementações incluem um passo de re-planejamento quando uma subtarefa falha.

Quando usar: tarefas de pesquisa longa, geração de documentos complexos, pipelines de dados onde a sequência importa. Evite para tarefas curtas e imprevisíveis — o overhead de planejamento não compensa.

Multi-agente é o padrão que mais aparece em demos e o que mais gera arquiteturas desnecessariamente complexas. Antes de adotar, entenda as três variantes:

Supervisor/Orquestrador → Sub-agentes: um agente central recebe o objetivo, decide qual sub-agente especializado acionar e consolida os resultados. É o padrão mais comum e mais controlável. O supervisor não executa tarefas diretamente — ele delega.

Hierárquico: o supervisor pode ter sub-supervisores, que por sua vez têm sub-agentes. Útil para domínios muito grandes (ex.: empresa com departamentos distintos). O custo de coordenação cresce exponencialmente com a profundidade — use com cuidado.

Peers/Swarm: agentes sem hierarquia explícita colaboram via mensagens. Cada agente pode iniciar interações com outros. É o padrão mais flexível e o mais difícil de debugar — o fluxo de controle emerge do comportamento coletivo, não de um orquestrador central.

O diagrama abaixo mostra o padrão supervisor → sub-agentes, que é o ponto de partida recomendado para qualquer sistema multi-agente.

O ponto crítico: cada fronteira entre agentes é uma chamada ao modelo — latência, custo e um novo ponto de falha. Um sistema com cinco agentes pode ter cinco vezes mais chances de alucinação propagada. Comece sempre com o agente mais simples que resolve o problema.

Human-in-the-loop (HITL) não é uma limitação do sistema — é uma decisão arquitetural deliberada. Em vez de deixar o agente executar um plano completo de forma autônoma, você insere um ponto de aprovação humana antes de ações irreversíveis ou de alto impacto.

Exemplos concretos: antes de enviar um e-mail em nome do usuário, antes de deletar registros em banco, antes de publicar conteúdo, antes de executar uma transação financeira. A regra prática: se a ação não pode ser desfeita com facilidade, coloque um humano no caminho.

Implementar HITL é simples conceitualmente — o agente para, serializa o estado atual (plano + contexto), e aguarda uma confirmação externa. Na AWS, isso se traduz em uma fila SQS ou um Step Functions waitForTaskToken. O desafio real é UX: como apresentar o estado do agente de forma que o humano entenda o que está aprovando?

HITL também é um mecanismo de aprendizado. Cada aprovação ou rejeição é um dado de avaliação — você pode usar esses sinais para melhorar prompts, identificar padrões de erro e calibrar quando o agente pode operar de forma mais autônoma.

Não confunda HITL com desconfiança no modelo. É gerenciamento de risco. Sistemas maduros começam com mais pontos de aprovação e os removem gradualmente à medida que o agente demonstra confiabilidade — não o contrário.