Como funciona o agente Hermes por dentro: contexto, raciocínio e execução

TL;DR

A resposta final é só a parte visível. Por trás existe um ciclo operacional: interpretar a intenção, montar o contexto, planejar etapas, escolher ferramenta, observar o resultado, reavaliar e validar.

• O Hermes é uma camada de coordenação, não um modelo isolado.
• Cada turno é uma cadeia auditável de decisões, não um passe de mágica.
• O texto visível é o último nó de um pipeline que pode ter dezenas de etapas internas.

O que significa “por dentro” de um agente

“Por dentro” não é o mesmo que “dentro do modelo de linguagem”. Um agente não é o LLM. Um agente é a camada que envolve o LLM e toma decisões sobre o que fazer com ele.

O modelo de linguagem é uma peça. Ele transforma texto em texto com alta probabilidade contextual. Mas ele não decide sozinho: ele não sabe o que o usuário quer de fato, não sabe quais ferramentas estão disponíveis, não sabe o que aconteceu nos turnos anteriores, não sabe quando parar e quando perguntar.

Essas decisões vivem fora do modelo. Elas formam o que se pode chamar de ciclo operacional do agente: a sequência de etapas que transforma uma solicitação em uma resposta validada. Quando alguém pergunta “como o Hermes funciona por dentro?”, está perguntando sobre esse ciclo, não sobre os bilhões de parâmetros do modelo que ele usa.

A confusão entre agente e modelo é uma das fontes mais comuns de mal-entendido sobre IA generativa. Quando uma empresa diz “estamos usando IA”, pode estar usando um LLM puro via prompt (chatbot), ou um agente que planeja, executa, valida (sistema). O comportamento é completamente diferente.

O ciclo operacional em dez etapas

O Hermes segue uma sequência repetível para cada solicitação. Nem todas as etapas rodam em todos os turnos, mas a estrutura está sempre disponível:

• Receber o objetivo — a string bruta da conversa chega como entrada do ciclo.
• Interpretar a intenção — distinguir o que foi dito do que foi pedido de fato.
• Reunir o contexto — carregar memórias, skills, regras, histórico relevante.
• Planejar as etapas — decompor o objetivo em tarefas executáveis e ordenadas.
• Escolher o modelo adequado — mapear cada tarefa ao LLM mais apropriado.
• Utilizar ferramentas — acionar terminal, leitura de arquivos, busca web, execução de código, delegação.
• Observar os resultados — ler retornos, validar formato, extrair informação útil.
• Reavaliar o plano — decidir se a próxima etapa ainda faz sentido dado o que se aprendeu.
• Validar a execução — confirmar que o objetivo original foi atendido com qualidade.
• Entregar a resposta — retornar ao usuário o texto final, mais metadados úteis quando aplicável.

Essas etapas não são lineares na prática. O ciclo é iterativo: o agente pode voltar três etapas, abortar uma etapa e seguir por outro caminho, ou pedir intervenção humana no meio. O importante é que a estrutura existe, é auditável e pode ser interrompida quando o contexto for insuficiente.

A duração real varia. Uma pergunta simples (“que horas são em Tóquio?”) pode rodar só as primeiras cinco etapas e terminar com uma única chamada de ferramenta. Uma pergunta complexa (“postar agora este post no blog”) dispara dezenas de etapas internas: leitura de regras, validação de slugs, geração de imagem, auditoria, upload, verificação, arquivamento.

Interpretação da intenção vs texto literal

A primeira etapa crítica é separar texto recebido de intenção real.

Um usuário escreve “o sistema não compila, o que faço?”. O texto literal é uma pergunta. A intenção real é: preciso de ajuda para diagnosticar e corrigir um erro de build. Agir sobre o texto literal seria responder com uma lista genérica de causas. Agir sobre a intenção é investigar o projeto, ler o erro, procurar a linha, sugerir a correção concreta.

O agente faz essa separação olhando três coisas: o histórico recente da conversa, o vocabulário técnico presente, e as ferramentas que ele tem à disposição. Quando o vocabulário é técnico e há ferramentas de investigação, a intenção provavelmente é executar. Quando o vocabulário é genérico e não há contexto, a intenção provavelmente é aprender ou decidir.

Erros nessa etapa costumam ser caros. Responder à pergunta errada significa trabalho desperdiçado, frustração do usuário, e necessidade de reformular. Por isso o agente gasta tempo entendendo antes de agir — não por formalidade, mas porque interpretar errado é o modo mais rápido de falhar.

Construção de contexto: memória curta e memória persistente

O agente não tem acesso infinito ao passado. Ele opera com dois tipos de memória:

Memória de curto prazo — tudo que está na conversa atual: o que o usuário disse nos turnos anteriores, o que o agente já respondeu, quais ferramentas rodaram e o que retornaram. É o contexto imediato da janela. Essa memória é volátil: quando a conversa termina ou esgota o limite, ela desaparece.

Memória persistente — tudo que sobrevive entre sessões: preferências do usuário, regras de projetos específicos, skills instaladas, decisões operacionais registradas. Essa memória é carregada no início de cada turno e serve como contrato de comportamento.

A separação importa porque cada uma tem custo e confiabilidade diferentes. A memória de curto prazo é rica e detalhada, mas limitada em tamanho e sensível a perdas (truncamento). A memória persistente é estável e confiável, mas precisa ser explicitamente registrada — não surge automaticamente.

Um agente maduro sabe o que está em qual memória. Quando o usuário pede algo e a memória de curto prazo não tem, ele consulta a persistente (skill, regra, MEMORY.md). Quando a persistente também não tem, ele admite a lacuna em vez de inventar.

Planejamento: da intenção bruta ao plano de execução

Nem toda intenção vira um plano. Mas quando vira, o plano precisa ser executável.

Um plano executável tem três propriedades: é decomposto em tarefas pequenas o suficiente para serem feitas em uma chamada de ferramenta; é ordenado por dependência (não dá para validar antes de executar); e tem critério de sucesso claro (o que conta como “feito”).

Exemplo: “postar agora este post no blog” não é um plano. “Validar briefing, gerar body, gerar capa, auditar SEO, upload, verificar capa, arquivar” é um plano.

O agente não escreve o plano em linguagem natural para o usuário ver. O plano é uma estrutura interna que orienta quais ferramentas chamar em qual ordem. O usuário vê só o resultado final e, quando pertinente, atualizações intermediárias (“gerando imagem…”, “validando links…”).

Quando o plano fica ambíguo ou grande demais, o agente pode dividi-lo em sub-planos e delegar partes para subagentes. Cada subagente opera com contexto isolado, executa sua parte e devolve um resumo. Esse particionamento é caro em overhead, mas é necessário quando o trabalho é grande demais para uma única cadeia.

Escolha de modelo e uso de ferramentas

Nem toda tarefa usa o mesmo modelo. Um agente opera um portfólio de LLMs, cada um com trade-offs de custo, latência e capacidade.

Tarefas de raciocínio profundo (planejamento, validação de planos longos, geração de texto técnico) pedem modelos maiores. Tarefas mecânicas (classificar, extrair, formatar) aceitam modelos menores e mais baratos. Tarefas de código aceitam modelos especializados em código.

O Hermes faz essa escolha baseado em heurísticas: complexidade aparente da tarefa, tipo de retorno necessário, e custo aceitável. A escolha raramente é visível para o usuário — o que ele vê é a resposta, não o nome do modelo por trás.

Ferramentas são o segundo vetor. O agente usa terminal para executar comandos, leitura/escrita de arquivos para persistir informação, busca web para obter dados externos, execução de código para cálculos e protótipos, delegação para dividir trabalho entre subagentes. Cada ferramenta tem um custo e um risco — uma execução de código pode falhar, uma busca web pode retornar lixo, um upload pode ser bloqueado.

A escolha de ferramenta também não é visível. O que aparece é o efeito: o agente leu um arquivo, executou um comando, fez upload de uma imagem. O usuário vê o resultado, não a chamada interna.

Validação, falhas e limites da autonomia

Um agente confiável não termina no primeiro retorno. Ele valida.

Validação pode ser: conferir que o texto gerado não tem caracteres quebrados, que os links internos apontam para posts que existem, que a densidade da palavra-chave está dentro do alvo, que a imagem da capa é única (não clone de uma anterior), que o post no WordPress tem status `publish` e capa correta.

Essas validações rodam como gates binários — passam ou falham. Quando falham, o ciclo volta para a etapa relevante: regenerar capa, ajustar SEO, refazer upload. Quando passam, segue.

Mas validação não é onipotência. Há limites claros:

• O agente não sabe o que o usuário realmente quer quando o pedido é ambíguo — pode escolher mal.
• O agente não tem acesso ao mundo físico — não pode tocar, ouvir, ver (a menos que receba imagens/áudio por ferramenta).
• O agente pode errar de boa fé — gerar texto plausível mas factualmente errado.
• O agente tem limite de tempo e tokens — uma cadeia muito longa pode ser truncada.

Por isso a etapa final não é só “entregar resposta”. É “entregar resposta ou interromper e pedir ajuda”. Um agente maduro sabe a diferença. Responder quando o contexto é insuficiente é pior do que perguntar.

Leitura relacionada

• O que é o agente Hermes e como ele funciona na prática — definição operacional do Hermes como camada de coordenação entre modelos e ferramentas.
• Harness de IA: a camada entre o modelo e o trabalho real — o harness como infraestrutura invisível que sustenta o agente em produção.
• Agente de IA não é chatbot: quando começa a agir — fronteira entre agente de verdade e chatbot com prompt elaborate.