🗺️ Mapa do sistema — todos os componentes e conexões
Antes de escalar o Triad, você precisa enxergar o sistema inteiro de uma vez. Hermes + Triad não é um único agente — é uma rede de cinco peças que se conversam através de protocolos bem definidos. Esse mapa é a base de todas as decisões de extensão.
O que é
O mapa do sistema é a visão panorâmica de todos os componentes do ecossistema TRIAD — Hermes (orquestrador), Pantheon (interface de personas), soul.md (contexto pessoal), Skills (como Orpheus), OpenRouter (roteador de modelos) e Gemini CLI (ferramenta multimodal) — junto com as conexões que os ligam.
📐 Diagrama panorâmico do sistema
┌─────────┐
│ User │
└────┬────┘
│
┌──────▼──────┐
soul.md ──▶│ Hermes │◀── Pantheon
(context) │ (orchestr.) │ (personas)
└──┬───────┬──┘
│ │
┌────────▼─┐ ┌─▼─────────┐
│ Skills │ │ Tools │
│ (Orpheus,│ │ (Gemini │
│ ...) │ │ CLI,...) │
└────┬─────┘ └───────────┘
│
┌─────▼──────┐
│ Triad Loop │
└─┬────┬───┬─┘
│ │ │
Opus DSV4 GPT
│ │ │
└────┴───┘
│
▼
OpenRouter
(model layer)
Orquestrador central. Recebe o pedido, decide qual skill invocar, monta contexto e devolve a resposta final ao usuário.
Interface de personas e skills. É como o Hermes "vê" o catálogo de capacidades disponíveis.
Fonte única de contexto pessoal. Hermes lê toda vez para conhecer o usuário, suas preferências e histórico.
Camada de abstração que roteia chamadas para Opus, DeepSeek V4, GPT, etc., com fallback automático.
Ferramenta multimodal — vídeo, imagem e áudio — invocada como tool quando o Triad precisa de mídia.
O loop Condutor → Worker → Crítico que toda skill séria (como Orpheus) executa para garantir qualidade.
🔑 Conceitos-chave
TRIAD é uma rede de componentes, não um único modelo gigante
Toda extensão começa por localizar onde no mapa ela se encaixa
Cada componente conversa com os outros por contratos explícitos, não acoplamento direto
Tudo passa pelo Hermes — ele é o ponto de entrada e saída
🎯 Hermes como orquestrador central — o que ele controla
Hermes não pensa pelo Triad — ele decide quem pensa, em que ordem, com qual contexto. Entender isso evita o erro clássico de tentar fazer o Hermes raciocinar quando o papel dele é roteamento.
O que é
Hermes é o orquestrador de toda a interação. Ele recebe a entrada do usuário, consulta soul.md para contexto, decide qual skill do Pantheon invocar, monta o briefing inicial, repassa controle, e finalmente compõe a resposta final que volta ao usuário.
🧭 As 5 responsabilidades de Hermes
- •Parsing da intenção: traduz o pedido em linguagem natural num intent estruturado.
- •Carregamento de contexto: lê soul.md e injeta o que for relevante para o intent.
- •Seleção de skill: escolhe do Pantheon a skill ou persona certa para o intent.
- •Despacho e supervisão: invoca a skill, monitora execução, captura sinais como PARTIAL_DELIVERY.
- •Composição da resposta: integra o output da skill com tom e formato adequados ao usuário.
✗ Hermes mal usado
- ✗Hermes tentando ser Condutor, Worker e Crítico ao mesmo tempo
- ✗Lógica de negócio embutida no orquestrador
- ✗Hermes "decidindo" o resultado em vez de delegar
- ✗Contexto criado dentro do Hermes (não em soul.md)
✓ Hermes bem usado
- ✓Roteia, mas não raciocina sobre o domínio
- ✓Lê soul.md, escolhe skill, devolve resposta
- ✓Trata sinais de erro (PARTIAL, REVISE_LOOP) com regra clara
- ✓Mantém prompts pequenos — toda lógica grande vai para skills
🔑 Conceitos-chave
Hermes roteia — o raciocínio mora nas skills
Parsing, contexto, seleção, despacho, composição — nada além disso
Hermes captura PARTIAL_DELIVERY, REVISE, FUNDAMENTAL FLAW e age
Quanto mais lógica no Hermes, mais frágil o sistema todo
🔀 OpenRouter como camada de abstração de modelos
Acoplar uma skill direto a "Opus" é uma armadilha de longo prazo. OpenRouter desacopla papel de provedor — você pede "modelo classe Condutor" e o roteador decide qual chamar baseado em custo, disponibilidade e fallback.
O que é
OpenRouter é a camada que abstrai chamadas a modelos — Opus, DeepSeek V4, GPT-4, Mistral, etc. — atrás de uma única API. Permite trocar provedores sem alterar o código das skills, aplicar fallbacks automáticos quando um modelo falha, e centralizar controle de custos.
📐 Diagrama da camada de modelos
Skill (Orpheus)
│
│ request: { role: "conductor", task: ... }
▼
┌──────────────────┐
│ OpenRouter │ ◀── policy: cost, latency, fallback
└────┬─────┬─────┬─┘
│ │ │
▼ ▼ ▼
┌────┐┌────┐┌────┐
│Opus││DSV4││ GPT│
└────┘└────┘└────┘
│ │ │
└─────┴─────┘
│
▼
response → Skill
💡 Por que importa
Sem OpenRouter, trocar Opus por outro modelo significa reescrever toda a skill. Com ele, você muda uma linha de configuração. É a diferença entre um sistema que envelhece bem e um que precisa ser refeito a cada novo modelo.
🔑 Conceitos-chave
Skill pede um papel ("conductor"), não um modelo específico
Se o modelo primário falha, OpenRouter tenta o secundário sem intervenção
Todos os custos passam por um único ponto — auditoria e rate limit ficam triviais
Trocar provedor = mudar config, não mudar código
📄 soul.md como fonte única de contexto pessoal
Espalhar contexto pessoal em vários lugares é a forma mais rápida de criar inconsistência. soul.md é a fonte única da verdade sobre o usuário — preferências, histórico, restrições, vocabulário próprio. Todo componente lê dali; ninguém escreve em paralelo.
O que é
soul.md é um arquivo markdown único que descreve o usuário em primeira pessoa — identidade, projetos ativos, preferências de comunicação, regras de colaboração, decisões já tomadas e vocabulário. Funciona como o "manual do usuário" que Hermes lê em toda interação.
📂 Estrutura típica de soul.md
soul.md
├── # Identidade
│ nome, papel, tom preferido
├── # Projetos ativos
│ TRIAD, AutomationsAI, ...
├── # Regras de colaboração
│ "responder em PT-BR", "nunca usar AskUserQuestion"
├── # Decisões já tomadas
│ ADRs informais, escolhas técnicas
└── # Vocabulário
Condutor, Worker, Crítico, soul, pantheon
💡 Por que arquivo único
Múltiplos arquivos de contexto = múltiplas fontes da verdade = inconsistência inevitável. Um único soul.md força você a manter coerência — se duas regras se contradizem, isso vira visível na hora da edição.
🔑 Conceitos-chave
Um arquivo, uma verdade — sem cópias paralelas
soul.md é editado por humano, não por modelo — preserva intenção
Todos os componentes falam a mesma língua técnica
Só o Hermes lê soul.md — as skills recebem o recorte relevante
🎼 O Pantheon como interface de controle de personas
Pantheon é o catálogo navegável de skills e personas. Sem ele, Hermes precisaria conhecer cada skill por nome — o que mata extensibilidade. Com Pantheon, adicionar uma nova capacidade é registrar uma entrada, sem tocar no código do orquestrador.
O que é
Pantheon é o registry de skills e personas disponíveis para Hermes. Cada entrada descreve uma capacidade — nome, descrição, triggers, entradas esperadas e modelo recomendado — de forma que Hermes pode escolher dinamicamente sem hardcode.
📐 Pantheon como camada de descoberta
Hermes
│
│ "preciso de skill que: analise mercado"
▼
┌─────────────────────────┐
│ Pantheon │
│ ┌───────────────────┐ │
│ │ Orpheus (Triad) │ │ ← match
│ │ MarketScout │ │
│ │ DocWriter │ │
│ │ CodeReviewer │ │
│ │ ... │ │
│ └───────────────────┘ │
└────────────┬────────────┘
│
▼
Skill instance
Capacidade técnica — Orpheus, DocWriter. Executa uma tarefa, geralmente via Triad loop interno.
Estilo + atitude — "estrategista", "professor", "pair-programmer". Modula tom da resposta.
Padrão de intent que aciona a skill. Pode ser palavra-chave, regex ou descrição semântica.
Conjunto de entradas Pantheon. Adicionar skill = adicionar entrada, sem tocar Hermes.
🔑 Conceitos-chave
Skills se anunciam, Hermes descobre — sem hardcode
Skill = capacidade técnica, persona = estilo de entrega
Nova skill = nova entrada no registry, deploy zero no Hermes
Cada skill declara quando deve ser usada — Hermes só faz match
🎬 Gemini CLI como ferramenta multimodal no ecossistema
O Triad é forte em texto, mas mídia exige tools especializadas. Gemini CLI entra como ferramenta multimodal — análise de imagem, vídeo, áudio — invocada pelas skills quando o briefing exige percepção além de texto.
O que é
Gemini CLI é uma ferramenta de linha de comando que dá acesso ao Gemini para tarefas multimodais — descrever imagens, transcrever áudio, sumarizar vídeo. No TRIAD ele é tratado como tool: chamado por skills, com input/output bem definidos, nunca como orquestrador.
🔧 Quando uma skill chama Gemini CLI
- •Análise visual: descrever um screenshot, identificar UI, ler diagrama.
- •Transcrição de áudio: converter reunião gravada em texto para o Condutor processar.
- •Sumarização de vídeo: dar ao Triad o "miolo" de um vídeo sem precisar assistir tudo.
- •Verificação multimodal: o Crítico pode pedir leitura visual de um asset entregue.
🧩 Gemini CLI como cidadão do sistema
Skill (ex: Orpheus)
│
│ task: "analise este vídeo de demo e
│ liste 5 pontos de fricção UX"
▼
┌──────────────────┐
│ Triad Loop │
│ ┌────────────┐ │
│ │ Conductor │──┼──▶ briefing
│ └────────────┘ │
│ ┌────────────┐ │
│ │ Worker │──┼──▶ tool: gemini-cli (vídeo)
│ └────────────┘ │ ▲
│ ┌────────────┐ │ │ multimodal
│ │ Critic │ │ ▼
│ └────────────┘ │ resumo + tags
└──────────────────┘
🔑 Conceitos-chave
Gemini CLI é chamado por skills, nunca decide o fluxo
Só aciona quando o briefing exige mídia
Input e output via arquivo/stdout, fácil de testar e auditar
O Crítico pode pedir verificação visual via Gemini antes de SHIP
🔁 Fluxo completo de uma tarefa do início ao fim
Ver os componentes isolados não basta — você precisa rastrear uma tarefa real percorrendo o sistema inteiro. Esse é o teste de compreensão: se você consegue seguir cada salto, você entende o sistema.
O que é
O fluxo end-to-end é o caminho que uma tarefa percorre — desde o input do usuário até a resposta final — atravessando Hermes, soul.md, Pantheon, a skill escolhida, o Triad loop interno (Condutor → Worker → Crítico) e voltando.
User envia pedido
"Quero três ângulos estratégicos para entrar no mercado local de odontologia premium." — Entra no Hermes.
Hermes parseia intent e carrega soul.md
Identifica intent: "análise estratégica de mercado". Lê soul.md, recorta seção "negócios ativos" e "vocabulário".
Hermes consulta Pantheon e seleciona Orpheus
Trigger "análise estratégica" mapeia para Orpheus (skill Triad). Hermes invoca passando intent + contexto.
Orpheus aciona o Triad — Condutor monta briefing
Via OpenRouter, classe "conductor" → Opus. Condutor produz briefing com critérios mensuráveis e 3–5 ângulos.
Worker drafta ângulos com premissa diferente
Via OpenRouter, classe "worker" → DSV4. Produz drafts com raciocínio visível, sem julgar qual é melhor.
Crítico avalia — REVISE ou SHIP
Via OpenRouter, classe "critic" → GPT. Compara contra critérios do briefing. Pode iterar (REVISE) ou aprovar (SHIP).
Hermes compõe resposta final e devolve ao user
Recebe output SHIPped, aplica tom de soul.md ("terse like caveman"), devolve resposta ao usuário.
📐 Diagrama do fluxo end-to-end
User ──▶ Hermes ──▶ soul.md (read)
│
├──▶ Pantheon (lookup) ──▶ Orpheus
│ │
│ ▼
│ ┌─Triad Loop─┐
│ │ Conductor │ via OpenRouter → Opus
│ │ │ │
│ │ ▼ │
│ │ Worker │ via OpenRouter → DSV4
│ │ │ │
│ │ ▼ │
│ │ Critic │ via OpenRouter → GPT
│ │ SHIP/REV │
│ └─────┬──────┘
│ │
│◀─────── output ──────────────┘
▼
User
🎯 Teste de compreensão
Se você consegue desenhar esse fluxo de memória, com os nomes corretos em cada salto, você entende TRIAD o suficiente para começar a estendê-lo. Se travar em algum salto, esse é o tópico para reler.
🔑 Conceitos-chave
User → Hermes → soul → Pantheon → Skill → Triad → resposta
O loop Condutor-Worker-Crítico vive dentro da skill, não no Hermes
Cada papel do Triad é uma classe de modelo, não um provider fixo
Hermes aplica voz e formato apenas na composição final
🧩 Pontos de extensão — onde o sistema pode crescer
Um sistema saudável tem pontos de extensão claros — onde adicionar capacidade é trivial e onde adicionar é um risco arquitetural. Saber a diferença evita reescritas dolorosas mais à frente.
O que é
Pontos de extensão são as fronteiras do sistema projetadas para receber novas capacidades sem refatoração — novas skills no Pantheon, novos modelos no OpenRouter, novas tools (como Gemini CLI). Pontos não-extensíveis (como o núcleo do Hermes) exigem cuidado redobrado para mudar.
Nova skill no Pantheon
Registre entrada com trigger, descrição e classe de modelo. Hermes a descobre automaticamente. Custo de extensão: baixo.
Novo modelo no OpenRouter
Adicione config de provedor com policy (custo, latência, fallback). Skills não mudam. Custo: muito baixo.
Nova tool (CLI multimodal, scraper, etc.)
Envelope a tool com input/output via stdin/stdout. Skills chamam diretamente. Custo: baixo a médio.
Nova persona
Pantheon aceita personas com mesmo formato de entrada das skills. Modula só o tom da resposta final. Custo: baixíssimo.
Mudança no Hermes (núcleo)
Alterar as 5 responsabilidades do orquestrador afeta todo o sistema. Custo: alto. Faça apenas com motivo forte.
📐 Mapa de extensibilidade
┌── BAIXO CUSTO ──┐
│ │
nova skill ───▶ Pantheon OpenRouter ◀── novo modelo
│ │
nova persona ─▶ Pantheon Tools ◀── nova ferramenta
│ │
└─────┬────────┬───┘
│ │
▼ ▼
Hermes (núcleo)
│
▼
┌── ALTO CUSTO ───┐
│ mudar parsing │
│ mudar despacho │
│ mudar contexto │
└─────────────────┘
💡 Heurística de extensão
Antes de tocar em Hermes, pergunte: "Isso poderia ser uma nova skill no Pantheon?" Se sim, faça lá. O núcleo do orquestrador deve mudar muito devagar — extensões devem mudar rápido. É essa assimetria que mantém o sistema escalável.
🔑 Conceitos-chave
Pantheon/OpenRouter/Tools = barato; Hermes = caro
Hermes muda devagar — toda capacidade nova tenta primeiro virar skill
Skills, modelos e tools são as bordas — projetadas para crescer rápido
A diferença de custo entre extensão e mudança de núcleo é intencional
✅ Resumo do Módulo
Próximo Módulo:
4.2 — Pantheon visual: navegando o catálogo de skills e personas