Documentação viva · montada junto com o Don

Documentação — Residente Virtual

Atualizado: 04/06/2026 · este documento cresce a cada bloco entregue.

Como a gente trabalha esta doc: ela não é um relatório de fim. É viva. Cada decisão que a gente toma junto entra aqui, cada bloco que sobe é registrado. Quando você ler e quiser mudar algo, a gente edita aqui e o produto segue.

O que é

Uma plataforma de agentes de IA idêntica ao Telegram na experiência, mas própria. Em vez de contratar e treinar gente do zero toda vez, você cria residentes virtuais — um pra cada tarefa — e entrega cada um pra uma pessoa operar.

Não confundir com o serviço Residente Virtual que roda no WhatsApp pros médicos clientes. Isto aqui é a plataforma onde residentes nascem, são treinados e trabalham.

Arquitetura conceitual

Orquestrador

O cérebro. Acesso total, vê o negócio inteiro, cria e treina os residentes. Só o dono fala com ele.

Residente virtual

Nasce de uma tarefa do orquestrador. Tem escopo restrito, é entregue a uma pessoa, e trabalha só dentro dele. Trava de um usuário por residente.

Fábrica (BotResidente)

O criador. Gera um residente novo com nome, escopo e a pessoa que vai operar. Captura o id de cada um.

O diferencial (o moat): o que o funcionário treina fica na empresa, não com ele. Funcionário sai, o residente treinado continua, e a pessoa nova já entra com ele pronto. O humano é substituível, o residente treinado é o ativo, e o ativo é da empresa.

Estado atual

Bloco	Status
Interface igual ao Telegram (app)	no ar
Porta de entrada / landing	no ar
Cérebro real nos residentes (IA scoped, com memória)	no ar
Fábrica de residentes (criar na hora)	no ar
Trava de 1 usuário / papéis dono×operador	no ar
Documentação viva	esta página
Persistência real (banco central)	depende de conta
Login de verdade	depende de conta
Multi-empresa self-service	fase 2
Voz (Whisper + TTS)	fase 2
Cobrança recorrente	se virar SaaS

Hoje: o app já pensa de verdade (IA real por trás), mas os dados ainda ficam no navegador (demo). O próximo salto é o banco central + login, que dependem de decisão de conta (abaixo).

O que falta pra escalar pra mais e mais gente

Persistência real e multi-empresa — hoje morre no navegador. Banco central, cada empresa isolada.
Login de verdade — hoje o id é texto livre. Auth real pra abrir pra muita gente com segurança.
Auto-serviço — dono novo cria a empresa dele sozinho, sem virar gargalo em ninguém.
Voz — entrada por áudio (transcrição) e resposta falada.
Custo de IA controlado — modelo forte valida, modelo leve roda em produção. Sem isso, escala explode a conta.
Segurança / LGPD — isolamento forte por residente, dado de saúde sensível, retenção e DPA.
Cobrança — se for vender como SaaS, recorrência integrada.
Knowledge do orquestrador — o moat virar real: base de conhecimento por empresa que treina os residentes e persiste.

Decisões em aberto (suas)

1. Pra quem é o produto? Time interno seu · clientes médicos · ou SaaS pra qualquer um assinar? Cada um muda a arquitetura.

2. Banco e login — qual conta usamos (Supabase é a recomendação). Sem isso, segue como demo no navegador.

3. Marca — "Residente Virtual" é nome descritivo, difícil de registrar puro. Caminho: "NHW Residente Virtual" + logo. Busca formal pela frente jurídica.

4. Modelo de IA — hoje Gemini Flash (rápido e barato). Definir a régua champion-challenger pra produção.

Notas técnicas

Front: HTML/CSS/JS, hospedado na Vercel, domínio via Cloudflare.
Cérebro: função serverless /api/chat chamando Gemini, com o escopo de cada residente como instrução de sistema + memória de conversa.
Fundação backend pronta pra plugar: camada multi-tenant em mvp-agente/platform (isola cada empresa).
Chave de IA fica em variável de ambiente no servidor, nunca no navegador.

Log de construção

Data	O que entrou
04/06	Interface igual ao Telegram no ar (demo conceito)
04/06	Cérebro real (Gemini scoped) + landing + esta doc viva + reestruturação

Próximo passo combinado: você decide o público e a conta de banco, e a gente pluga persistência + login. A doc segue evoluindo aqui.