Skip to content
Hendrios Platform Docs

Guia do Concierge

Concierge — Agente de Atendimento Multicanal

Escopo único: runtime, canais, isolamento multi-tenant, billing e critérios de aceite do Concierge — o agente de atendimento multicanal da fábrica. Regras de billing_target e Work Type → canon/CONTEXT.md; Vaultwarden (cofre compartilhado) → platform/04-secrets-security; handoff e SLA → business/05-contract-legal.

Fonte: spec deep interview 2026-06-07 (di-whatsapp-agent-20260607, ambiguidade final 11%); pesquisa Hermes Agent e MiniMax ToS, 2026-06-07.

Visão geral

O Concierge é o agente de atendimento multicanal da fábrica: o Client conversa por WhatsApp ou Telegram (texto ou áudio) e o agente cria issues em nome dele, responde status em linguagem humana, fecha o ciclo needs-info pelo canal (a dúvida da equipe no GitHub vira outreach proativo no chat; a resposta volta como comentário atribuído na issue) e notifica entregas — sem que o Client precise viver no GitHub.

  • Atendimento incluído na mensalidade — billing_target=service: mede sempre, fatura nunca.
  • Ator distinto no threat model — conta-bot própria, allowlist de contatos, permissões GitHub mínimas.
  • Brain continua único despachante — o Concierge é boca e ouvido; o Brain decide o que merece outreach.
  • Client-facing: “Concierge da Hendrios” — apresenta-se como assistente de IA (transparência; EU AI Act).

Avoid: bot (solto), assistente, agente (solto — colide com os agentes de execução da fábrica).

Runtime: Hermes Agent + MiniMax-M3 (R3)

AtributoValor
FrameworkHermes Agent (Nous Research, MIT, v0.16.0)
ModeloMiniMax-M3 via Token Plan (ToS-safe: listado oficialmente)
FallbackOpenClaw se o multi-tenant do MiniMax decepcionar
DeployImagem Docker oficial (debian 13.4), 1–2 GB RAM
Configconfig.yaml com GitHub MCP + canais + profiles

NOTA — ADR 0008: chamadas MiniMax via Subscription Key com base URL customizada têm status ambíguo (sem cláusula pública de enforcement; risco documentado = throttling por janela 5h/semanal, não suspensão por harness). Ticket de suporte em platform.minimax.io pendente para confirmação. Ver canon/adr/0008.

NOTA — Hermes v0.16: bugs MiniMax endpoint #5781 (routing /anthropic) e #6039 (custom base_url ignorado) reportados na v0.15. Verificar correção na v0.16.0 antes do deploy (AC9). Releases ~bimensais — fixar versão no docker-compose.yml.

Canais: Telegram + WhatsApp (R6)

  • Telegram: integração nativa do Hermes (bot token via @BotFather).
  • WhatsApp: via Baileys (QR pairing; não-oficial). Mitigantes do risco de ban: número dedicado, volume PME, comportamento não-spam.
  • Um número/identidade para todos os Clients (R4): isolamento por profiles, não por número.
  • Evolution API: mantida intocada para o tracer; adaptador Evolution↔Hermes rejeitado na decisão R6 — só reviver se Baileys falhar em produção.

Autoria e outreach (R5)

  • Conta-bot única da fábrica — permissões GitHub mínimas: Issues:read/write + Comments nos repos da allowlist apenas.
  • Carimbo de atribuição no corpo da issue: "criada via WhatsApp/Telegram em nome de <username>".
  • Label de canal: via:whatsapp ou via:telegram aplicada automaticamente.
  • Outreach proativo: GitHub → Brain → webhook nativo do Hermes → mensagem no canal do Client.
    • O Brain decide quais eventos merecem outreach; o Hermes só entrega.
    • Ciclo needs-info: comentário/label da equipe → Brain → outreach no canal → resposta do Client vira comentário atribuído na issue (AC4).
  • GitHub App da conta-bot: upgrade para App na org na migração para conta de organização (passo futuro).

Isolamento multi-tenant (R4)

  • Profiles do Hermes: um profile por Client; doc oficial recomenda 1 container Docker por profile para dados sensíveis.
  • Sessions por contato: group_sessions_per_user: true em grupos — sessões por autor dentro do grupo, não por grupo.
  • Allowlist de contatos: números de WhatsApp + usernames Telegram definidos no onboarding de cada Client; sem auto-cadastro no MVP; registrada via platform/10-onboarding-automation.
  • Critério de aceite: isolamento validado por teste adversarial entre 2 Clients de teste — nenhum dado vaza, incluindo cenário de grupo (AC6).

Captação guiada (R8 — A2+B1)

Issue só nasce com os 3 campos preenchidos:

CampoDescrição
O quêDescrição do pedido
OndeSistema/módulo — resolvido por mapa de apelidos no perfil do Client; pergunta só em ambiguidade
Como saber que ficou prontoCritério de aceite nas palavras do Client

O agente oferece prévia da issue antes de confirmar a criação. Captação por texto e áudio (faster-whisper local / Groq / OpenAI; OGG/Opus do WhatsApp suportado — AC1, AC2). Mapa de apelidos coletado no preboarding via platform/10-onboarding-automation.

Filtro de dados sensíveis (R9)

P1 (MVP): filtro ativo na escrita — senhas, chaves API, CPF/NIF, números de cartão substituídos por placeholder antes de tocar issue/GitHub/LLM; Client avisado com mensagem educada (AC11). Dado ausente da sessão, da issue e do GitHub.

P3 (Fase 2): cofre Vaultwarden self-hosted para segredos que precisam ser retidos. Instalação compartilhada com o Deputy (decisão L10 — antecipação da necessidade). Ver platform/04-secrets-security.

Handoff humano (R10 — H2)

Três gatilhos disparam handoff para a equipe:

#Gatilho
1Pedido explícito do Client
22 falhas de entendimento consecutivas
3Tema sensível: fatura, contrato, reclamação formal

Ao detectar o gatilho:

  • Mattermost notificado com resumo + transcript da conversa.
  • Client recebe promessa com prazo (≤ régua SLA de R24).
  • Ponte no mesmo número (continuar a conversa sem troca de canal) = evolução futura.

Apresentação e tom (R11 — T2)

  • Nome client-facing: “Concierge da Hendrios”.
  • Auto-apresentação como assistente de IA na primeira conversa de contato novo (EU AI Act — AC13).
  • Idioma automático pelo perfil do Client: pt-PT (EU) / pt-BR (Brasil).
  • Tom: profissional-próximo (guideline no system prompt).
  • Coerente com a política de IA na comunicação (L13): resultado primeiro, IA como motor — não é manchete nem segredo.

Grupos (R12 — G2)

O Concierge suporta DM + um grupo oficial por Client desde o MVP, com 3 regras duras:

  1. Só executa ações para autores da allowlist — membro fora dela presente no grupo é ignorado para qualquer ação (AC7).
  2. Em grupo, responde apenas quando mencionado ou endereçado diretamente.
  3. Atribuição sempre pelo autor da mensagem (nunca “do grupo”).

ACs 6 e 7 incluem cenários de grupo (isolamento e recusa de intruso).

Billing (R2)

  • work_type=afk + billing_target=service em toda conversa atribuída ao Client (AC8).
  • Mede sempre; fatura nunca — incluído na mensalidade.
  • Anti-abuso futuro via Spend Caps suaves (jamais cobrança adicional).

Fases

FaseEscopo
MVPAC1–AC10: captação texto/áudio, status, needs-info, notificações, isolamento, allowlist, metering, runbook
Fase 2Aprovação de estimativa no chat (quando o gate de estimativa da esteira existir); trilha de auditoria; Vaultwarden P3
Futuro distantePortal próprio (Concierge é o precursor conversacional)

Gate de estimativa (awaiting-client-approval) documentado como FUTURO na esteira — validação com o Client no MVP é de trade-offs/escopo via needs-info, nunca financeira.

Acceptance Criteria (13 ACs — aprovados R7 + R8–R12, 2026-06-07)

ACCritério
AC1Captação por texto: allowlist → prévia (3 campos) → confirmação → issue no repo certo com carimbo + label de canal
AC2Captação por áudio (transcrição) com o mesmo fluxo
AC3Status de issue em linguagem humana (labels/PR traduzidos)
AC4Ciclo needs-info completo: comentário/label da equipe → Brain → outreach no canal → resposta vira comentário atribuído na issue
AC5Notificações de entrega (PR aberto/deploy) com régua anti-spam mínima
AC6Isolamento multi-tenant validado por teste adversarial entre 2 Clients de teste (nada vaza) — incluindo cenário de grupo (sessões por autor dentro do grupo)
AC7Número fora da allowlist: recusa educada, zero ação no GitHub — incluindo membro intruso em grupo (presente no grupo, fora da allowlist → mensagens dele nunca geram ação)
AC8Metering: toda conversa com work_type=afk + billing_target=service, atribuída ao Client
AC9Bugs MiniMax #5781/#6039 verificados na v0.16.0 antes do deploy; fallback de provider documentado
AC10Runbook do agente (re-pair QR, restart, logs) no padrão do §12 do PLANO-FABRICA
AC11Filtro de sensíveis: senha/CPF plantados na conversa → issue nasce com placeholder; dado ausente da sessão e do GitHub; Client avisado
AC12Handoff: cada um dos 3 gatilhos → Mattermost notificado com resumo+transcript + Client recebe promessa com prazo (≤ régua SLA)
AC13Apresentação: primeira conversa de contato novo contém auto-apresentação como IA, na variante de idioma do perfil do Client

Contexto técnico do Hermes Agent (digest da pesquisa, 2026-06-07)

Nous Research · MIT · lançado fev/2026 · ~185k stars · v0.16.0 (5/jun/2026). Releases ~bimensais — fixar versão no compose. Telegram nativo; WhatsApp via Baileys (QR pairing; não-oficial — risco de ban mitigado por número dedicado/volume PME); sessões por contato + profiles por Client (doc recomenda 1 container/profile para dados sensíveis); áudio via faster-whisper local / Groq / OpenAI (OGG/Opus do WhatsApp suportado); GitHub via MCP (create_issue, list_issues); webhook server nativo para eventos GitHub→chat; Docker oficial (debian 13.4, 1–2 GB RAM). Listado oficialmente no MiniMax Token Plan (junto com OpenClaw, Claude Code, OpenCode, Cursor, TRAE, Kilo Code, Droid, Zed).

Fontes: hermes-agent.nousresearch.com/docs · github.com/nousresearch/hermes-agent · platform.minimax.io/docs/token-plan/hermes-agent · issues #5781 e #6039.