Seis padrões de arquitetura que todo agente vertical deveria implementar
Seis padrões de arquitetura que todo agente vertical deveria implementar
O Claude Design ficou famoso pela qualidade do que produz. Mas o que importa para quem constrói agentes não é o output. É a arquitetura que torna o output possível.
Depois de olhar como esse sistema foi construído, ficam visíveis seis padrões que não são específicos para design. São princípios de engenharia de agentes que se aplicam a qualquer domínio: jurídico, comercial, de RH, de operações. O conjunto desses padrões é o que diferencia um agente que funciona em produção de um protótipo que funciona em demo.
1. Grounding antes de gerar
O primeiro padrão é que o agente nunca gera output sem primeiro ler uma fonte de verdade sobre o contexto do usuário.
No Claude Design, isso é o design system: antes de criar qualquer componente, o agente lê as definições de marca, cores, tipografia, exemplos de componentes. Só depois começa a gerar.
A generalização: qualquer agente vertical tem uma fonte de verdade que precisa ser consultada antes de qualquer geração. Para um agente jurídico, são os templates de contrato e as jurisprudências relevantes. Para um agente de vendas, é o histórico do CRM e o contexto do prospect. Para o Athena, são as regras de negócio e o schema específico de cada empresa no TOTVS. A regra é simples: nunca gere cegamente antes de o agente se orientar nos dados reais do usuário.
2. Memória estruturada como primeiro output
O segundo padrão é que o primeiro output do agente não é a entrega final ao usuário. É a estruturação do contexto em memória reutilizável.
No Claude Design, isso é o design system gerado pelo próprio agente: um arquivo estruturado que encapsula o que foi aprendido sobre a marca e que vai ser reutilizado em todas as tarefas subsequentes.
O formato importa aqui. Não é um schema proprietário. É Markdown, HTML, JSON, formatos que qualquer modelo downstream consegue consumir. Isso torna a memória portável para outros agentes no pipeline.
3. Loop de refinamento multimodal
O terceiro padrão é ter múltiplos modos de input para o refinamento iterativo, em vez de forçar tudo pelo chat.
No Claude Design, o usuário pode passar instrução por voz, apontar para um elemento na tela, desenhar uma marcação sobre o output. Cada modalidade captura um tipo diferente de intenção.
Para agentes não-visuais, o equivalente é ter formas estruturadas de capturar feedback que vão além do campo de texto livre. Um slider de intensidade, opções binárias para clarificações, seleção de variantes. O modelo pode gerar os próprios controles de follow-up baseado no output que produziu.
4. Auto-revisão antes de entregar
O quarto padrão é o agente revisar o próprio output antes de apresentar ao usuário.
No Claude Design, isso é literal: o agente renderiza o que gerou, tira screenshot do resultado, e avalia se o que está na tela corresponde à intenção. Itera até estar alinhado.
Para outros domínios: se o agente gera um contrato, passe para um segundo modelo revisar por inconsistências antes do usuário ver. Se gera um relatório, verifique se as afirmações são suportadas pelos dados no contexto. Se gera uma query SQL, rode num ambiente de teste antes de entregar como resposta.
O custo de tokens é real. O argumento é que a qualidade justifica, e que quanto mais o modelo é capaz, mais a auto-revisão captura problemas que antes passavam.
5. Geração de variações proativas
O quinto padrão é o agente gerar múltiplas versões de forma proativa, sem esperar o usuário pedir.
No Claude Design, para layouts e estruturas, o agente apresenta opções com variação ao longo de dimensões que importam (layout, estrutura, hierarquia), não somente uma resposta que o usuário tem que aceitar ou reformular.
O benefício é duplo: o usuário vê o espaço de possibilidades e pode fazer uma escolha informada, e o agente sinaliza implicitamente qual a dimensão de variação que considera mais importante para o problema.
Para um agente de vendas, isso pode ser gerar três variações de email com tons diferentes. Para o Nexus ZDT, pode ser gerar duas versões de um relatório de RH com diferentes níveis de detalhe para públicos diferentes.
6. Output projetado para handoff
O sexto padrão é que o output do agente precisa ser consumível por ferramentas externas e por outros agentes, não só pelo usuário final.
No Claude Design, tudo é armazenado em HTML/CSS e pode ser exportado para PowerPoint, Figma, PDF, ou passado para o Claude Code como contexto. Nenhum output fica preso num formato proprietário.
Para agentes empresariais, isso significa que o resultado de um agente precisa poder alimentar o próximo passo do processo. Um agente que gera análise de solicitação de férias precisa produzir um output que o sistema de aprovação do GITFLOW pode consumir diretamente, sem transformação manual.
O que torna esses padrões funcionar juntos
O que o Claude Design demonstra é que nenhum desses padrões funciona bem isolado. É a combinação do primeiro com o segundo que faz o sistema sentir diferente: o grounding alimenta a memória, a memória alimenta todas as gerações subsequentes, a auto-revisão fecha o loop de qualidade, e as variações proativas aceleram o alinhamento com a intenção do usuário.
A maioria dos agentes empresariais hoje ainda está num modelo de system prompt estático + geração direta. Os padrões acima representam o próximo nível: agentes que constroem sua própria base de conhecimento sobre o contexto do usuário e geram a partir dessa base.
Qual dos seis padrões está faltando no agente que você está construindo?
Assine a Newsletter
Receba conteúdo exclusivo sobre IA, LLMs e desenvolvimento em produção diretamente no seu email.
Sem spam. Cancele quando quiser.
Posts Relacionados
Prompt não é instrução. Contexto é o recurso que o modelo usa para raciocinar
A maioria das pessoas ainda trata prompt como uma instrução que você dá ao modelo. A mudança de perspectiva que importa é perceber que contexto é o recurso escasso, e o que você injeta nele determina o teto de qualidade do que sai.
Deixar o agente encontrar os parâmetros certos: o loop de auto-otimização
Um pipeline RAG tem pelo menos meia dúzia de parâmetros que afetam a qualidade: tipo de chunking, tamanho, overlap, top-k, modelo de embedding, estratégia de busca. A maioria dos times testa esses parâmetros manualmente. Existe uma alternativa.
O gargalo não é o modelo, é atenção humana gerenciando sessões
O teto de quanto você consegue extrair de agentes de código não é mais capacidade do modelo. É quanto contexto humano você consegue manter ativo ao mesmo tempo. A mudança de paradigma é de gerenciar sessões para gerenciar resultados.