A matriz de fusão
Agora você tem dois sistemas: o motor Alembic (Lição 1) e o Hermes Agent que você fez reverse-engineering (Lição 2). A matriz é a ponte — uma decisão item a item sobre o que fazer com cada capacidade do Hermes. Quatro verbos, uma regra cada, sempre julgada contra um mapa verificado, nunca de memória.
- Explicar as duas perguntas que decidem o destino de cada capacidade — e por que ambas são respondidas contra um mapa verificado.
- Distinguir os quatro verbos (CLONE · ADAPT · MERGE · IGNORE) e aplicar a regra de cada um.
- Justificar por que a coluna IGNORE vale tanto quanto a de construir — a matriz também é uma ferramenta de poda.
- Reconhecer por que o loop de aprendizado é a pedra angular, e por que ele virou ADAPT no envio.
- Que você leu (ou tem por perto) as Lições 1 e 2 — sabe o que é o motor Alembic e que o Hermes foi mapeado por reverse-engineering.
- Que você entende a ideia de uma
capacidade: uma habilidade isolada de um agente (memória, busca na web, delegação…). - Nada além disso. Os termos técnicos (
Result,gate,swarm,funnel) aparecem definidos quando importam.
A grande ideia
Imagine que você herdou a oficina de outro mecânico (o Hermes) e já tem a sua própria (o Alembic). Você não joga tudo da oficina herdada na sua, nem ignora tudo. Você pega cada ferramenta, uma de cada vez, e decide: levo igual? refaço do meu jeito? encaixo numa que já tenho? ou descarto porque a minha é melhor?
É isso que a matriz de fusão faz com as capacidades do Hermes. Ela não é uma lista de desejos — é uma planilha de decisões justificadas. Metade do valor está em dizer não com um motivo escrito.
O artefato real
A matriz vive em docs/alembic-hermes-fusion-matrix.md no monorepo. Sua estrutura: §1 a legenda dos verbos, §2 as quatro tabelas de veredicto, §3 as duas CLONEs-chave, §4 o esboço do pacote @alembic/hermes, §5 a ordem de implementação.
Cada veredicto é ancorado em contagens de hits sobre dois mapas verificados — não em impressão. A disciplina anti-fabricação é estrutural: o que não pôde ser confirmado foi marcado [uncertain] em vez de chutado.
O método: duas perguntas, um veredicto
Cada capacidade do Hermes passou por duas perguntas. E o ponto crucial: cada uma é respondida contra um mapa verificado — não de cabeça.
- Q1 — O Alembic já tem um equivalente? Respondida contra
docs/alembic-complete-map.md, com contagens de hits sobre o mapa e os pacotes nomeados como evidência. - Q2 — A versão do Hermes é superior ou inédita? Respondida contra
docs/hermes-complete-map.md.
O veredicto sai do par de respostas. O que não deu para confirmar foi marcado [uncertain] em vez de adivinhado.
Uma capacidade do Hermes existe no Alembic só de forma parcial (um equivalente diferente, incompleto). Qual dos quatro verbos isso provavelmente recebe?
Evidência, não impressão
A frase "contra um mapa verificado" é o coração do método. Em vez de "acho que o Alembic não tem busca na web", a matriz escreve web search=0 hits sobre docs/alembic-complete-map.md. Cada veredicto carrega esse número.
Isso transforma a fusão em algo auditável: qualquer pessoa pode reabrir o mapa, rodar a mesma contagem e checar a decisão. É a mesma disciplina de prova (Proof Gate) que o resto do Alembic aplica a código — aqui aplicada a decisões de arquitetura.
Os quatro verbos
Uma regra por verbo. Decore estas quatro linhas e você lê a matriz inteira.
As duas perguntas no topo abrem em quatro veredictos. Cada cartão traz a regra de uma linha do seu verbo.
| Verbo | Quando |
|---|---|
| CLONE | Inédito no Alembic; portar o design do Hermes de perto, adaptando os tipos a @alembic/*. |
| ADAPT | O Alembic tem um equivalente parcial / diferente; reimplementar a ideia do Hermes no estilo do Alembic. |
| MERGE | O Alembic já tem uma superfície relacionada; dobrar a capacidade do Hermes dentro dela — uma superfície mais rica. |
| IGNORE | O Alembic já faz tão bem ou melhor, ou está fora do escopo da missão. Sempre justificado. |
CLONE — os cinco inéditos de alto valor
Estes não têm equivalente no Alembic (o mapa mostra zero ou hits incidentais), então são portados de perto.
| Capacidade | Fonte no Hermes | Por que CLONE |
|---|---|---|
| Memória em arquivo (frozen-snapshot) | memory_tool.py §3.2 (1089 LOC) | MEMORY.md/USER.md limitados, injetados como um snapshot congelado no início da sessão. Fundamental para o loop de aprendizado. |
| Loop de auto-revisão (aprendizado) | background_review.py §1.10 | O mecanismo "auto-melhorável" de manchete — a maior lacuna do Alembic. (Enviado como ADAPT; veja o destaque adiante.) |
| Curator (ciclo de vida das skills) | curator.py + skill_usage.py §3.3 | active→stale→archived, nunca deleta. Dá controle de qualidade ao loop. |
| Busca / extração web | web_tools.py §3.1 (1377 LOC) | HTTP+JSON puro sobre múltiplos backends. Reforça a camada SOURCE do funil. |
| Clarify (humano-no-loop) | clarify_*.py §3.7 | Perguntas estruturadas + gateway bloqueante. Vira a superfície de "perguntar" do gate humano T4. |
Result, FsPort, Zod). E um veredicto pode mudar entre o plano e o envio.O esboço de @alembic/hermes (§4 da matriz)
@alembic/hermes memory/ # CLONE: snapshot congelado MEMORY.md/USER.md (memory_tool.py §3.2) web/ # CLONE: web_search / web_extract sobre HTTP+JSON (web_tools.py §3.1) clarify/ # CLONE: perguntas estruturadas + gateway bloqueante (clarify_*.py §3.7) curator/ # CLONE: ciclo active→stale→archived das skills (curator.py §3.3) review/ # o loop de aprendizado — entrou como ADAPT (ADR-0018)
A ordem de implementação (§5) começa por memory/ — "fundamental, fácil, zero binds externos" — porque o loop de aprendizado depende dela.
MERGE — dobrar numa superfície relacionada
Aqui o Alembic já tem uma superfície parecida. Em vez de criar uma nova, você funde a capacidade do Hermes dentro dela — uma superfície só, mais rica.
| Capacidade | Alembic hoje | Por que MERGE |
|---|---|---|
| Cliente MCP | O Alembic é um servidor MCP, read-only — sem cliente (MCP=8 hits) | Adicionar a capacidade de consumir servidores MCP externos. Alto valor; o SDK TS deixa isso mais limpo que o original em Python. Parado como follow-up, ainda não conectado. |
| Automação completa de browser | Envolve o agent-browser read-only (browser=13 hits) | Manter read-only como padrão; fundir a superfície de interação atrás de um opt-in explícito. |
| Autoria + telemetria de skills | Carrega skills (skill=22 hits) mas não tem autoria por agente | Fundir create/edit/patch dentro de loop-engineering para que skills feitas por agente alimentem o Curator. |
| Verifier / mixture-of-agents | verifier-panel do council (verifier=19 hits) | O quórum de N-lentes + veto do Alembic é o equivalente mais rico do MoA — mantém-se o do Alembic. |
ADAPT & IGNORE — o resto, justificado
ADAPT (equivalente parcial → reimplementar): session-search com FTS5, skills-hub, conceitos de kanban no swarm, blueprints de cron, transcrição em nuvem, análise de visão.
IGNORE — e a parte interessante é justamente a justificativa:
| Capacidade | Por que IGNORE |
|---|---|
Delegação de subagente (delegate_tool.py, 3188 LOC) | O swarm do Alembic (swarm=63 hits: orquestrador 3-tier, lead-worker, profundidade limitada, fila dependency-gated) já faz isso nativamente e melhor. Guarda-se um insight portável: na delegação assíncrona, "a conclusão reentra como um novo turno, nunca no meio do contexto". |
| Backends de terminal (6 contextos) | A factory do Alembic já entrega docker/podman/no-sandbox + isolamento por git-worktree. Redundante. |
| Computer use, TTS neural local, faster-whisper | Stacks de ML só-Python ou fora da missão distill→venture. Difíceis de portar, sem valor para a missão. |
| 23 adaptadores de plataformas de mensagens | O Alembic é um motor interno (ADR-0001), não um gateway de assistente pessoal. Os clientes L4 são API/MCP/CLI/cockpit — não Telegram/WhatsApp. |
A pedra angular: por que o loop de aprendizado fica acima de tudo
"O Alembic tem um funil de destilação e um gate de validação, mas nenhum loop fechado de auto-melhoria. O loop de aprendizado do Hermes é a peça que falta, e ele compõe com o que o Alembic já tem em vez de substituir."
O funil transforma fontes em Learnings — mas nada realimenta esses learnings de volta para o motor. O Hermes fecha esse ciclo. Dois motivos de ele encaixar tão bem:
- Encaixa na cintura estreita. A memória vive dentro do system prompt, congelada no início da sessão — exatamente a disciplina que mantém o cache de prefixo do prompt quente. O fork de revisão herda o prompt em cache, verbatim.
- Encaixa no pipeline de gates. O reviewer é, ele mesmo, gateável — as escritas passam pelo Validator Gate existente do Alembic antes de sedimentar. Isso dá o "aprenda só com vitórias validadas".
Hoje + Hermes = o loop fechado fundido. O reviewer propõe; o Validator dispõe; o curator mantém limpo.
AIAgent em Python para forquilhar como daemon thread, e auto-escrever burlaria o Validator Gate. Então o reviewer propõe e o Validator do Alembic dispõe. Essa nuance é a Lição 4.Por que a disposição mudou entre o plano e o código
O original do Hermes forquilha o próprio loop do agente como uma thread em background depois do run. No Alembic não há esse objeto AIAgent para forquilhar — a arquitetura é diferente. Portar "de perto" (CLONE) seria importar uma forma que não existe aqui.
Pior: deixar o reviewer escrever direto na memória/skills passaria por cima do Validator Gate, violando a invariante de que escritas duráveis são validadas. A solução (ADR-0018) separa os papéis: o reviewer propõe um patch; o Validator Gate dispõe (aprova/rejeita) antes de sedimentar. Resultado: "aprende só com vitórias validadas". É por isso que o veredicto correto, no código, é ADAPT — não CLONE.
Experimente — classifique a capacidade
Você é o arquiteto agora. Para cada capacidade do Hermes abaixo, escolha o verbo. O painel diz se acertou e por quê — com a evidência da matriz.
memory=1 hit incidental, sem pacote de memória. → praticamente inédito.@alembic/hermes → memory/.delegate_tool.py · 3188 LOCConfusões comuns
Result, FsPort, Zod). E um veredicto pode mudar entre plano e envio: o loop de aprendizado foi CLONE → ADAPT por razões de princípio.swarm=63 hits contra delegate_tool.py; a factory contra os backends de terminal; ADR-0001 (motor interno) contra os 23 adaptadores de mensagens. A recusa é tão ancorada quanto a construção.Recapitulando
Verifique
Três perguntas. O placar conta abaixo.
delegate_tool.py (delegação de subagente, 3188 LOC) recebe IGNORE. Por quê?swarm=63 hits — um orquestrador 3-tier com lead-worker, profundidade limitada e fila dependency-gated. IGNORE aqui é "já tão bom ou melhor", não "fora de escopo". Um insight portável é guardado: a conclusão reentra como um novo turno, nunca no meio do contexto.- A matriz é uma planilha de decisões justificadas, não uma lista de desejos.
- Cada capacidade passa por duas perguntas, ambas contra um mapa verificado.
- Quatro verbos: CLONE (portar) · ADAPT (refazer) · MERGE (encaixar) · IGNORE (recusar com motivo).
- A coluna IGNORE vale tanto quanto construir — é poda que mantém o foco do motor.
- O loop de aprendizado é a pedra angular e foi CLONE→ADAPT (o reviewer propõe, o Validator dispõe).