Agent Architecture Patterns

O primeiro recurso de "IA" que lancei foi um widget de triagem de suporte dentro de um painel interno de suporte. Os tickets chegavam, o widget escaneava cada mensagem em busca de palavras- chave e roteava a conversa para uma resposta pré-definida. Funcionava lindamente — até que um cliente escreveu "minha coisa parou de fazer o que faz." Zero correspondências de palavras-chave. O widget retornou "Desculpe, não posso ajudar com isso," e o ticket ficou sem roteamento por horas.

Eu havia construído um agente reativo: um sistema que mapeia entradas diretamente para saídas por meio de um conjunto fixo de regras, sem capacidade de raciocinar sobre o que ainda não conhece. As regras eram um modelo fixo do mundo como ele existia no dia em que escrevi o código. O mundo avançou; as regras não.

Pense em um agente reativo como uma máquina de vendas. Você pressiona B4 e obtém uma barra de granola. Mas se alguém pedir "algo saudável e crocante," a máquina não tem resposta — ela só entende códigos de botões. Um agente deliberativo é mais como um consultor experiente: você descreve o que precisa em linguagem natural, e ele raciocina sobre a melhor resposta antes de responder.

Essa lacuna — estímulo-resposta fixo versus raciocínio com contexto completo — é a divisão arquitetural sobre a qual todos os outros módulos neste caminho se constroem.

Um agente reativo produz uma saída no momento em que vê uma entrada. Não há memória, sem raciocínio, sem modelo — apenas uma tabela de lookup expressa como código.

Esta função era todo o cérebro de triagem daquele painel de suporte. Quando o volume de tickets era baixo e as mensagens eram previsíveis, ela se sustentava. Sob carga real, três modos de falha surgiram:

1. Fraseamento desconhecido — "minha coisa parou de fazer o que faz" atinge o ramo else sempre.
2. Cegueira de contexto — uma mensagem de acompanhamento ("ainda quebrado depois de tentar isso") é tratada como um novo ticket, não uma continuação da troca anterior.
3. Deriva silenciosa — quando um novo recurso de produto foi lançado, todos os tickets sobre ele falhavam até que alguém atualizasse manualmente a cadeia if/elif.

Agentes reativos são apropriados para entradas determinísticas e enumeráveis — mapear códigos de status HTTP para mensagens, por exemplo. Eles falham no momento em que o espaço de entrada é aberto.

Um agente deliberativo mantém o histórico completo de uma conversa e pede a um modelo de linguagem que raciocine sobre esse histórico antes de responder. A janela de contexto do modelo torna-se a memória de trabalho do agente — não um índice de palavras-chave.

Quando substituí o widget de triagem reativo por um loop deliberativo, "minha coisa parou de fazer o que faz" produziu uma resposta sensível na primeira tentativa. O modelo inferiu intenção do contexto em vez de combinar palavras-chave. Mais importante, mensagens de acompanhamento — "ainda quebrado" ou "deixa pra lá, achei" — chegaram corretamente porque o agente lembrava o que já havia sido dito.

Aqui está a versão deliberativa mínima — o primeiro bloco executável canônico para este caminho:

A mudança estrutural em relação à versão reativa é pequena mas fundamental:

• Histórico de conversa acumula cada turno, então mensagens de acompanhamento carregam contexto completo.
• Sem cadeia if/elif — o modelo interpreta intenção da própria mensagem.
• claude-sonnet-4-6 aplica sua janela de contexto de 200K tokens para surfaçar a resposta mais relevante, inclusive para fraseamentos nunca antecipados quando o sistema foi construído.

Após lançar a versão deliberativa, o próximo desafio foi a explicabilidade. Quando um colega perguntou "por que ele sugeriu uma redefinição de senha para aquele ticket?", não havia trilha de auditoria — apenas uma resposta.

O padrão ReAct (Raciocínio + Ação) aborda isso pedindo ao modelo que escreva seu raciocínio antes de agir. Cada etapa tem a forma: pensar sobre o que fazer, então fazer. Quando adicionei raciocínio explícito ao agente de suporte, duas coisas melhoraram: a depuração tornou-se possível (eu podia ler a cadeia de pensamento), e a qualidade das respostas aumentou (o raciocínio escrito capturava erros antes que a resposta final fosse entregue).

A cadeia de raciocínio torna-se parte do contexto passado para a próxima etapa. Cada decisão subsequente que o agente toma tem visibilidade sobre por que a etapa anterior escolheu o que escolheu — não apenas o que escolheu. Este é o primeiro vislumbre do princípio de contexto compartilhado que o módulo 06 formaliza.

Ponto de Verificação do Módulo

Antes de continuar, considere: o que aconteceria se dois agentes deliberativos separados trabalhassem em metades diferentes da mesma tarefa — sem compartilhar seus históricos de conversa?

Cada instância faria suposições independentes. Seus resultados provavelmente entrariam em conflito ou duplicariam trabalho. Este é o modo de falha multi-agente que o módulo 06 diagnostica e que a arquitetura linear dos módulos 02 a 05 é especificamente projetada para evitar. Tenha esse modo de falha em mente enquanto o caminho avança.

Os padrões reativo e deliberativo estabelecem o porquê. A arquitetura usada ao longo do restante deste caminho é um agente linear: uma única instância de modelo que recebe uma especificação de tarefa, gera um plano de etapas e executa cada etapa sequencialmente — com o contexto completo anterior visível em cada turno.

Sem agentes paralelos. Sem históricos fragmentados. Cada etapa constrói sobre a anterior.

Isso é intencionalmente mínimo. O módulo 02 adiciona o loop de planejamento e execução. O módulo 03 registra ferramentas que o agente pode chamar. O módulo 04 insere pontos de verificação humanos. O módulo 05 monta o capstone completo. Cada expansão é ganha pela prosa que a introduz.