A tecnologia por trás do Hermes: modelos, ferramentas, memória e orquestração

TL;DR

O modelo de linguagem é só uma peça. Por trás de um agente existe uma arquitetura em camadas: orquestrador, contexto, memória, ferramentas, validação. A qualidade do trabalho depende menos do modelo e mais da engenharia ao redor dele.

• Um agente moderno combina modelo, orquestrador, contexto, memória e ferramentas em camadas distintas.
• O modelo interpreta e gera conteúdo. As outras camadas decidem o que pedir a ele.
• Dois sistemas com o mesmo modelo podem ter resultados muito diferentes dependendo da arquitetura ao redor.

O que existe “por trás” de um agente

“Por trás” não é o mesmo que “dentro do modelo”. Confundir as duas coisas é o erro mais comum quando se descreve como um agente funciona.

Um modelo de linguagem é uma peça específica do quebra-cabeça. Ele recebe texto, transforma em texto, com alta probabilidade contextual. Mas o modelo, sozinho, não decide nada. 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 no turno anterior, não sabe quando parar para pedir ajuda.

Essas decisões vivem em uma camada acima do modelo. É essa camada que transforma um modelo de linguagem em um agente. O nome genérico é “orquestrador”, mas a ideia é simples: existe um componente que planeja, escolhe, valida e decide o próximo passo em nome do usuário.

A confusão entre “agente” e “modelo” aparece toda vez que alguém diz “estamos usando IA” sem distinguir se está rodando um chatbot puro (modelo + prompt) ou um sistema completo (modelo + orquestrador + ferramentas). São produtos diferentes, com capacidades e limites diferentes. Um modelo bom sem orquestrador vira resposta genérica. Um orquestrador competente com modelo médio pode entregar trabalho útil.

Aprofundar essa distinção é entender as camadas da arquitetura.

As camadas da arquitetura

Um agente moderno é organizado em camadas que se sobrepõem. Cada camada tem uma responsabilidade clara, e as camadas se comunicam por interfaces bem delimitadas. A lista a seguir não é uma implementação específica — é a anatomia conceitual que qualquer sistema desse tipo precisa ter em alguma medida.

As camadas da arquitetura conceitual:

• Modelo de linguagem — interpreta texto e gera saída em linguagem natural.
• Orquestrador — planeja etapas, escolhe o que pedir a cada camada, decide quando parar.
• Prompt de sistema — define comportamento, regras, tom e limites do agente.
• Contexto — o que o modelo vê agora: histórico, ferramentas, mensagens injetadas.
• Memória de curto prazo — a conversa atual, volátil, finita, regenerada a cada turno.
• Memória persistente — preferências, regras, skills, decisões que sobrevivem entre sessões.
• Ferramentas — terminal, leitura/escrita de arquivos, busca, execução de código, navegação.
• Function calling — protocolo pelo qual o orquestrador pede ao modelo uma chamada estruturada.
• Ambiente de execução — onde as ferramentas rodam (mesmo processo ou subprocesso).
• Sandbox — camada de isolamento com permissões restritas.
• Registro de operações — log persistente de tudo que aconteceu.
• Validação — fechamento do ciclo, verifica se objetivo foi atendido.
• Recuperação de informações — banco vetorial, busca textual, web search, leitura de arquivos.
• Subagentes — instâncias isoladas para subtarefas, devolvem resumo ao orquestrador.
• Regras de segurança — limites de ação, confirmação humana, auditoria.

A camada mais visível é o modelo de linguagem. Ele é responsável por duas coisas: interpretar o que foi pedido e gerar o texto de resposta. É a peça que dá ao sistema a capacidade de “entender” e “falar”. Mas ele é determinístico-estatístico — produz a saída mais provável dado um contexto, sem raciocínio explícito passo a passo.

Logo acima do modelo mora o orquestrador. Ele é o componente que toma decisões. Recebe a solicitação, monta o contexto, escolhe o que pedir ao modelo, decide quando acionar uma ferramenta, lê o resultado, decide o próximo passo. O orquestrador é o que diferencia um agente de um chatbot.

O prompt de sistema é o contrato de comportamento. É o texto que define quem é o agente, quais regras ele deve obedecer, qual o tom de voz, quais limites não devem ser cruzados. O prompt é carregado a cada turno, junto com o histórico e a solicitação do usuário.

O contexto é tudo que o modelo precisa ver para gerar a boa resposta: a solicitação atual, o histórico recente, o prompt de sistema, o resultado da última ferramenta, mensagens injetadas pelo orquestrador. O contexto é a “memória de curto prazo” do turno.

A memória propriamente dita tem duas modalidades. A de curto prazo é o contexto da conversa atual — volátil, finito, regenerado a cada turno. A persistente é o que sobrevive entre sessões — preferências do usuário, regras operacionais, skills instaladas, decisões registradas. São sistemas diferentes com custos e confiabilidades diferentes.

As ferramentas são o que permitem ao agente agir fora do texto. Terminal, leitura e escrita de arquivos, busca web, execução de código, navegação em interface, envio de email, upload de imagens. As ferramentas ampliam o o raio de ação do modelo e dão concretude às decisões do orquestrador.

O function calling é o protocolo pelo qual o orquestrador pede ao modelo que produza uma chamada de ferramenta em vez de texto puro. O modelo gera uma estrutura tipo `{ “ferramenta”: “buscar_arquivo”, “parametros”: {…} }`, e o orquestrador executa essa chamada, lê o resultado, e injeta de volta no contexto para a próxima iteração.

O ambiente de execução é onde as ferramentas rodam. Pode ser o mesmo processo do agente, ou um subprocesso isolado. Quando é isolado com permissões restritas (sistema de arquivos limitado, rede filtrada, sem acesso a segredos), vira um sandbox.

O registro de operações é o log persistente de tudo que aconteceu. Cada chamada de ferramenta, cada resposta, cada erro. Sem log, debugging e auditoria ficam cegos.

A validação é o que fecha o ciclo. Após cada resultado, o sistema verifica se o objetivo foi atendido, se a saída tem a forma esperada, se há erro, se faz sentido seguir. Quando a validação falha, o ciclo volta — reformula a pergunta, refaz a chamada, escala para o humano.

A recuperação de informações é o conjunto de mecanismos que permitem ao agente buscar o que não está no contexto imediato: banco vetorial, busca textual, leitura de arquivos, web search. É o que permite ao agente responder perguntas sobre o que aconteceu em sessões passadas ou sobre o mundo fora dele.

Os subagentes são extensões do orquestrador. Cada subagente é uma instância nova, com contexto isolado, que trabalha em uma subtarefa e devolve um resumo. O orquestrador decide quando vale a pena o overhead de criar um subagente versus resolver direto.

Por fim, as regras de segurança definem o que o agente pode ou não fazer: quais comandos não executar, quais URLs não acessar, quais arquivos não ler, quais ações pedir confirmação humana antes de prosseguir.

Cada camada tem um papel específico. A qualidade do agente depende de todas elas funcionarem bem — não só do modelo.

O fluxo operacional de uma solicitação

Uma solicitação típica passa pelo seguinte caminho: o usuário envia uma mensagem. O orquestrador recebe, interpreta a intenção, monta o contexto relevante (histórico + memória persistente + skills carregadas). Pede ao modelo que avalie o que precisa ser feito. O modelo pode devolver texto direto (resposta simples) ou uma chamada de ferramenta (ação necessária). Se for uma chamada, o orquestrador executa, lê o resultado, injeta de volta no contexto, e pede ao modelo para continuar. Esse ciclo pode rodar várias vezes antes de uma resposta final.

A sequência conceitual é sempre a mesma:

1. Solicitação — o usuário envia uma mensagem ou aciona uma tarefa. 2. Orquestrador — recebe e interpreta a intenção real. 3. Contexto — monta histórico, memória persistente, skills, ferramentas disponíveis. 4. Modelo — recebe o contexto e decide entre texto direto ou chamada de ferramenta. 5. Ferramenta — executada em ambiente isolado (sandbox) com permissões definidas. 7. Resultado — injetado de volta no contexto para a próxima iteração. 8. Validação — verifica formato, qualidade, e se o objetivo foi atendido. 9. Resposta — texto final entregue ao usuário, com metadados quando aplicável.

O que varia é a profundidade: uma pergunta simples pode rodar só os primeiros nós, uma tarefa complexa pode rodar o ciclo dezenas de vezes, com múltiplas ferramentas, múltiplas validações e, eventualmente, intervenção humana.

O fluxo parece simples no papel. Na prática, é onde mora a complexidade do sistema. Cada nó pode falhar, cada nó pode pedir revisão, cada nó pode ser expandido em uma sub-árvore quando a tarefa é grande demais.

Modelo de linguagem: a peça visível

É a peça mais fácil de vender — é onde mora o “raciocínio”. Mas é também a peça que tem menos controle direto: o modelo decide token a token qual saída produzir, e o sistema só influencia via contexto, prompt e amostragem.

A escolha do modelo é importante — capacidade, latência, custo, comportamento esperado — mas nenhum modelo substitui uma arquitetura ruim. Dois sistemas com o mesmo modelo podem ter comportamentos radicalmente diferentes dependendo do resto.

A tendência da indústria é tratar o modelo como commodity e investir cada vez mais na engenharia ao redor. É coerente: o modelo é uma peça que evolui rápido, mas a arquitetura é o que diferencia um sistema útil de um brinquedo.

Orquestrador: quem decide o que fazer

O orquestrador é o componente menos visível para o usuário final, mas é o que mais importa para o resultado. É ele que decide se vale a pena pesquisar, se vale a pena chamar uma ferramenta, se vale a pena escalar para o humano.

Um orquestrador competente sabe a diferença entre uma pergunta direta (responder agora) e uma tarefa complexa (planejar, executar em etapas, validar cada etapa). Sabe quando parar para pedir mais contexto. Sabe quando interromper a cadeia porque o custo está ficando alto demais. Sabe quando o erro do modelo é plausível demais para confiar.

A qualidade do orquestrador é proporcional à qualidade dos seus critérios de parada, dos seus hooks de validação, e da sua disciplina em manter a separação entre “modelo decide o texto” e “orquestrador decide a ação”.

Contexto, memória e prompt de sistema

Contexto é o que o modelo vê agora. Memória persistente é o que ele já viu em outras sessões. Prompt de sistema é quem ele é. As três coisas juntas definem a “personalidade operacional” do agente em cada turno.

A limitação prática é o tamanho do contexto. Modelos têm janelas finitas — alguns milhares, centenas de milhares, ou milhões de tokens, dependendo do modelo. O orquestrador precisa decidir o que entra e o que fica de fora. Cabe a ele escolher entre resumir histórico, carregar memória seletiva, ou simplesmente cortar e pedir continuação.

A memória persistente é mais confiável porque é registrada explicitamente, mas precisa ser mantida: preferências mudam, regras ficam desatualizadas, dados ficam obsoletos. Um sistema maduro revisa a memória persistente periodicamente — não acumula lixo para sempre.

Ferramentas, function calling e sandbox

Ferramentas são o que diferencia o agente do chatbot. Um modelo que pode chamar terminal e ler arquivos é qualitativamente diferente de um modelo que só produz texto. A diferença é concreta: um pode inspecionar o sistema, o outro só pode falar sobre ele.

O function calling é o protocolo. O sandbox é o isolamento. A combinação dos dois dá ao sistema um raio de ação real, com contenção de risco: pode fazer muito, mas dentro de limites explícitos.

A escolha de quais ferramentas oferecer é uma decisão de produto. Muitas ferramentas ampliam o raio mas aumentam a chance de erro e o custo de validação. Poucas ferramentas limitam a utilidade mas mantêm o sistema previsível. O ponto de equilíbrio depende do tipo de trabalho que o agente vai fazer.

Validação, subagentes e segurança

Validação é o que fecha o ciclo. Sem ela, o agente produz texto plausível que pode estar errado, e propaga o erro para a próxima etapa. Com ela, cada nó de saída é checado antes de virar entrada do próximo nó.

Validações comuns em produção:

• Formato — a saída tem a estrutura esperada (JSON, XML, schema declarado)?
• Domínio — os valores fazem sentido (URL válida, data no formato certo, faixa numérica)?
• Negócio — a regra de negócio foi respeitada (cálculo bate, limite respeitado)?
• Coerência — a resposta faz sentido dentro do contexto da conversa?
• Verificação cruzada — comparar com fonte externa ou resultado independente.

Quando a validação falha, três caminhos são possíveis: corrigir localmente (refazer a chamada), escalar para o orquestrador (reformular a estratégia), ou parar e pedir ajuda humana. A escolha depende do tipo de erro e do custo de cada caminho.

Subagentes são extensões. Cada um opera em contexto isolado, faz sua parte, devolve resumo. O custo é alto (criar instância nova, copiar contexto, esperar), então só vale a pena para subtarefas grandes ou paralelizáveis. O critério prático é o tempo esperado: subtarefa maior que ~30 segundos de cadeia linear geralmente vale um subagente.

Segurança é o que mantém o sistema dentro de limites. Regras explícitas sobre o que não fazer, confirmação humana para ações com risco, auditoria de tudo que aconteceu. Não é opcional em sistemas que agem no mundo real — é pré-condição para confiança operacional.

Leitura relacionada

• O que é o agente Hermes e como ele funciona na prática — definição operacional do Hermes como camada de coordenação, não como modelo.
• Como funciona o agente Hermes por dentro — o fluxo interno em dez etapas, do objetivo entregue à resposta validada.
• 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.