Como a MIA funciona, de ponta a ponta

01 As camadas

Seis camadas, dois cérebros de IA com papéis que nunca se misturam: Gemini atende, Claude analisa.

02 Infra — onde tudo roda

Duas máquinas no SSH config. Os crons do Claude rodam 100% na primeira; toda a produção roda na segunda.

MIA-01 / Hetzner — containers principais (de 19)

Domínios → backend

03 Canal — WhatsApp ↔ Evolution ↔ Chatwoot ↔ n8n

Dois componentes: a Evolution API (gateway WhatsApp) e o Chatwoot fork fazer.ai (inbox + fonte dos eventos).

Ida — paciente → IA

O paciente manda WhatsApp pro número do cliente. A Evolution recebe via Baileys e encaminha pro Chatwoot por webhook interno (entra como message_type=0, incoming). O Chatwoot dispara o webhook account-level → webhook.miaconecta.com.br/webhook/chatwoot-front, que alimenta o n8n. O agent_bots.outgoing_url fica NULL de propósito, pra evitar webhook concorrente.

Volta — IA → paciente

O n8n posta a resposta no Chatwoot via API REST (message_type=1, outgoing). O Chatwoot repassa pra Evolution, que envia ao WhatsApp.

Mapa cliente → conta / inbox (tudo no fork)

Contas extras (fora dos 6): acc 1 = MIA / inbox 12 mia-test · acc 8 = Juca Pessoal / inbox 13 juca-pessoal (onde vivem os grupos de suporte MIA - <Cliente>) · acc 9 Jess · acc 10 HEALIX · acc 11 CEAFI_GERUZA. Total: 11 contas / 9 inboxes.

04 Atendimento em tempo real — a arquitetura do bot

O cérebro de atendimento não é por cliente — é um par central na pasta Universais. Cada cliente só tem seu Config Loader + a suíte de ferramentas que o agente chama.

Os passos de uma mensagem

Chatwoot Trigger (1 por conta)
  → Config do cliente (chama o Config Loader)  → Filter  → IF horário comercial (só Hugo/Carlos)
  → Abrir Conversa (pending→open)  → Encaminhar pro Universal
  → Info  → IF tem mídia? (Gemini Mídia transcreve áudio / descreve imagem)
  → INSERT na fila  → Wait (debounce)  → DELETE RETURNING  → Consolidar o burst
  → Histórico Chatwoot  → Single Agent (AI Agent)  → Enviar Humanizada  → UPSERT status

Ferramentas do Single Agent (via $fromAI): informacoes_gerais (RAG), Buscar_janelas_disponiveis, Criar_agendamento, Atualizar_agendamento, Buscar_agendamentos_do_contato, Cancelar_agendamento, enviar_midia, Escalar_humano, Refletir.

Clientes × workflows

05 O cérebro de análise — Claude, de madrugada

O Claude headless (claude -p, modelo herda o default do CLI = Opus) lê a operação já acontecida e destila entendimento. Read-only em produção — só escreve em tabelas de análise/demandas e nos arquivos de relatório mensal. Os scripts vivem em demandas-clientes/scripts/ e rodam todos na MIA-SUPORTE.

06 Dados — schemas e tabelas

O painel abre dois pools: dbSistema() → Postgres :5433 e dbFork() → Postgres do Chatwoot fork. Tudo read-only, exceto a decisão de demanda.

Arquétipos (fixos por slug em lib/funil.ts): clínica hugo · nathalya · carlos   SDR thiago   eventos explow   — mais_saude sem arquétipo (inativo).

07 Vitrine — as telas e de onde cada coisa vem

Auth scrypt + JWT (cookie mia_sessao). Navegação de 5 itens: Início · Reparos · Clientes · Conversas · Bots. Todas as telas server-side, com degradação graciosa. Nenhuma rota chama IA ao abrir.

08 Como tudo se alimenta — os 2 fluxos

Um acontece na hora (atendimento, Gemini); o outro acontece em batch, de madrugada (análise, Claude). O primeiro gera os dados; o segundo os transforma em entendimento.

Fluxo A — atendimento em tempo real Gemini Flash

Paciente (WhatsApp)
   │
   ▼
Evolution API ──webhook──► Chatwoot fork (inbox do cliente)
                              │ webhook account-level
                              ▼
                  n8n: 01. Webhook-Loader  (identifica o cliente, Config Loader)
                              ▼
                  n8n: 02. Universal → INSERT fila → Wait (debounce) → DELETE RETURNING
                              ▼
                  Single Agent  ◄──  LLM: GEMINI FLASH  (fallback OpenRouter)
                   │   tools: buscar janela / criar agendamento / enviar mídia / escalar
                   ▼
                  Enviar Humanizada ──► Chatwoot ──► Evolution ──► WhatsApp (paciente)
                   └─► grava status + appointments/Calendar + fila

Fluxo B — análise / insight de madrugada Claude Opus

Cron na MIA-SUPORTE  (03h ter–sáb)
   ▼
run-cron.sh conversas   ◄──  LLM: CLAUDE (Opus), headless, READ-ONLY em prod
   │   lê: fork (conversas do dia) + erros do n8n + Postgres :5433
   │   destila por conversa:  FATOS · QUALIDADE · COMPARAÇÃO · INSIGHT
   ▼
escreve  mia_ciclo.analise_conversas
          └─ insight recorrente (≥2) ──► mia_demandas.demandas
   ▼  (04h — psql puro, NÃO Claude)
projetar-fatos.sh:  UNNEST ──► mia_ciclo.fatos_conversa
   ▼  (diário / semanal / mensal)
triagem dos grupos + maturidade + relatório por cliente
   ▼
DADOS ──SELECT determinístico (sem IA ao abrir)──► Painel ──► Juca lê, decide, exporta

09 Clientes & produto

10 Lacunas honestas

O que ficou sem confirmar, ou que simplesmente ainda não existe. Sem maquiar.

• Insight cruzado de jornada não existe. O sistema extrai fatos e insights por conversa e por cliente, mas não há (no código) um insight que cruze a jornada inteira de um paciente entre conversas — "confirmou e depois desmarcou" vira dois fatos soltos, ninguém costura.
• Relatório é monomodal. A camada de entrega só serve clínica-que-agenda. SDR (Thiago) e Eventos (Explow) têm zero evento em mia_ciclo — a captura de "lead qualificado/handoff" e "orçamento respondido" não existe.
• Cobertura parcial: só 3 de 6 clientes têm dados em mia_ciclo (Hugo, Nathalya, Carlos).
• Tensão do Carlos não resolvida: agendamento ativo (doc do cliente) vs triagem/handoff (docs de produto). Precisa de decisão.
• Temperatura do Gemini não verificada no node (convenção interna = 1.0).
• Divergência script ↔ painel: o cron ainda grava fazer_juntos; o painel já migrou pra parecer_pronto.
• A camada de confiança é hardcoded por cliente (hugo/nathalya/carlos), não derivada dos dados.
• Autonomia agêntica (autogerencial): a ideia do sistema melhorar a própria estrutura no n8n é futuro declarado — não existe hoje.