Hermes Agent: quando um agente começa a administrar seus agentes de desenvolvimento

TL;DR

O Hermes Agent virou o chefe de equipe dos meus agentes de código: ele decompõe o objetivo e decide se cada tarefa vai pro Codex, pro Claude Code ou pro OpenCode. Memória persistente, skills versionadas, MCP e subagentes paralelos mudaram meu fluxo de trabalho de raiz a ponta — e o caso real abaixo mostra o que isso produziu.

• O problema: três agentes excelentes e nenhum chefe — o gargalo era eu escolhendo quem faz o quê
• A solução: o Hermes como camada de orquestração com memória, skills, MCP e subagentes
• O resultado: um objetivo de cinco linhas virou um relatório consolidado com três agentes rodando em paralelo

~ 11 min de leitura · 1871 palavras

O problema de ter três agentes excelentes

Codex programa. Claude Code programa. OpenCode programa. Mas quem decide qual deles deveria executar cada tarefa?

Essa pergunta me perseguiu durante meses. Eu tinha três agentes de código excelentes instalados na máquina e me peguei fazendo na mão o trabalho que nenhum deles deveria fazer: escolher quem faz o quê. Abro o Codex pra escrever aquela função, colo o resultado no Claude Code pra revisar, depois rodo o OpenCode pro refactor. Entre uma janela e outra, o contexto se perdia, eu repetia instruções que já tinha dado e a tarde virava gerenciamento de terminal em vez de engenharia.

O ponto que me obrigou a admitir o problema foi um refactor de módulo fiscal do nosso ERP. Tarefa pequena: extrair a validação de CFOP pra uma classe própria. Eu deleguei pro Codex, que entregou um resultado decente mas sem noção das regras que vivem em comentários espalhados pelo sistema. Copiei pro Claude Code pedir uma segunda passada — e ele reescreveu trechos que o Codex tinha acertado de primeira. Três janelas, dois agentes ótimos, zero progresso líquido.

O problema não era os agentes. Era eu. Tinha três excelentes e nenhum chefe.

O que é o Hermes Agent

O Hermes Agent é uma camada de orquestração de agentes. Ele não substitui o Codex, o Claude Code ou o OpenCode — ele os administra. Eu descrevo um objetivo, e o Hermes decompõe esse objetivo em tarefas, decide qual agente executa cada uma, distribui o trabalho, acompanha e agrega os resultados de volta.

A primeira vez que eu usei dessa forma, a sensação foi parecida com a transição de programar sozinho pra liderar um time. Quando eu era o único dev, todo o contexto vivia na minha cabeça. Quando o time cresceu, precisei aprender a escrever briefing, definir critério de pronto e confiar na execução sem revisar linha por linha. O Hermes me forçou a fazer o mesmo com os meus agentes de código.

E tem um detalhe que muda o jogo: o Hermes não é burro na hora de escolher. Uma tarefa de arquitetura ele roteia pro arquiteto engenheiro sênior. Uma decisão de estratégia ou ROI, pro estrategista de negócios. Infra e segurança vão pro especialista correspondente. Esse roteador de profiles existe porque tarefa de código e decisão de negócio pedem cabeças diferentes — e eu já perdi tempo demais tentando fazer o mesmo agente ser bom nas duas coisas.

Memória persistente e skills

A segunda coisa que o Hermes mudou foi a memória — e essa foi a mais demorada pra eu entender o valor.

Toda sessão de agente que eu tinha rodado até então era um recomeço. Fechei o terminal, o contexto morreu. Abri de novo, expliquei o projeto do zero: qual sistema, qual stack, quais regras, o que não mexer. Nas primeiras semanas com agentes de código, eu gastava mais tokens re-explicando o ERP do que executando a tarefa em si.

O Hermes tem memória persistente. O que eu conto pra ele numa sessão ainda está lá na próxima. Decisão de arquitetura que documentei em março, ele lembra em setembro. Isso soa banal até você medir quanto tempo a gente perde reconstituindo contexto — no meu caso, eram minutos por sessão, todos os dias.

Em cima da memória vem o conceito de skills: procedimentos versionados por tipo de tarefa. Um playbook de como revisar PR, outro de como diagnosticar serviço Linux caído, outro de como configurar HAProxy com rollback. Eu escrevi a skill uma vez, testei, ajustei — e agora toda vez que o Hermes encontra uma tarefa daquele tipo, ele segue o procedimento em vez de improvisar.

Isso é parecido com o que times maduros fazem com runbooks, com uma diferença que me pegou de surpresa: a skill é executável. O agente lê o procedimento e segue. Quando eu escrevia runbook pra humano, eu sabia que metade do time pulava o passo 4. O Hermes não pula — e se o passo 4 estiver errado, ele falha do mesmo jeito que o humano teria falhado, só que mais rápido e com log. Descobri dois bugs nas minhas próprias skills assim, no primeiro mês.

MCP e a caixa de ferramentas que atravessa agentes

MCP é o Model Context Protocol — um padrão aberto que conecta modelos a ferramentas externas. No meu setup, MCP virou a caixa de ferramentas que atravessa todos os agentes.

Antes do MCP, cada agente tinha suas integrações isoladas. O que o Claude Code conseguia acessar, o Codex não acessava. Se eu queria que um agente lesse um banco, outro buscasse uma issue no GitHub e um terceiro postasse um comentário, eu precisava configurar cada um separadamente, e nem sempre era possível.

Com MCP, uma ferramenta configurada uma vez fica disponível pra todos. GitHub, Postgres, busca na web, e-mail, acesso ao filesystem do projeto — o Hermes expõe tudo isso pra qualquer agente que estiver trabalhando naquela sessão. O agente de código não precisa “saber” usar o GitHub; ele chama a ferramenta, e o MCP resolve.

Eu já tinha investido tempo demais em colar resultados de uma janela na outra, então quando essa camada começou a funcionar foi um alívio quase físico. O Codex termina uma task, o Hermes verifica o diff no repositório, o agente de revisão abre o PR com o contexto do que foi mudado. Nenhum humano copiando nada. Eu me lembro de sorrir quando vi a primeira PR aberta por um agente com a justificativa escrita do jeito que eu teria escrito — exceto que eram 2h da manhã e eu estava dormindo.

Subagentes e delegação: o Hermes como chefe de equipe

Aqui entra a peça que consolidou o modelo: subagentes.

O Hermes pode delegar parte do trabalho pra instâncias isoladas, cada uma com contexto próprio. Um subagente recebe a tarefa, o contexto necessário pra executá-la — e só isso — e roda de forma independente. Ele não vê o resto do projeto, não vê as outras tarefas, não vê o histórico completo. Vê o problema que tem que resolver.

Isso resolve um problema que eu não tinha nem nomeado ainda: a janela de contexto como gargalo. Quando eu passava o projeto inteiro pra um agente, o contexto inchava e a qualidade da execução caía no final. Contexto demais é quase tão ruim quanto contexto de menos. O subagente com contexto próprio evita isso — cada tarefa carrega só o que precisa.

A analogia que funciona pra mim é a de um chefe de equipe que sabe delegar. Ele não entrega o projeto inteiro pro estagiário, nem o detalhe operacional pro arquiteto. Ele traduz o objetivo em tarefas do tamanho certo e com o briefing certo pra cada executor. O Hermes faz exatamente isso, e o briefing é a parte que eu mais reviso hoje em dia — porque descobri que a qualidade da delegação define a qualidade do resultado, igual a times de gente.

E igual a times de gente, às vezes ele erra na delegação. Nas primeiras semanas, vi tarefas mal divididas e subagentes duplicando esforço. Foi lendo essas falhas que eu aprendi a escrever objetivos melhores. A culpa, de novo, era minha — o executor executa; o objetivo, quem escreve sou eu.

Execução paralela e automação

O subagente isolado já seria uma boa evolução. A combinação com execução paralela é o que muda a escala de verdade.

Como cada subagente tem contexto próprio, vários podem rodar simultâneos sem tropeçar uns nos outros. O Hermes distribui as tarefas e acompanha todas ao mesmo tempo. Uma tarefa de escrita de teste, uma de revisão de documentação, uma de diagnóstico de bug, outra de configuração — todas avançando em paralelo enquanto eu reviso o resultado de uma quinta.

O tempo de resposta em tarefas independentes caiu de forma que eu não consigo mais voltar atrás. Antes, se eu tivesse três pendências independentes, eu resolvia uma por vez, cada uma com sua sessão e seu contexto. Agora eu descrevo o objetivo, o Hermes decompõe em quatro tarefas, distribui pro Codex, pro Claude Code, pro OpenCode e pra um subagente de diagnóstico — e eu só interviu onde minha decisão é necessária.

E tem o cron. O Hermes agenda tarefas recorrentes de forma independente: health check de serviços, verificação de monitoramento, digest de ataques no HAProxy. Quando eu acordo, o relatório já está pronto. O agente de infra executou às 6h, o de segurança às 7h, e eu leio os resultados com café, decidindo o que precisa de mim e ignorando o resto.

Isso me lembrou de quando comecei a automatizar backups na época do DOS e parei de pensar neles pra sempre. Automação de verdade é aquela que você esquece que existe — até o dia que ela te salva.

O cenário completo: um objetivo entra, tarefas saem distribuídas

O jeito mais honesto de fechar é descrever o cenário completo de um objetivo real que passei pro Hermes semana passada. Um cliente pediu uma auditoria de performance do módulo de faturamento do ERP, com recomendações de infra pra aguentar o aumento de carga do fechamento.

Eu escrevi o objetivo em cinco linhas. O Hermes leu, e a primeira coisa que fez foi rotear: tarefa de arquitetura de código → arquiteto engenheiro sênior; decisão de infra e custo de escalar → estrategista de negócios; revisão de segurança das mudanças propostas → especialista. Três profiles, escolhidos sem eu dizer nada.

Depois ele decompôs. Separou o trabalho em: análise de código do módulo, diagnóstico de infra, e uma revisão de coerência das recomendações. Cada sub-tarefa foi delegada pra um subagente com contexto próprio — o subagente de código recebeu o caminho do módulo e as skills de análise de performance; o de infra recebeu as métricas atuais do servidor e as skills de diagnóstico; o de revisão recebeu só o critério de pronto.

Os subagentes rodaram em paralelo. O de código usou as ferramentas MCP pra ler o repositório e executar queries no banco. O de infra cruzou métricas de carga e consultou as skills de dimensionamento. O Hermes acompanhou os três, agregou os resultados e me devolveu um relatório consolidado: três achados de performance, dois gargalos de infra, uma recomendação de mudança arquitetural com trade-offs escritos do jeito que eu pediria pra um consultor sênior.

Eu revisei o relatório, ajustei uma recomendação e aprovei. Total do meu tempo: a escrita do objetivo, a revisão e a decisão. O resto foi o Hermes chefiando os meus três agentes de código, cada um no que faz melhor, com memória do projeto, skills que eu escrevi e ferramentas que atravessam todos eles.

Leitura relacionada

• O que você pode fazer com o agente Hermes no trabalho e na empresa — casos de uso além do código: operação, monitoramento e gestão que sustentam essa camada de orquestração no dia a dia.
• OpenAI Codex: o terminal virou um ambiente de desenvolvimento — background do Codex, um dos executores que o Hermes orquestra, e por que o terminal ganhou esse papel.
• Claude Code: desenvolvimento orientado por contexto — por que contexto estruturado é o ativo mais valioso em desenvolvimento assistido, a mesma tese que os subagentes do Hermes aplicam.