🔮 Avançado

O Condutor é o modelo que transforma seu objetivo vago em um briefing preciso que o Worker pode executar. Um prompt fraco do Condutor produz um briefing fraco → Worker gera drafts medíocres → Crítico reprova em loop → custo alto, resultado ruim. Um prompt forte define critérios de sucesso mensuráveis, restrições claras e ângulos específicos para explorar.

Otimizar o prompt do Condutor tem o maior retorno de qualquer ajuste no sistema. Um briefing de qualidade reduz as iterações do loop Worker-Crítico em 60–80%.

Briefing como multiplicador de qualidade · Critérios de sucesso mensuráveis · Restrições explícitas · Redução de iterações por qualidade do briefing

Um briefing eficaz do Triad tem cinco elementos: (1) Objetivo em uma frase sem ambiguidade; (2) Critérios de sucesso mensuráveis — como você saberá que o resultado é bom; (3) Restrições explícitas — o que não fazer, formatos inaceitáveis; (4) Contexto relevante — informações que o Worker precisa mas não tem acesso; (5) 3–5 ângulos sugeridos para exploração paralela.

Saber os cinco elementos permite auditar qualquer briefing antes de despachar ao Worker. Se algum elemento estiver faltando, o briefing está incompleto.

Cinco elementos do briefing · Objetivo sem ambiguidade · Critérios mensuráveis · Ângulos sugeridos · Auditoria pré-execução

Critérios vagos ("boa análise de mercado") produzem outputs que parecem válidos mas são inúteis. Critérios específicos são testáveis: "identifica nichos onde o ticket médio por cliente é acima de $3.000, o mercado é local e a urgência de compra é alta". O Crítico usa os critérios para aplicar SHIP/REVISE objetivamente.

Critérios específicos são o que permite que o Crítico seja rigoroso de forma objetiva em vez de subjetiva. Sem eles, o sistema produz qualidade inconsistente.

Critério testável vs subjetivo · Urgência como critério · Critério como input do Crítico · Consistência por especificidade

O system prompt do Worker deve especificar: quantos ângulos explorar (3–5), que cada ângulo use uma premissa fundamentalmente diferente (não apenas linguagem diferente), que o Worker mostre seu raciocínio (não apenas a conclusão), e que não julgue qual ângulo é melhor — isso é papel do Crítico. Para tarefas de volume: "se o Crítico retornar REVISE com o mesmo problema pela segunda vez, inverta a premissa central".

O Worker sem instruções claras de paralelismo produz variações superficiais do mesmo ângulo, não exploração genuína. A instrução de premissa diferente é o que força diversidade real.

Premissa diferente vs linguagem diferente · Raciocínio visível · Sem julgamento de valor · Inversão de premissa como estratégia · Diversidade real de ângulos

O Crítico deve ser instruído a criticar com especificidade: "X assume Y, mas isso falha quando Z" é crítica válida. "Poderia ser mais detalhado" não é crítica — é observação vaga. O Crítico deve sempre indicar: qual é o problema específico, onde no draft ele aparece, e como seria diferente se fosse corrigido. Para tarefas estratégicas: "questione a premissa central se ela não for verificável".

Um Crítico vago faz o Worker girar sem melhorar. Um Crítico específico converte cada iteração em melhoria mensurável.

Crítica específica vs vaga · Localização do problema no draft · Como seria diferente · Questionamento de premissa · Crítica como driver de melhoria

Em tarefas longas, modelos podem atingir limites de contexto no meio da execução. Adicione fallbacks explícitos no system prompt do Worker: "se você atingir o limite de tokens antes de completar todos os ângulos, entregue os ângulos completos e sinalize PARTIAL_DELIVERY — não truncue ângulos no meio". Para o Crítico: "se receber um PARTIAL_DELIVERY, avalie apenas os ângulos completos e sinalize quantos faltam".

Sem fallbacks explícitos, o modelo trunca silenciosamente no momento do limite — e o Crítico avalia trabalho incompleto como se fosse completo. Fallbacks tornam as falhas visíveis e recuperáveis.

Limite de contexto · PARTIAL_DELIVERY como sinal · Truncamento silencioso · Falha visível vs silenciosa · Recuperação de tarefa parcial

Para iterar sistematicamente: (1) mantenha um log das últimas 5 execuções com resultado e número de iterações do loop; (2) identifique o padrão de reprovação mais frequente do Crítico — esse padrão indica um gap no briefing do Condutor; (3) adicione instrução específica para cobrir esse gap; (4) execute com a mesma tarefa de referência e compare. Bom sistema: menos de 3 iterações para tarefas de complexidade média.

Iterar sem medir é girar em círculos. Com métricas simples (número de iterações, tipo de reprovação mais frequente), você transforma otimização em processo sistemático.

Log de execuções · Padrão de reprovação · Gap do briefing · Tarefa de referência · Menos de 3 iterações como benchmark

O custo de uso de LLMs é calculado em tokens — unidades de texto que variam entre 3–4 caracteres em inglês e 2–3 em português. Custos separados para tokens de input (o que você envia) e output (o que o modelo responde). Input é geralmente mais barato que output. Alguns modelos (como Claude) oferecem cache de prompt — tokens de input repetidos entre chamadas são cobrados a 10% do preço normal.

Entender a estrutura de custo é o pré-requisito para qualquer estratégia de otimização. Sem esse conhecimento, você otimiza o componente errado.

Input tokens vs output tokens · Cache de prompt · Relação input/output em português · Custo por modelo · Estimativa antes de executar

Antes de rodar uma tarefa overnight longa, estime o custo: (1) estime o briefing em tokens — regra prática: 750 palavras ≈ 1.000 tokens; (2) estime o tamanho de cada draft (500–2.000 tokens para análises médias); (3) multiplique pelo número esperado de iterações; (4) multiplique pelo preço do modelo; (5) adicione 30% como margem de erro. Para DeepSeek V4 a $0,87/M output: 10 iterações × 1.000 tokens = $0,0087.

Estimar custo antes de executar elimina surpresas. Em tarefas novas, uma estimativa ruim pode resultar em custo 10x maior que o esperado.

750 palavras = 1.000 tokens · Estimativa de iterações · Margem de 30% · Cálculo para DeepSeek V4 · Surpresa como resultado de não estimar

Rate limits são limites impostos pelos provedores no número de tokens ou chamadas por minuto/hora/dia. Quando atingidos, retornam erro 429 Too Many Requests. Os limites variam por modelo e por tier de conta. Para o Triad em uso intensivo, os rate limits mais comuns são tokens por minuto (TPM) e requisições por minuto (RPM). BYOK na DeepSeek resolve o problema de limite compartilhado no OpenRouter.

Rate limits são o principal ponto de falha em loops overnight. Saber quando acontecem e como evitá-los é o que garante que o trabalho noturno chega completo pela manhã.

TPM e RPM · 429 Too Many Requests · Tier de conta e limites · BYOK como solução · Limites compartilhados vs dedicados

Orçamento prático para o Triad: defina um limite semanal por papel — ex: Condutor (Opus): $5/semana, Worker (DeepSeek): $10/semana, Crítico (GPT-5.5): $3/semana. Configure alertas no OpenRouter para cada modelo quando atingir 80% do orçamento semanal. Reserve 20% para experimentos fora do Triad.

Orçamento por modelo evita que um loop runaway (loop sem parada) consuma créditos ilimitados. É o freio de segurança financeiro do sistema.

Orçamento por papel · Limite semanal · Alertas de 80% · Loop runaway · Reserva para experimentos

No OpenRouter, vá em Settings → Billing → Spend Alerts. Configure: alerta de email quando gasto diário atingir $X; limite hard de gasto mensal (o OpenRouter bloqueia novas chamadas automaticamente). Para projetos de equipe, crie chaves de API separadas por projeto para monitorar custo por iniciativa.

Alertas automáticos são o sistema de proteção que funciona enquanto você dorme. Sem eles, você pode acordar com uma conta inesperada de um loop que ficou rodando além do planejado.

Spend Alerts no OpenRouter · Limite hard mensal · Alerta por projeto · Chave por projeto · Proteção automática overnight

Free tiers são adequados para: testes de configuração, exploração de novos prompts, tarefas de baixa prioridade onde velocidade não importa. Não são adequados para: o Triad em produção (rate limits muito baixos), tarefas overnight (risco de interrupção), e loops de mais de 5 iterações. Regra prática: se a tarefa vai levar mais de 10 minutos ou produzir mais de 10 chamadas, use tier pago com BYOK.

Usar free tier nas situações erradas resulta em trabalho interrompido e estados inconsistentes — muitas vezes mais custoso em tempo que a economia em dinheiro.

Free tier para testes · Pago para produção · Limite de 10 chamadas · Risco de interrupção · Custo em tempo vs custo em dinheiro

Técnicas de redução de tokens que não sacrificam qualidade: (1) remover exemplos redundantes do system prompt; (2) usar listas em vez de parágrafos nas instruções de sistema; (3) colocar instruções constantes no prompt do sistema (cacheado) e variáveis no prompt do usuário (fresh); (4) para o briefing do Condutor, usar formato estruturado de 5 seções em vez de prosa; (5) pedir ao Worker para mostrar raciocínio em bullets, não em parágrafos.

Reduzir tokens sem perder qualidade é o que permite fazer mais com o mesmo orçamento. Cada técnica tem impacto mensurável no custo sem afetar a profundidade do output.

Cache de system prompt · Lista vs parágrafo · Briefing estruturado · Raciocínio em bullets · Redução sem sacrifício de qualidade

Um sistema Hermes em uso regular precisa de quatro categorias de monitoramento: (1) Disponibilidade — o Hermes responde? (2) Custo — está dentro do orçamento? (3) Qualidade — os outputs do Triad estão sendo aprovados em menos de 3 iterações? (4) Saúde do soul.md — as informações estão atualizadas? Um sistema mal monitorado deriva silenciosamente para comportamento inesperado.

Monitoramento sistemático transforma o Hermes de uma ferramenta que funciona às vezes em um sistema confiável. Sem ele, você descobre problemas depois de ter consequências.

Quatro categorias de monitoramento · Disponibilidade vs custo vs qualidade · Deriva silenciosa · Monitoramento como prevenção · Atualidade do soul.md

O Hermes mantém logs em ~/.hermes/logs/. Cada sessão gera um arquivo de log com timestamp contendo: chamadas de modelo (qual modelo, quantos tokens, custo), ferramentas executadas, erros e warnings, e histórico de decisões do agente. O comando hermes logs --last 10 mostra os últimos 10 eventos.

Saber onde ficam os logs e como lê-los é o que permite diagnosticar problemas retroativamente. "Por que o Hermes fez X?" é uma pergunta que os logs respondem.

~/.hermes/logs/ · hermes logs --last · hermes logs --session · Tokens e custo por chamada · Diagnóstico retroativo

O dashboard do OpenRouter (openrouter.ai/activity) é o melhor painel de saúde financeira do sistema. Verifique diariamente: custo total do dia anterior vs média dos últimos 7 dias; modelo com maior custo; chamadas com erro; e latência por modelo. Anomalias em qualquer dessas métricas indicam problema.

O dashboard centraliza todas as informações financeiras do sistema em um lugar. Verificar 2 minutos por dia é suficiente para detectar anomalias antes que se tornem problemas grandes.

Revisão diária de 2 minutos · Custo vs média 7 dias · Modelo mais caro · Taxa de erro · Latência por modelo

Configure alertas por email ou Telegram para eventos críticos: (1) Custo diário excede o limite; (2) Erro 429 repetido — rate limit crônico; (3) Job agendado não completou no tempo esperado; (4) soul.md não atualizado há mais de 30 dias. Para alertas via Telegram, use o bot do Hermes ou integre via Webhook ao seu bot pessoal.

Alertas proativos eliminam a necessidade de monitoramento ativo constante. Você age quando precisa, não monitora constantemente.

Alerta de custo · Alerta de rate limit · Alerta de job falho · soul.md stale · Telegram como canal de alerta

Um ritual diário de 5 minutos de saúde do sistema: (1) abrir o OpenRouter dashboard e verificar custo de ontem; (2) verificar se há jobs incompletos no Hermes; (3) ler o resumo do que Hermes fez nas últimas 24 horas; (4) verificar se há alertas pendentes; (5) confirmar que o soul.md ainda reflete a realidade atual. Esse ritual pode ser automatizado — peça ao Hermes para enviar um resumo diário às 8h.

5 minutos por dia de revisão previne horas de debugging quando algo vai errado. É o custo de manutenção mais barato possível para um sistema de produção.

Ritual de 5 minutos · Jobs incompletos · Resumo diário automático · soul.md vs realidade atual · Prevenção vs remediação

Tarefas presas acontecem quando o loop Worker-Crítico entra em ciclo: o Crítico reprovando sempre com o mesmo problema, o Worker revisando sem conseguir resolver. Sinais: mesmo número de iterações crescendo sem convergência; custo subindo sem entrega. Solução: adicionar instrução no Worker "se o Crítico reprovar o mesmo problema três vezes, sinalize STUCK e escale para o Condutor".

Loops infinitos são o bug mais caro de um sistema de IA agêntica. Um loop overnight sem parada pode consumir créditos significativos antes de ser detectado.

Sinal STUCK · Escala para o Condutor · Loop sem convergência · Custo crescente sem entrega · Limite de iterações como proteção

O Hermes mantém histórico de decisões em ~/.hermes/memory/. Periodicamente, exporte e revise: quais tipos de tarefa foram delegados com mais frequência, quais tiveram melhor qualidade, quais foram reprovados pelo Crítico mais vezes. Essa análise revela onde o sistema é mais e menos eficiente. Adicione os insights à seção Memory do soul.md para que o Hermes aprenda com o histórico.

O histórico de decisões é o dado bruto para melhoria contínua. Sem revisão periódica, você perde a oportunidade de aprender com o que o sistema já fez.

~/.hermes/memory/ · Exportação periódica · Tipos de tarefa com melhor ROI · Padrão de reprovação · Insights para o soul.md

Chaves de API expostas são usadas por bots que escaneiam repositórios GitHub, pastas públicas e logs em tempo real. Uma chave da OpenAI ou Anthropic exposta pode resultar em centenas de dólares de uso não autorizado em horas. GitHub Secret Scanning detecta automaticamente padrões de chaves e notifica, mas a notificação vem depois da exposição.

O risco não é teórico — acontece rotineiramente com desenvolvedores que acidentalmente commitam arquivos de configuração. Entender o nível de risco motiva as boas práticas.

Bot scanning de repositórios · GitHub Secret Scanning · Uso não autorizado em horas · Custo de vazamento · Notificação tardia

O soul.md é um arquivo de texto que pode ser lido por qualquer processo com acesso ao ~/.hermes/. Nunca inclua chaves de API, senhas ou tokens no soul.md. Alternativas seguras: variáveis de ambiente (arquivo .env nunca commitado), um gerenciador de senhas (1Password, Bitwarden), ou o keychain do sistema via hermes secrets set KEY valor.

O soul.md é um ponto de exposição óbvio para pessoas que não conhecem o sistema. Estabelecer a regra "nunca chaves no soul.md" antes de começar a preencher evita o hábito errado.

soul.md como arquivo de texto · hermes secrets set · Variáveis de ambiente · .env no .gitignore · Gerenciador de senhas

Variáveis de ambiente são armazenadas no ambiente do sistema operacional, não em arquivos. Crie um arquivo .env na raiz do diretório de trabalho (nunca no repositório), adicione ao .gitignore, e carregue com source .env antes de iniciar o Hermes. No arquivo: ANTHROPIC_API_KEY=sk-ant-... em cada linha.

Variáveis de ambiente são o padrão da indústria para credenciais: ficam fora do sistema de arquivos de projeto, não aparecem em logs de debug e não são acidentalmente commitadas.

.env e .gitignore · source .env · ~/.bashrc para persistência · Fora do projeto git · Padrão da indústria

Rotação de chaves é o processo de substituir periodicamente suas API keys por novas. Pratique rotação: a cada 90 dias como rotina, imediatamente se suspeitar de exposição, e ao offboard um colaborador que tinha acesso. Para rotacionar: gere nova chave no provedor, atualize as variáveis de ambiente, teste que o sistema funciona com a nova chave, e então revogue a chave antiga.

Chaves antigas que nunca foram rotacionadas são um risco silencioso — você não sabe se foram expostas em algum momento. Rotação regular limita a janela de exposição potencial.

Rotação a cada 90 dias · Rotação imediata por suspeita · Revogar depois de confirmar nova chave · Offboard como gatilho · Janela de exposição

O Hermes pode ser configurado com escopos de ferramenta limitados: hermes config set tools.allowed "terminal,gemini" restringe o Hermes a usar apenas essas ferramentas. Para o Triad específico, o Hermes precisa: acesso à internet (chamadas de API), acesso ao terminal (para CLIs), leitura de ~/.hermes/. Não precisa de: acesso a arquivos fora de diretórios configurados ou execução de scripts arbitrários.

Princípio de menor privilégio — dar ao agente apenas o que ele precisa para a função limita o dano potencial de um comportamento inesperado ou de um prompt injection.

Escopo de ferramentas · hermes config tools.allowed · Menor privilégio · Prompt injection · Dano limitado por restrição

O Hermes tem acesso a tudo que você inclui no soul.md, no histórico de conversas e nos arquivos que você passa explicitamente. Evite incluir no soul.md: senhas de qualquer tipo, dados pessoais de terceiros sem necessidade, informações financeiras detalhadas além do necessário para contexto, e informações confidenciais de contratos ou acordos de sigilo.

O contexto que você dá ao Hermes pode eventualmente chegar a um modelo externo via API. Minimizar dados sensíveis no contexto é uma prática de privacidade básica.

soul.md como contexto transmitido · Dados de terceiros · Informações financeiras vs contexto financeiro · Acordo de sigilo · Minimização de dados

Antes de usar o Hermes para tarefas de produção, verifique: ✓ Chaves estão em variáveis de ambiente, não em arquivos de texto · ✓ .env está no .gitignore · ✓ soul.md não contém credenciais · ✓ hermes tools.allowed está configurado com escopo mínimo · ✓ Alerta de custo está ativo no OpenRouter · ✓ Limite de orçamento mensal está definido · ✓ Última rotação de chaves foi há menos de 90 dias. Este checklist deve ser repetido a cada novo projeto.

Um checklist sistemático substitui a dependência de memória. Segurança que depende de lembrar é segurança que vai falhar eventualmente.

Checklist como protocolo · Verificação antes de produção · Independência de memória · Repetição por projeto · Falha inevitável por dependência de memória

Falhas de modelo em sistemas de produção são inevitáveis: indisponibilidade de provedor (ocorre algumas vezes por mês em qualquer provedor), sobrecarga de servidor (latências de 30–60s em horários de pico), rate limit excedido (429), e erros de qualidade (modelo retorna resposta truncada ou sem sentido). Cada tipo de falha requer uma estratégia diferente de recuperação.

Aceitar que falhas vão acontecer — e projetar o sistema para lidar com elas — é o que diferencia um protótipo de um sistema de produção. A questão não é se vai falhar, mas quando e como recuperar.

Indisponibilidade de provedor · Rate limit como falha · Resposta truncada · Falha como dado estatístico · Design para recuperação

No OpenRouter, você pode especificar um array de modelos fallback em sua chamada de API: se o modelo primário retornar erro ou timeout, o OpenRouter automaticamente tenta o próximo na lista. Exemplo para o Worker: primário deepseek/deepseek-chat, fallback 1 mistral/mistral-large, fallback 2 meta-llama/llama-3.1-70b-instruct. O fallback é transparente para o Hermes.

Fallbacks no OpenRouter são a forma mais simples de resiliência — uma linha de configuração que protege contra indisponibilidade de provedor sem mudança no código do Hermes.

Array de fallback · Transparência para o Hermes · Fallback para mesmo papel · Configuração única · Proteção contra indisponibilidade

Além de fallbacks de provedor, adicione instruções defensivas no system prompt do Worker: "Se você atingir o limite de tokens antes de completar todos os ângulos, entregue os ângulos completos e sinalize PARTIAL_DELIVERY com o número de ângulos faltantes. Não truncue ângulos no meio — um ângulo incompleto é inútil. Se você encontrar informação contraditória no briefing, sinalize BRIEFING_CONFLICT antes de prosseguir."

Instruções defensivas tornam falhas visíveis e nomeadas — PARTIAL_DELIVERY e BRIEFING_CONFLICT são muito mais fáceis de diagnosticar do que um output silenciosamente incompleto ou errado.

PARTIAL_DELIVERY · BRIEFING_CONFLICT · Ângulo incompleto vs ausente · Falha nomeada vs silenciosa · Instruções defensivas como protocolo

Sem limites de retry, um loop que falha repetidamente pode rodar indefinidamente. Configure no system prompt do Worker: "se o Crítico retornar REVISE com o mesmo problema pela terceira vez consecutiva, escale para o Condutor com status STUCK. Não tente uma quarta revisão do mesmo ângulo." Para falhas de API: retry automático máximo 3 vezes com backoff exponencial (1s, 2s, 4s).

Limites de retry são o freio de segurança do sistema. Sem eles, um loop mal configurado pode rodar por horas sem progressão.

Três tentativas como limite · STUCK como sinal de escalada · Backoff exponencial · Loop sem progressão · Consumo sem resultado

Para tarefas que levam mais de 30 minutos ou mais de 20 iterações, instrua o Worker a salvar estado parcial periodicamente: "a cada 5 ângulos completados, escreva o progresso parcial no formato: CHECKPOINT: [número de ângulos completados]/[total], seguido dos ângulos prontos". Se a tarefa for interrompida, o Condutor pode retomar a partir do último checkpoint em vez de reiniciar do zero.

Checkpoints transformam falhas de tarefa longa de catástrofe em inconveniência. Sem eles, qualquer interrupção joga fora todo o trabalho feito até aquele momento.

CHECKPOINT como protocolo · Retomada parcial · A cada 5 ângulos · Formato de checkpoint · Falha como inconveniência vs catástrofe

Quando uma tarefa é interrompida, o processo de recuperação manual é: (1) verificar no log do Hermes qual foi o último estado registrado; (2) identificar se há um CHECKPOINT no output parcial; (3) construir um novo prompt que inclua o contexto do checkpoint e instrua a continuar de onde parou; (4) verificar custo consumido antes de reiniciar. Para tarefas sem checkpoint, avaliar se vale recomeçar ou abandonar.

Saber recuperar uma tarefa interrompida salva o trabalho já feito e o custo já consumido. Sem esse processo, toda interrupção resulta em desperdício.

Log como fonte de estado · CHECKPOINT como ponto de retomada · Prompt de continuação · Custo consumido vs valor recuperável · Abandonar vs recomeçar

Antes de confiar no sistema para tarefas críticas overnight, teste a resiliência ativamente: (1) simule uma falha de modelo trocando para um modelo inexistente e verificando se o fallback é acionado; (2) envie um briefing deliberadamente contraditório e verifique se o Worker sinaliza BRIEFING_CONFLICT; (3) force STUCK mandando um briefing impossível; (4) interrompa uma tarefa no meio e verifique o processo de recuperação.

Testar resiliência em condição controlada revela problemas antes de eles aparecerem em produção. É a diferença entre descobrir que o fallback não funciona durante um teste vs durante uma tarefa crítica às 3h da manhã.

Modelo inexistente como teste · Briefing contraditório · STUCK forçado · Interrupção controlada · Validação antes de produção crítica

Orpheus é para deep work estratégico que justifica o custo e tempo do loop Triad completo. Crie novas personas quando: a tarefa tem um padrão recorrente com perfil específico (ex: análise de conteúdo de redes sociais), o Orpheus está sendo chamado para tarefas de escopo médio que não precisam de 3 modelos, ou você quer especialização sem o overhead do Triad.

Usar Orpheus para tudo é como usar martelo para parafuso. Personas especializadas são mais rápidas e baratas para tarefas de escopo definido.

Escopo da tarefa como critério · Overhead do Triad · Especialização vs generalismo · Padrão recorrente como gatilho · Custo-benefício por persona

Faça uma auditoria das últimas 20 tarefas que delegou ao Hermes e categorize por tipo: análise estratégica, criação de conteúdo, pesquisa de mercado, revisão técnica, planejamento, comunicação externa. Tipos que aparecem mais de 3 vezes por semana e têm um padrão de prompt consistente são candidatos a persona própria.

A auditoria transforma intuição em dado. Sem ela, você cria personas por conveniência, não por necessidade — e acaba com um Pantheon grande demais para gerenciar.

Auditoria das últimas 20 tarefas · Frequência como critério · Padrão consistente · Pantheon manejável · Criação por dado vs intuição

Persona "Ágora" — especialista em pesquisa de mercado. System prompt: "Você é Ágora, especialista em análise de mercado. Para cada pesquisa: (1) identifique o mercado-alvo com 3 critérios objetivos; (2) mapeie os 5 maiores players com posicionamento, preço e diferencial; (3) identifique 3 gaps não atendidos com evidência; (4) avalie atratividade por um modelo de scoring simples." Modelo: DeepSeek V4 (sem Crítico — a estrutura fixa substitui a crítica).

Ver um exemplo concreto de persona especializada demonstra como traduzir um tipo recorrente de trabalho em uma persona funcional.

Persona Ágora · Estrutura fixa vs Triad · DeepSeek como executor único · Formato de entrega padronizado · Scoring de mercado

Persona "Hermes Scribe" — especialista em geração de conteúdo no seu tom de voz. System prompt: "Você é Hermes Scribe. Gere conteúdo estritamente no tom definido no soul.md (brand voice). Para cada peça: (1) leia a seção Voice do soul.md; (2) confirme o canal de destino (LinkedIn, newsletter, YouTube script); (3) gere três variações curtas; (4) aplique os hard nos do soul.md como filtro." Modelo: Claude Sonnet (mais econômico que Opus para geração de texto).

Geração de conteúdo é um dos casos de uso mais frequentes. Uma persona dedicada com tom de voz calibrado elimina iterações de edição após a geração.

Persona Hermes Scribe · soul.md como fonte de voz · Três variações · Hard nos como filtro · Sonnet vs Opus para texto

Persona "Arquiteto" — especialista em revisão e análise de código. System prompt: "Você é Arquiteto. Para cada análise: (1) identifique os 3 maiores riscos técnicos com impacto estimado; (2) liste débito técnico acumulado com prioridade (crítico/alto/médio/baixo); (3) proponha o menor conjunto de mudanças para reduzir os riscos críticos; (4) estime esforço de cada mudança em dias de desenvolvedor. Use Claude Code como ferramenta para ler o repositório antes de analisar." Modelo: Claude Opus.

Análise técnica de código é um caso onde o custo adicional do Opus se justifica. O Arquiteto demonstra como escolher o modelo certo por tipo de tarefa.

Persona Arquiteto · Riscos técnicos com impacto · Débito técnico priorizado · Claude Code como ferramenta · Opus para raciocínio máximo

Com múltiplas personas no Pantheon, organize por: convenção de nomenclatura (nomes mitológicos para estratégicas, nomes descritivos para operacionais), tag por domínio (estratégia, conteúdo, técnica, pesquisa), e documentação de invocação (quando chamar cada uma, o que ela não faz). Limite o Pantheon ativo a 5–7 personas — mais do que isso, o overhead de gestão supera o benefício.

Um Pantheon desorganizado se torna difícil de usar. A fricção de lembrar qual persona serve para qual tarefa aumenta com o número de personas sem organização.

Convenção de nomenclatura · Tags por domínio · Documentação de invocação · Limite de 5–7 ativas · Overhead de gestão

Personas do Hermes podem ser exportadas via hermes pantheon export --persona Orpheus > orpheus.yaml. Para importar em outro Hermes: hermes pantheon import orpheus.yaml. O arquivo exportado inclui: system prompt, modelo configurado, ferramentas permitidas e metadados de versão. Para equipes, mantenha as personas compartilhadas em um repositório git separado do código.

A capacidade de compartilhar personas transforma o Hermes de ferramenta individual em ativo de equipe. Uma persona bem calibrada pode poupar horas de configuração para cada novo membro.

hermes pantheon export · hermes pantheon import · YAML/JSON portável · Repositório de personas da equipe · Ativo compartilhado vs individual