Camada 1
Entrada conversacional operacional via Evolution API. Twilio WABA permanece como opção suportada para cenários institucionais.
Infraestrutura conversacional vertical · v1.1.0
Conversa que vira operação controlada.
Plataforma para WhatsApp com NLU híbrido, RAG tenant-aware, tool use com confirmação no Cockpit e foundation para adapters de ERPs SMB brasileiros.
PMEs brasileiras vendem e atendem pelo WhatsApp, mas os ERPs que sustentam a operação não foram desenhados para conversar. O resultado é gente copiando dado entre chat, agenda, estoque, financeiro e CRM.
Luna ocupa esse espaço: conversa natural na ponta e caminho controlado para write-back no backend.
Canal
WhatsApp como balcão principal
Sistema
ERP nacional sem camada de IA
Automação
Fluxos fixos e pouco integrados
Lacuna
Agente que conversa, decide e escreve de volta
Seis camadas com fronteira clara. Cada uma faz uma coisa e faz bem.
1 · WhatsApp
Evolution API · Twilio WABA
2 · NLU híbrido
regex + Haiku 4.5 / Sonnet 4 por contexto
3 · Flow Runtime
FSM + estado preservado
4 · RAG tenant-aware
admin_rag_documents · cosine
5 · Integration Hub
foundation · interfaces + registry
6 · Adapters
PrintWayy em construção
Camada 1
Entrada conversacional operacional via Evolution API. Twilio WABA permanece como opção suportada para cenários institucionais.
Camada 2
Regex para atalhos; Claude Haiku 4.5 ou Sonnet 4 escolhido por contexto; clarificação como fallback quando a intenção não fecha.
Camada 3
Máquina de estados híbrida com sessão e contexto preservados. O padrão plan-confirm-apply já opera no Cockpit administrativo.
Camada 4
Hoje via admin_rag_documents com embeddings isolados por tenant e similaridade cosine. Consolidação pgvector/HNSW está no desenho de performance.
Camada 5
Foundation inspirada em Model Context Protocol: interfaces por categoria e registry com cache por tenant já implementados.
Camada 6
PrintWayy é o primeiro adapter externo em construção. Writes auditados e tabela dedicada fazem parte deste marco de implementação.
Padrão validado no Cockpit da Luna: toda ação sensível passa por plan → confirm → apply. Estamos estendendo esse mesmo padrão aos adapters externos do Integration Hub.
Caso-alvo · PrintWayy adapter (em construção)
// apps/flows-backend/src/integrations/adapters/printwayy.adapter.ts
const transferStockItemTool: AnthropicTool = {
name: "printwayy_transfer_stock_item",
description:
"Transfere quantidade de item de estoque entre localizações no " +
"PrintWayy. sourceCustomerPlaceId vazio = origem é o provedor. " +
"destCustomerPlaceId vazio = destino é o provedor.",
input_schema: {
type: "object",
properties: {
stockItemId: { type: "string", format: "uuid" },
quantity: { type: "integer", minimum: 1 },
sourceCustomerPlaceId: { type: "string", format: "uuid" },
destCustomerPlaceId: { type: "string", format: "uuid" }
},
required: ["stockItemId", "quantity"]
}
}; Caso-alvo · fluxo do adapter PrintWayy
No Cockpit, writes só disparam após confirmação explícita. Plan sozinho retorna preview, não executa.
O Cockpit registra pending actions e auditoria; a tabela dedicada a adapters externos é o próximo marco.
Request ID determinístico e retry seguro são requisitos definidos para o adapter PrintWayy em construção.
Cada peça escolhida pra resolver um problema específico em produção. Sem stack-by-trend.
Decisão
Motivo técnico
01
Plan-confirm-apply garante ação somente com confirmação explícita no Cockpit, antes de aplicar mudanças sensíveis.
02
Documentos e embeddings isolados por tenant hoje. Consolidação pgvector/HNSW está no desenho de performance.
03
Tenant aplicado nas consultas, no admin e nos fluxos. A base atual convive com UUID e slug por camada.
04
Haiku 4.5 atende contextos simples; Sonnet 4 cobre contextos críticos e raciocínio. Otimiza custo sem perder qualidade.
05
Build estático com hidratação seletiva para uma landing rápida e de baixa complexidade operacional.
06
Type-safe queries em build time. Migrations idempotentes. Compatível com Railway, Supabase, AWS RDS.
07
Canal operacional da DG. Twilio WABA disponível para tenants que exigem uma configuração oficial.
08
Validação em runtime já é padrão nas rotas. Os adapters externos devem seguir o mesmo contrato tipado.
A foundation do Integration Hub está implementada: interfaces por categoria (ERP, Payment, Calendar, CRM), registry com cache por tenant e manifest declarativo. O primeiro adapter concreto — PrintWayy — está em desenvolvimento, baseado nos 35 endpoints reais da API PrintWayy Dragon.
Vertical declara
manifest.integrations[]
Hub resolve
config do tenant
Adapter conecta
em construção
Sistema externo
POST / GET
Snippet 1 · Manifest do vertical (declarativo)
// apps/verticals/outsourcing/manifest.ts
import type { VerticalManifest } from '@/types/vertical-manifest';
export const manifest: VerticalManifest = {
slug: 'outsourcing',
name: 'Outsourcing de Impressão',
industry: 'outsourcing',
schemaPrefix: 'os_',
integrations: [
{
name: 'printwayy',
type: 'erp',
required: false,
capabilities: ['read', 'write'],
configFields: [
{ key: 'api_key', type: 'secret', required: true },
{ key: 'company_id', type: 'string', required: true }
],
adapterPath: '@adapters/printwayy.adapter'
}
],
customIntents: [
'novo_chamado',
'status_chamado',
'consultar_estoque',
'transferir_estoque',
'consultar_fechamento',
'consultar_contrato'
],
ragAutoIndex: true,
ragDocsPath: 'apps/verticals/outsourcing/skills'
}; Spec do adapter · em construção
// apps/flows-backend/src/integrations/adapters/printwayy.adapter.ts
export class PrintWayyAdapter implements ERPAdapter {
// ... 35 métodos: 26 read + 9 write em V2
async transferStockItem(
input: TransferStockItemInput
): Promise<IntegrationResult<TransferResult>> {
// Validação Zod em runtime
const parsed = TransferStockItemSchema.safeParse(input);
if (!parsed.success) {
return { status: 'invalid_request', error: { ... } };
}
// Audit log antes da chamada
const auditId = await this.auditWrite({
tool: 'transfer_stock_item',
input: parsed.data
});
// Chamada com retry exponencial + timeout 8s
const response = await this.request('/stock/transfer-stock-item', {
method: 'POST',
body: parsed.data,
retries: 3,
timeout: 8000
});
// Audit log final com resposta
await this.auditComplete(auditId, response);
return response;
}
} ERP, Payment, Calendar e CRM têm interfaces preparadas para adapters concretos.
A foundation permite trocar ERP sem redesenhar a lógica vertical quando os adapters estiverem conectados.
Outsourcing é o primeiro marco em construção; clínica e advocacia permanecem no roadmap.
A foundation declarativa já existe: manifest, loader e template. A operação DG está em produção; o pack de outsourcing está scaffoldado, com flow e adapter ainda em construção.
Exemplo da estrutura · flow.json ilustrativo
{
"id": "outsourcing-main",
"name": "Outsourcing — fluxo principal",
"version": "1.0",
"nodes": [
{
"id": "start",
"type": "trigger",
"intent": "any",
"next": "identify_caller"
},
{
"id": "identify_caller",
"type": "lookup",
"adapter": "printwayy",
"method": "getCustomerByName",
"input": "{{ message.author_name }}",
"next": {
"found": "main_menu",
"not_found": "handoff_human"
}
},
{
"id": "main_menu",
"type": "ai_response",
"model": "haiku-4.5",
"context_window": "vertical_outsourcing"
}
]
} Exemplo da estrutura · nlu-intents.ts
// apps/verticals/outsourcing/nlu-intents.ts
export const intents = [
{
id: 'consultar_fechamento',
patterns: ['fechamento', 'fatura', 'invoice'],
examples: [
'fechamento de maio do cliente XPTO',
'qual minha fatura desse mês',
'lista os fechamentos pendentes'
]
},
{
id: 'transferir_estoque',
patterns: ['troquei', 'transferir', 'estoque'],
examples: [
'troquei toner ciano no cliente Y',
'transfere 3 toners do estoque do Marcos pro XPTO',
'baixa 1 cartucho do meu estoque'
],
requiresWrite: true // ← força plan-confirm-apply
}
]; Cada status registra o estágio real: produção comprovada, foundation implementada, construção ativa ou visão de roadmap.
Caso-alvo em construção, em parceria com a equipe PrintWayy. As conversas abaixo demonstram o fluxo que estamos implementando, baseado nos 35 endpoints reais da API PrintWayy Dragon (26 de leitura + 9 de escrita V2).
CONVERSA A · DONO · LEITURA
demonstração do fluxo planejado
Luna Bot
online
Fechamento de maio do cliente XPTO.
09:12
Fechei mês 05/2026 pro cliente XPTO. Receita bruta R$ 18.420, 3 chamados em aberto. Aqui o PDF do extrato.
PDF fechamento-xpto-05-2026.pdf 1.4 MB09:12
Qual minha receita total mensal projetada?
09:13
R$ 247.320 nos 12 contratos ativos. 3 contratos vencem em 30 dias.
09:13
Quais?
09:14
· XPTO Ltda — vence 15/06 · MegaCopias — vence 22/06 · Print4U — vence 28/06 Quer que eu prepare email de renovação pros 3?
09:14
Pode preparar.
09:15
Drafts gerados. Mando aqui pra você revisar antes de enviar.
09:15
CONVERSA B · TÉCNICO · ESCRITA + PLAN-CONFIRM-APPLY
demonstração do fluxo planejado
Luna Bot
online
Troquei toner ciano no cliente XPTO, impressora SN-ABC123.
14:31
🔍 Identifiquei: · Cliente: XPTO Ltda (place_id 2b25…) · Impressora: Lexmark MS621dn (SN-ABC123) · Toner compatível: 56F4U00 high yield 📋 Plano de ação: · Transferir 1 toner do teu estoque → cliente XPTO · Teu estoque ciano: 4 → 3 unidades · Estoque alocado ao cliente: 0 → 1 Confirma?
14:31
Confirma.
14:32
✅ Transferência registrada no PrintWayy. · audit_id: aud_2826ff21 · Estoque atualizado.
14:32
Não vai ser chatbot. Vai ser operador estruturado. O adapter PrintWayy é o marco atual de construção.
Resolvem coisas diferentes. Combinam bem.
Decisão
n8n
If/then fixo
Luna
Tool use validado no Cockpit
Mudança de fluxo
n8n
Edição visual do grafo
Luna
Manifest declarativo (foundation)
Linguagem natural
n8n
Trigger via keyword
Luna
NLU híbrido state-aware
Plan-confirm-apply
n8n
Manual no fluxo
Luna
Produção no Cockpit; adapters em extensão
Multi-tenant
n8n
Workflow separado por cliente
Luna
Tenant isolado nativo (JWT)
Audit log
n8n
Custom
Luna
Cockpit ativo; adapters em construção
Compliance
n8n
Custom
Luna
Controles declarados por estágio
Onde brilha
n8n
Automação backend, integrações
Luna
Atendimento conversacional, vendas, suporte
— Combinação ideal
n8n no backend, Luna no front-WhatsApp.
Cliente que precisa de automação interna (sync entre sistemas, ETL, integrações backend) + atendimento conversacional vai usar os dois, não escolher entre.
Multi-tenant + IA + ERP write exige transparência operacional. Os controles ativos e os próximos marcos estão declarados separadamente.
01
Requests HTTP e erros operacionais geram logs estruturados com contexto de tenant e duração.
02
Audit log validado no Cockpit com admin_audit_logs e pending actions. A tabela integration_writes_audit está no marco dos adapters externos.
03
O flows-backend responde /health em produção com status saudável e versão atual do serviço.
04
Primeira mensagem do bot identifica explicitamente "você está falando com IA da [empresa]". PL 2338 art. 11.
05
Comando "atendente" ou "humano" sempre escala. Sem fricção. PL 2338 art. 12.
06
Políticas formais de retenção e anonimização configurável por tenant seguem no marco de compliance.
Formato planejado · audit log de integração
{
"audit_id": "aud_2826ff21",
"tenant_id": "550e8400-e29b-41d4-a716-446655440000",
"user_phone": "+5521987654321",
"tool_name": "printwayy_transfer_stock_item",
"input": {
"stockItemId": "9ae021f3-84e3-4f4a-9ff2-4ae63c394791",
"quantity": 1,
"sourceCustomerPlaceId": "tech_marcos_id",
"destCustomerPlaceId": "2b255a86-bf14-4ca5-b4cb-e7dc678eae07"
},
"phase": "apply",
"confirmed_by": "+5521987654321",
"confirmed_at": "2026-05-21T14:32:18.234Z",
"response_status": 200,
"latency_ms": 412,
"request_id": "req_4f1a2b3c"
} Métricas persistidas do tenant DG, coletadas em 23 de maio de 2026.
230
bdb_appointments
148
status completed
237
fb_leads
6
bdb_subscribers
74
desde março/2026
Barbearia única em Vila Isabel, Rio de Janeiro. Operação solo, contínua desde março de 2026. Bot atende, agenda, confirma, qualifica leads e mantém assinaturas recorrentes — sem intervenção humana no fluxo padrão.
concluído
em execução
planejado
futuro
Roadmap detalhado disponível para parceiros após NDA. Versão pública sincronizada com commits no monorepo.
WhatsApp do Breno. Sem formulário, sem funil.
WhatsApp direto · +55 21 99962-4264