A infraestrutura de IA dos nossos produtos.
Plataforma e produtos de IA em produção. Mesma stack, mesma disciplina de engenharia, mesmo dev por trás. Código pensado pra durar mais que o ciclo do hype.
Como construímos.
Três princípios que separam software que sobrevive ao primeiro pico de tráfego de software que vira pedido de desculpas.
Plataforma e produto.
Forgem é a plataforma — agentes WhatsApp com pipeline de 6 estágios, orquestrador multi-LLM, infra edge, observability nativa. Em cima dela rodam produtos próprios. Hoje, Ghost Workforce. Mais virão na ordem que faz sentido pro mercado, não na ordem que vende slide.
Cada produto vive em domínio próprio, com auth e banco próprios. O que conecta é a engenharia compartilhada: mesma stack, mesma disciplina de testes, mesmo dev decidindo cada release. Operação enxuta porque tudo herda da mesma base.
O produto.
Em produção hoje. Domínio próprio, posicionamento próprio, dados primários. Construído sobre a plataforma Forgem.
O que está rodando.
Stack enxuta. Cada peça aqui está em produção, não em roadmap. Sem Docker, sem VPS, sem cold start.
Como opero.
Decisões técnicas e processos sem make-up.
Por que produtos em domínios separados em vez de um SaaS único?
Cada produto resolve um problema distinto pra um público distinto. Forçar um domínio único diluiria SEO. Cada um tem sitemap próprio, schema.org nativo, canonical estrito, voz editorial autoral. O que une é a engenharia por trás (stack, padrões, processos de deploy), não a marca na frente.
Pipeline de deploy?
npm test roda 227 testes em Vitest antes de qualquer push. npx wrangler deploy sobe atômico em 13–16s, com Version ID por release. Rollback em um comando. /health valida D1 connectivity pós-deploy. Worker startup ~14ms — CDN e compute na mesma camada.
Como o agente realmente pensa?
Pipeline de 6 estágios, não chamada LLM crua: pre-processor classifica intent (forgem-fast), memória rolante carrega summary + facts, RAG só roda se necessário (BGE-M3 + top-K=4), build de mensagens junta tudo, geração principal (forgem-balanced default), pós-processamento async grava custo BRL e atualiza memória. Cada peça falha em silêncio com fallback — pipeline nunca trava.
Observability — o que de fato está medido?
Cada mensagem do agente grava cost_brl, prompt_tokens, completion_tokens e latency_ms em D1. auth_event_log persiste cada tentativa de sign-in com result code. Cloudflare Observability binding habilitado no Worker. p50 latency e taxa de erro 24h visíveis em /app/usage. Sem Slack alerts ainda — vem quando fizer sentido.
API pública e API keys?
API keys já em produção em /app/api-keys — geração com revelação única, revogação imediata, rate limit por chave. Endpoint /v1/chat/completions compatível com formato OpenAI pra zero-friction migration. Webhooks de eventos críticos (magic link usado, sign-in) gravados; export de eventos sob request.
Residência de dados e LGPD?
D1 hoje em ENAM (Miami) — migração pra SAM (São Paulo) entra quando Cloudflare promover SAM pra D1 GA. Magic link uso único, expira em 15min. Sessão expira por inatividade. Constant-time compare em todo token sensível. Zero venda de lista, zero retargeting pago. Export em JSON sob request.
O que NÃO tem ainda?
SSO unificado entre os 4 produtos (a tabela sso_grants existe, mas só Forgem.dev consome hoje). Stripe billing BRL/Pix tá codificado, em fase de validação. Slack alerts. Logpush. Region SAM pra D1. Tudo isso vem na ordem que faz sentido — não na ordem que vende bonito.
Conversa é como começa.
Manda mensagem. Você fala com quem constrói — não com chatbot, não com SDR, não com formulário de qualificação.
Abrir conversa no WhatsApp