Vigil Summit Agent — Agente Autônomo de Funil para Eventos B2B

Case AI Engineer (Pareto) · Cliente: Vigil.AI · Evento: Vigil Summit — Segurança para a Era da IA

Agente de IA que gerencia o funil completo de um evento corporativo B2B, da captação do lead à reunião comercial agendada, atacando os três gargalos clássicos desse tipo de evento: geração de leads qualificados, no-show (40–60% dos inscritos) e follow-up frio.

A solução usa Claude 3.5 Sonnet para enriquecer perfis e gerar comunicação personalizada de alta conversão, SQLite como memória de contexto do funil, uma landing page de captação e um painel Streamlit para operação e monitoramento.

Índice

Visão geral e funil
Arquitetura da solução
Stack tecnológico justificado
Réguas de comunicação
Estratégia de dados, personalização e LGPD
Decisões estratégicas e racional
Plano de execução (primeiros 5 dias)
Cenário de escala (pergunta bônus)
Como instalar e rodar · Integração LLM
Como testar (acesso para a Pareto)
Modelo de dados
Limitações e decisões conscientes
Entrega para a Pareto (ENTREGA.md)

1. Visão geral e funil

O agente cobre as quatro fases do funil pedidas no case:

Fase	Objetivo	Onde vive
1 · Captação	Capturar o contato certo (decisores de segurança/TI)	`index.html` (LP) + formulário no painel (`app.py`)
2 · Enriquecimento	Inferir cargo real, setor, porte e dores antes de qualquer mensagem	`agent.py · run_enrichment_pipeline()`
3 · Engajamento pré-evento	Confirmar presença e reduzir no-show (meta > 70%)	`agent.py · run_pre_event_engagement()` / `run_pre_event_sequence()`
4 · Follow-up pós-evento	Converter presença em reunião comercial	`agent.py · run_post_event_sequence()`

O status do lead caminha por quatro estágios, persistidos no banco:

Inscrito  →  Confirmado  →  Presente  →  Reunião Agendada

2. Arquitetura da solução

2.1 Camadas

flowchart TD
    subgraph Entrada["1 · Entrada de dados (Captação)"]
        LP["Landing Page (index.html)<br/>estática · SEO/JSON-LD"]
        FORM["Formulário do Painel<br/>(Streamlit)"]
    end

    subgraph Dados["Camada de dados (memória)"]
        DB[("SQLite · vigil_summit.db<br/>leads + interaction_logs + users")]
    end

    subgraph Cerebro["Processamento (Agente)"]
        AG["agent.py<br/>Fases 2, 3 e 4"]
    end

    subgraph LLM["Camada de IA"]
        CL["Claude 3.5 Sonnet<br/>(Anthropic API)"]
    end

    subgraph Canais["Canais de comunicação (simulados)"]
        WA["WhatsApp"]
        EM["E-mail"]
    end

    subgraph Operacao["Operação e monitoramento"]
        PAINEL["Painel Streamlit (app.py)<br/>KPIs · ações · histórico"]
    end

    LP -->|POST /api/inscricao| DB
    FORM -->|inscrição| DB
    DB <--> AG
    AG -->|enriquecer / gerar copy| CL
    CL -->|perfil / mensagem| AG
    AG -->|registra envio| WA
    AG -->|registra envio| EM
    AG -->|grava interação| DB
    PAINEL -->|modo nuvem: HTTP| DB
    PAINEL -->|dispara pipelines| AG

2.2 Fluxo de dados (ponta a ponta)

Captação: o lead se inscreve pela LP ou pelo painel → cria registro em leads com status_funil = 'Inscrito' e origem (LP_Organico ou Remarketing).
Enriquecimento: o agente seleciona leads sem cargo_real/tamanho_empresa, envia (nome, cargo declarado, empresa) ao Claude e grava o perfil deduzido.
Engajamento: para cada Inscrito enriquecido, o agente gera uma mensagem personalizada de confirmação (gatilho de compromisso) e registra em interaction_logs. A resposta do lead (receive_lead_response) promove o status para Confirmado.
Follow-up: após o evento, presentes recebem a régua comercial; quem confirmou e não veio entra na régua de reengajamento de no-show.
Monitoramento: o painel lê o banco em tempo real, exibe KPIs do funil e permite operar todas as fases.

2.3 Onde cada fase do funil se encaixa

Captação → camada de entrada (LP + painel) grava em leads.
Enriquecimento → Agente + LLM, escreve de volta em leads.
Engajamento / Follow-up → Agente + LLM, escreve em interaction_logs e atualiza status_funil.

3. Stack tecnológico justificado

Camada	Escolha	Por quê
LLM	Claude 3.5 Sonnet (`claude-3-5-sonnet-20241022`), com camada multi-provedor	Preferência explícita do case (ecossistema Anthropic). A camada de LLM é abstraída (`_chat`) e configurável via `LLM_PROVIDER` no `.env`, suportando também Groq (compatível com OpenAI) para desenvolvimento/teste sem custo. A lógica do agente independe do provedor.
Orquestração do agente	SDK nativo (Anthropic / OpenAI-compat)	Para um funil determinístico (etapas e gatilhos bem definidos), o SDK nativo dá controle total e transparência sobre cada prompt/resposta, sem a camada de abstração de um framework. `agno` está listado no `requirements` como caminho de evolução (tool-use/orquestração multiagente) quando a complexidade justificar.
Banco de dados	SQLite	Relacional, zero-config, arquivo único — ideal para um protótipo demonstrável e inspecionável pela banca. O modelo de dados é portável para Postgres sem reescrever a lógica.
Captação (LP)	HTML/CSS/JS estático	Hospedagem gratuita (GitHub Pages/Vercel/Netlify), carregamento rápido e SEO para IA via JSON-LD — relevante para indexação em buscas generativas (Perplexity, SearchGPT, Gemini).
Interface/Operação	Streamlit	Painel funcional em Python puro, sem front-end dedicado. Cobre o opcional "painel de monitoramento" e "interface protegida por senha" (login multiusuário com senhas em hash).
Config/Segredos	python-dotenv	Carrega `ANTHROPIC_API_KEY` e parâmetros (`VIGIL_EVENT_DATE`, `APP_PASSWORD`) do `.env`, mantido fora do versionamento.
Dados/Tabelas	pandas	Leitura e exibição tabular no painel.

Canal de comunicação: combinação WhatsApp + E-mail. Justificativa pelo público (CISOs/CTOs/diretores): o WhatsApp tem altíssima taxa de abertura e é ideal para lembretes curtos e confirmação (reduz no-show); o e-mail carrega credibilidade executiva e conteúdo mais rico (agenda, recap, materiais). No protótipo o envio é simulado (o conteúdo é gerado e persistido em interaction_logs), com a arquitetura isolando geração de envio para plugar Twilio/Meta (WhatsApp) ou SMTP/SendGrid (e-mail) sem refatorar a lógica.

4. Réguas de comunicação

As duas réguas são personalizadas pelo enriquecimento (cargo real, setor, porte e dores) e segmentadas pela origem do lead (Remarketing vs LP_Organico).

4.1 Régua PRÉ-evento (confirmação · anti no-show)

Regras de negócio (gatilhos, condições, timing):

Timing	Canal	Tipo	Regra de negócio
D-14	E-mail	`Boas_Vindas`	Ancoragem de valor: conecta as dores do lead às palestras/demos.
D-7	WhatsApp	`Pedido_Confirmacao`	Gatilho de compromisso + regra de acompanhante (convida a trazer o CTO/diretor de risco).
D-3	WhatsApp	`Gatilho_Escassez`	Escassez por proximidade (poucas vagas / lista de espera). Tom mais assertivo para quem ainda não confirmou.
D-1	WhatsApp	`Lembrete_Logistico`	Lembrete de véspera (horário, local) para cortar no-show de última hora.

Gatilho de compromisso (neurociência — commitment & consistency, Cialdini): a mensagem de confirmação induz o lead a responder com a frase exata "Eu irei ao evento". Quando essa resposta chega (receive_lead_response), o status vira Confirmado. A microdecisão pública de se comprometer aumenta a probabilidade de comparecimento.

Segmentação: leads de Remarketing (base de edições anteriores) abrem relembrando o relacionamento ("que bom te ver de volta"); leads orgânicos da LP são tratados como primeiro contato.

Exemplo de mensagem personalizada (lead: Carlos Mendes — Gerente Comercial Sênior, Varejo Mais, Varejo, +1000 func.; segmento Remarketing; canal WhatsApp; D-7):

Olá Carlos, que bom te ver de novo por aqui! 👋 No Vigil Summit deste ano teremos uma demo ao vivo de como blindar dados de clientes no varejo e manter a LGPD em dia sem travar a operação — exatamente a dor que mais pesa no seu setor. Como são só 120 vagas (e você pode trazer um diretor da sua equipe), me responda com "Eu irei ao evento" para eu garantir o seu lugar.

4.2 Régua PÓS-evento (follow-up comercial)

Timing	Canal	Tipo	Objetivo
D+1	E-mail	`Agradecimento_Recap`	Recap personalizado do que ele viu + CTA suave (conversa de 30 min).
D+3	WhatsApp	`Convite_Reuniao`	Proposta concreta de reunião com 2 horários + ROI ligado às dores.
D+7	E-mail	`Ultima_Chamada`	Última chamada para quem não respondeu + oferta de material de valor.

Régua paralela de no-show (Reengajamento_NoShow): quem confirmou mas não compareceu recebe uma trilha separada — empatia ("sentimos sua falta") + gravação das palestras + oferta de demo 1:1.

Exemplo de mensagem personalizada (lead: Mariana Lima — COO, TechCorp, SaaS B2B, 201-500 func.; status Presente; canal E-mail; D+1):

Assunto: Mariana, o próximo passo depois do Vigil Summit

Mariana, foi ótimo ter você no Vigil Summit! Na demo de monitoramento contínuo, mostramos como antecipar incidentes antes que virem exposição — algo crítico para uma operação SaaS B2B em crescimento como a da TechCorp, onde conformidade (SOC 2/LGPD) abre portas comerciais. Faz sentido marcarmos 30 minutos para eu te mostrar isso aplicado ao seu ambiente? Tenho agenda esta semana.

5. Estratégia de dados, personalização e LGPD

5.1 Coleta e armazenamento

Coleta: formulário da LP / painel (dados declarados: nome, e-mail corporativo, cargo, empresa, telefone).
Armazenamento: SQLite (vigil_summit.db), tabela leads (perfil + status) e interaction_logs (cada mensagem enviada e a resposta do lead — a memória de contexto do agente).

5.2 Como o enriquecimento funciona na prática

Entrada: nome, cargo declarado e empresa.
Processo: o Claude atua como "agente de inteligência de mercado B2B" e deduz cargo_real, setor, tamanho_empresa e sinais_interesse (dores prováveis), retornando JSON estrito validado pelo código.
Uso: os campos enriquecidos alimentam todas as mensagens das réguas — é o que torna o copy não-genérico.
Fonte (honestidade técnica): no protótipo o enriquecimento é uma dedução do LLM com base em padrões de mercado, não uma consulta a fontes externas. Em produção, plugaríamos enriquecimento real (LinkedIn/Apollo/Clearbit/Receita) antes da camada do LLM, mantendo a mesma interface.

5.3 Conformidade com a LGPD

Base legal: o titular fornece os dados ativamente ao se inscrever, com finalidade explícita (participação no evento e contato comercial) — consentimento + legítimo interesse.
Transparência: a LP informa, no formulário, que os dados são tratados conforme a LGPD.
Minimização: coletamos apenas o necessário para operar o funil.
Segredos e dados: .env e o banco local ficam fora do versionamento (.gitignore).
Direitos do titular: o modelo permite exclusão/atualização por registro (chave id/email), suportando solicitações de eliminação.
Coerência da automação: enriquecimento é dedução, não decisão automatizada com efeito jurídico sobre o titular.

6. Decisões estratégicas e racional

Três principais decisões

Campo origem explícito em vez de proxy por domínio de e-mail.
- Racional: remarketing se define pela fonte do lead, não pelo domínio corporativo. Segmentar por e-mail mandaria "que bom te ver de volta" para quem nunca teve contato — queimando lead.
- Alternativa descartada: email.endswith("@dominio") — frágil, acoplado e não-escalável.
- Ganho: personalização correta hoje e base pronta para o cenário de 10 eventos.
SDK nativo da Anthropic em vez de framework de agente.
- Racional: o funil é uma máquina de estados com etapas determinísticas; controle e transparência dos prompts valem mais que abstração.
- Alternativas consideradas: LangChain/CrewAI/Agno — descartadas para o MVP por adicionarem complexidade sem ganho proporcional. agno fica como rota de evolução para tool-use.
Envio simulado + persistência em interaction_logs, com canais desacoplados.
- Racional: o case aceita interações simuladas; o que importa é o fluxo demonstrável e a memória. Isolar "gerar" de "enviar" permite plugar WhatsApp/e-mail reais depois sem tocar na lógica.
- Alternativa descartada: integrar Twilio/Meta já no MVP — alto custo de setup e baixo retorno para a avaliação.

Referências de mercado / frameworks

Cialdini (gatilhos de commitment & consistency, escassez e prova social) nas réguas.
Boas práticas de réguas anti no-show de eventos B2B (sequência multi-toque por proximidade da data).
Modelo AAARRR / funil de eventos para a divisão captação → confirmação → presença → reunião.

7. Plano de execução (primeiros 5 dias)

Premissa: começo amanhã, com o protótipo atual já em mãos.

Dia 1 — Fundação e captação real. Provisionar ambiente (chaves Anthropic, deploy da LP em Vercel/Netlify) e conectar a LP ao banco via endpoint serverless (POST → insert_lead). Atacar a Captação primeiro, pois sem leads reais nada flui.
Dia 2 — Enriquecimento robusto. Plugar uma fonte real de enriquecimento (LinkedIn/Apollo) antes do LLM e tratar rate limits/erros; logar custo por lead.
Dia 3 — Réguas e agendador. Migrar de execução manual para scheduler (cron/APScheduler) disparando as etapas por proximidade da data; integrar canal real (WhatsApp via provedor).
Dia 4 — Loop de resposta. Substituir o match por frase exata por classificação de intenção (Claude) das respostas reais; webhooks de entrada e atualização de status.
Dia 5 — Observabilidade e hardening. Métricas do funil, alertas, testes e endurecimento de LGPD (política de retenção, opt-out). Migração SQLite → Postgres se o volume exigir.

8. Cenário de escala (pergunta bônus)

"Replicar para 10 eventos regionais simultâneos, com públicos distintos (manufatura, saúde, financeiro, governo), sem reescrever o agente."

A arquitetura já aponta para isso. As mudanças necessárias:

Multi-tenant por evento_id. Adicionar evento_id a leads e interaction_logs; todo o pipeline filtra por evento. Um único agente serve N eventos.
Configuração por evento (data-driven, não código). Cada evento tem um arquivo/registro de config: data, vagas, persona do público (manufatura, saúde…), tom e contexto de negócio. As réguas e prompts já recebem esse contexto por parâmetro — basta trocar a config, não o código.
Enriquecimento e copy sensíveis ao vertical. O setor/persona do evento entra no system prompt; o Claude adapta dores e exemplos (ex.: HIPAA-equivalente/dados de paciente para saúde; OT/ICS para manufatura; Bacen/PCI para financeiro; soberania de dados para governo).
origem por evento. O campo já distingue remarketing × orgânico — por evento, viabiliza réguas e públicos diferentes sem ambiguidade.
Orquestração e fila. Scheduler central + fila de mensagens (ex.: Celery/RQ) para paralelizar os 10 funis; banco em Postgres.

Resumo: o que muda entre eventos é dado/configuração (persona, datas, contexto), não a lógica do agente — exatamente o que evita reescrever do zero.

9. Como instalar e rodar

Ambiente Windows/PowerShell: use o launcher py (o comando python pode não estar disponível). Para scripts com emojis no console, use py -X utf8.

# 1. Dependências
cd vigil_summit_agent
py -m pip install -r requirements.txt

# 2. Configurar o ambiente: copie o .env.example para .env
#    copy .env.example .env   (Windows)   |   cp .env.example .env (Linux/Mac)
#    Escolha Anthropic ou Groq — veja a seção "Integração com LLM" abaixo.
#    (opcional) VIGIL_EVENT_DATE=2026-06-30
#    (opcional) APP_PASSWORD=uma_senha   -> protege o painel (padrao: vigil2026)

# 3. Criar e popular o banco
py -X utf8 database.py

# 4a. Rodar o agente via CLI
py -X utf8 agent.py enrich   # Fase 2 - enriquecimento
py -X utf8 agent.py engage   # Fase 3 - confirmação (neurociência) + respostas simuladas
py -X utf8 agent.py pre      # Fase 3 - régua pré-evento completa (4 toques)
py -X utf8 agent.py post     # Fase 4 - régua pós-evento
py -X utf8 agent.py demo     # funil completo de ponta a ponta

# 4b. Rodar LP + API + painel com um comando (recomendado)
py run_dev.py
#    LP  → http://localhost:8080
#    App → http://localhost:8501

# Ou, em dois terminais separados:
# py -m uvicorn api:app --reload --port 8080   → http://localhost:8080
# py -m streamlit run app.py                   → http://localhost:8501

A landing page (index.html) é servida pelo api.py (FastAPI) em http://localhost:8080. O formulário grava leads reais no SQLite; o painel Streamlit lê o mesmo banco.

Integração com LLM (Anthropic ou Groq)

O agente usa uma camada multi-provedor (agent._chat). Basta configurar LLM_PROVIDER e a chave correspondente — não é necessário alterar código.

Segurança: chaves de API nunca devem ir para o GitHub. O .env está no .gitignore. O .env.example traz apenas placeholders; quem for testar precisa criar a própria chave no console do provedor.

Opção A — Anthropic (Claude 3.5 Sonnet) · recomendado pelo case

Crie uma conta em console.anthropic.com.
Gere uma API key em Settings → API Keys.
No .env (local) ou Secrets (Streamlit Cloud / Render):

LLM_PROVIDER=anthropic
ANTHROPIC_API_KEY=sk-ant-api03-...sua_chave...
# opcional: ANTHROPIC_MODEL=claude-3-5-sonnet-20241022

Opção B — Groq (Llama 3.3 70B) · free tier para testes

Crie uma conta em console.groq.com.
Gere uma API key em API Keys.
No .env ou Secrets:

LLM_PROVIDER=groq
GROQ_API_KEY=gsk_...sua_chave...
# opcional: GROQ_MODEL=llama-3.3-70b-versatile

Onde configurar em cada ambiente

Ambiente	Onde colocar as variáveis
Local	`vigil_summit_agent/.env` (copie de `.env.example`)
Streamlit Cloud	App → Settings → Secrets (formato TOML). Modelo em `.streamlit/secrets.toml.example`
Render (API)	Service → Environment — LLM, scheduler, `VIGIL_API_KEY` e `SEED_TEST_LEADS`

Importante: no Streamlit Cloud, o LLM não roda no painel — fica na API (Render). Os Secrets do Streamlit precisam, no mínimo, de VIGIL_API_URL, VIGIL_API_KEY e APP_PASSWORD. Chaves ANTHROPIC_* / GROQ_* vão no Render, não no Streamlit.

Secrets mínimos no Streamlit Cloud (copie de secrets.toml.example):

VIGIL_API_URL = "https://vigil-summit-api.onrender.com"
VIGIL_API_KEY = "mesma_chave_definida_no_Render"
APP_PASSWORD = "vigil2026"

Exemplo completo no Render (Groq — free tier):

VIGIL_API_KEY=sua_chave_compartilhada
LLM_PROVIDER=groq
GROQ_API_KEY=gsk_...sua_chave...
ENABLE_SCHEDULER=true
SEED_TEST_LEADS=false

Exemplo completo no Render (Anthropic — recomendado pelo case):

VIGIL_API_KEY=sua_chave_compartilhada
LLM_PROVIDER=anthropic
ANTHROPIC_API_KEY=sk-ant-api03-...sua_chave...
ENABLE_SCHEDULER=true
SEED_TEST_LEADS=true

Como validar se está tudo conectado

API: GET https://vigil-summit-api.onrender.com/health → "status":"ok", "llm_configurado": true quando a chave LLM estiver correta no Render.
Painel local: com VIGIL_API_URL no .env, o topo exibe ☁️ Modo nuvem · API: …. Sem isso, aparece 💾 Modo local (SQLite desta máquina — não vê leads da LP online).
Painel Streamlit Cloud: obrigatório ter VIGIL_API_URL nos Secrets. Sem API configurada, o app bloqueia com instruções (não usa SQLite local enganoso). Com Secrets corretos, o topo mostra ☁️ Modo nuvem · API: ….
LLM no painel (barra lateral): em modo nuvem, o status do LLM reflete a configuração da API Render; localmente, reflete o .env.
CLI local: py -X utf8 agent.py enrich — se a chave estiver ausente, o script informa qual variável preencher.

Deploy simples (produção):

Componente	Onde	URL
Landing Page	GitHub Pages	https://irgomallis.github.io/vigil_summit_agent/
API de captação	Render (blueprint `render.yaml`)	https://vigil-summit-api.onrender.com
Painel Streamlit	Streamlit Community Cloud	https://vigilsummitagent.streamlit.app/

GitHub Pages — ativado via GitHub Actions (workflow .github/workflows/pages.yml). A LP envia inscrições para a API no Render.
Render (obrigatório para o formulário online) — Deploy to Render. Configure:
- VIGIL_API_KEY — mesma chave usada no Streamlit
- LLM_PROVIDER + ANTHROPIC_API_KEY ou GROQ_API_KEY (agente roda na API)
- ENABLE_SCHEDULER=true — régua automática diária (já no render.yaml)
- SEED_TEST_LEADS — true (default local) inclui a base via database.py
- SEED_SIMULATION_LEADS — true no Render (já no render.yaml) popula 22 leads de demonstração no startup
Valide: https://vigil-summit-api.onrender.com/health → "status":"ok", "llm_configurado": true.
Streamlit Cloud — vigilsummitagent.streamlit.app. Cole os Secrets de .streamlit/secrets.toml.example, salve e Reboot app. Confirme o banner ☁️ Modo nuvem · API: … após o login.

Com VIGIL_API_URL, o painel lê e opera leads da LP via API (enriquecer, engajar, demo). O LLM fica configurado no Render.

Três bancos — não confundir

Ambiente	Onde ficam os leads da LP
Render API	SQLite persistente no servidor Render
Streamlit Cloud	Não tem banco próprio — lê a API via `VIGIL_API_URL`
Streamlit local	SQLite local (`vigil_summit.db`) ou API, conforme `.env`

Entrega para a banca: roteiro completo em ENTREGA.md.

Nota: localmente LP + painel compartilham o mesmo SQLite (py run_dev.py). Na nuvem, a API (Render) centraliza dados e agente; o painel Streamlit Cloud sempre aponta para a API.

Base de leads de simulação (22 personas)

Catálogo em leads_simulacao.py — idempotente por e-mail (UNIQUE).

Dimensão	Variação
Status	Inscrito · Confirmado · Presente · Reunião Agendada
Origem	`LP_Organico` · `Remarketing`
Setores	Todos da LP + Outro
Cargos	CISO, CTO, Diretor de TI, VP Segurança, etc.
Enriquecimento	Mix enriquecido + 4 leads pendentes de Fase 2

Inclui ramon@pareto.io (case Pareto).

Local:

cd vigil_summit_agent
py -X utf8 leads_simulacao.py
# ou: py -X utf8 database.py

Render (automático): SEED_SIMULATION_LEADS=true no render.yaml → seed no startup da API após deploy.

Render (manual, após deploy):

py -X utf8 leads_simulacao.py --remoto

Requer VIGIL_API_URL + VIGIL_API_KEY no .env. Endpoint: POST /api/admin/seed-simulation (header X-API-Key). Faz insert ou update por e-mail (perfis completos com status e origem).

Fallback (API ainda sem redeploy):

py -X utf8 leads_simulacao.py --inscricao-remoto

Envia os 22 leads via POST /api/inscricao (todos como Inscrito / LP_Organico). Depois do redeploy, rode --remoto ou aguarde o startup com SEED_SIMULATION_LEADS=true para atualizar os perfis completos.

10. Como testar (acesso para a Pareto)

Provedor de LLM: fica a critério de quem testa — Anthropic (Claude) ou Groq. Instruções completas na seção Integração com LLM. Nenhuma chave real é versionada no repositório.

Acesso ao painel (login): o painel é protegido por login de usuário + senha. Na primeira execução, um usuário inicial é criado automaticamente:
- Usuário: admin · Senha: vigil2026 (ou o valor de APP_PASSWORD, se definido).
- Na aba "👤 Usuários" é possível criar e remover outros usuários da equipe. As senhas são guardadas apenas como hash PBKDF2-HMAC-SHA256 com salt (nunca em texto puro). Há travas de segurança: não é possível remover o próprio usuário conectado nem deixar o painel sem nenhum acesso.
O banco local vem com 22 leads de simulação (leads_simulacao.py), incluindo ramon@pareto.io. No Render, SEED_SIMULATION_LEADS=true popula a mesma base no startup (idempotente).
Fluxo recomendado de teste (nuvem — igual à Pareto):
1. Inscreva-se pela LP online.
2. Abra o painel Streamlit → login admin / vigil2026 → confirme ☁️ Modo nuvem no topo.
3. Aba Leads → veja a base de simulação (22+) e novos inscritos da LP.
4. Operar o agente → Fases 2–4 ou Demo ponta a ponta.
Fluxo local (demo ao vivo):
1. py -X utf8 database.py (cria o banco + seed).
2. py run_dev.py ou py -m streamlit run app.py com .env preenchido.
3. LP em http://localhost:8080 · painel em http://localhost:8501.
4. Para ver leads da LP online no painel local, adicione VIGIL_API_URL + VIGIL_API_KEY no .env (mesma chave do Render).
O painel é organizado em abas: Visão geral (KPIs e funil de conversão), Leads (tabela e detalhe), Operar o agente (Fases 2–4), Interações (log completo) e Usuários (controle de acesso).
As ações de IA exigem chave LLM no .env local ou no Render (modo nuvem). Sem chave, o funil é exibido, mas geração fica indisponível.

11. Modelo de dados

Tabela `leads`

Campo	Tipo	Notas
`id`	INTEGER PK	autoincremento
`nome`	TEXT NOT NULL
`email`	TEXT UNIQUE NOT NULL
`telefone`	TEXT
`cargo_declarado`	TEXT	informado na captação
`empresa`	TEXT
`cargo_real`	TEXT	enriquecido
`setor`	TEXT	enriquecido
`tamanho_empresa`	TEXT	enriquecido
`linkedin_perfil`	TEXT
`sinais_interesse`	TEXT	enriquecido (dores)
`origem`	TEXT	`LP_Organico` \| `Remarketing` (default `Remarketing`)
`evento_id`	TEXT	identificador do evento (default `vigil_summit_2026`; prepara multi-evento)
`status_funil`	TEXT	`Inscrito`/`Confirmado`/`Presente`/`Reunião Agendada` (default `Inscrito`)
`data_inscricao`	DATETIME	default `CURRENT_TIMESTAMP`
`updated_at`	DATETIME	atualizado por trigger em cada UPDATE

Tabela `interaction_logs`

Campo	Tipo	Notas
`id`	INTEGER PK	autoincremento
`lead_id`	INTEGER	FK → `leads(id)`
`fase_funil`	TEXT	ex.: `Pre-Evento`, `Pos-Evento`
`canal`	TEXT	`WhatsApp`, `E-mail`
`tipo_mensagem`	TEXT	ex.: `Confirmacao_Neurociencia`, `Convite_Reuniao`
`conteudo_enviado`	TEXT	mensagem gerada pelo LLM
`resposta_lead`	TEXT	resposta simulada do lead
`data_envio`	DATETIME	default `CURRENT_TIMESTAMP`

Tabela `users`

Campo	Tipo	Notas
`id`	INTEGER PK	autoincremento
`username`	TEXT UNIQUE NOT NULL	usuário de acesso ao painel
`password_salt`	TEXT NOT NULL	salt aleatório por usuário
`password_hash`	TEXT NOT NULL	hash PBKDF2-HMAC-SHA256 (200k iterações)
`created_at`	DATETIME	default `CURRENT_TIMESTAMP`

12. Limitações e decisões conscientes

Captação da LP é real via POST /api/inscricao (api.py → insert_lead, origem LP_Organico). LP e painel compartilham o mesmo SQLite localmente; na nuvem, a LP grava no Render e o painel lê via VIGIL_API_URL.
Streamlit Cloud exige modo nuvem — sem VIGIL_API_URL nos Secrets, o painel bloqueia com instruções (evita SQLite isolado no container).
Seed de leads de simulação — leads_simulacao.py (22 personas); Render usa SEED_SIMULATION_LEADS=true; re-seed manual via POST /api/admin/seed-simulation.
Envio de mensagens é simulado (persistido em interaction_logs), com canais desacoplados para integração futura.
Enriquecimento é dedução do LLM, não consulta a fontes externas (substituível sem mudar a interface).
Confirmação de presença usa frase exata ou classificação de intenção via LLM (_confirma_presenca).
Scheduler automático na API (ENABLE_SCHEDULER=true) dispara réguas diárias no Render.
SQLite atende o protótipo; coluna evento_id prepara multi-evento; Postgres previsto no plano de escala.

Entrega para a Pareto

Roteiro de teste, links, credenciais e checklist de deploy: ENTREGA.md.

Estrutura do projeto

Case - AI Engineer (2026)/
├── index.html                 # Landing page de captação (Fase 1)
├── README.md                  # Documentação técnica
├── ENTREGA.md                 # Roteiro de entrega para a Pareto
├── render.yaml                # Blueprint Render
├── .gitignore
└── vigil_summit_agent/
    ├── .env                   # segredos (fora do versionamento)
    ├── .env.example
    ├── .streamlit/
    │   ├── config.toml
    │   └── secrets.toml.example   # modelo para Streamlit Cloud Secrets
    ├── database.py            # schema, seed e acesso ao SQLite
    ├── leads_simulacao.py     # catálogo de 22 leads + seed local/remoto
    ├── agent.py               # cérebro do agente (Fases 2, 3 e 4)
    ├── api.py                 # API FastAPI + agente remoto + scheduler
    ├── api_client.py          # cliente HTTP para o painel na nuvem
    ├── app.py                 # painel Streamlit (operação e monitoramento)
    ├── run_dev.py             # LP + API + painel com um comando
    ├── requirements.txt
    └── vigil_summit.db        # banco (gerado ao rodar database.py; gitignored)

Name		Name	Last commit message	Last commit date
.devcontainer		.devcontainer
.github/workflows		.github/workflows
vigil_summit_agent		vigil_summit_agent
.gitignore		.gitignore
Case - AI Engineer (2026).pdf		Case - AI Engineer (2026).pdf
ENTREGA.md		ENTREGA.md
README.md		README.md
index.html		index.html
render.yaml		render.yaml

Latest commit

History

Folders and files

Repository files navigation