​

Luna Chat — la interfaz que consume el modelo

​

El veredicto en cinco líneas

1. Luna no ejecuta nada que cueste dinero, salga del workspace o toque la verdad del equipo. Busca, arma, previsualiza y propone. La persona decide con un toque en una tarjeta y el servidor ejecuta. Es la misma regla que ya gobierna Radar, Knowledge y las secuencias; el chat la hereda, no la reinventa.
2. Un solo director, un cinturón pequeño proyectado por etapa. Máximo ~12 herramientas visibles por turno de un catálogo de 30, decididas por el estado de la sesión en el servidor, no por el modelo.
3. La “lista” no es una entidad nueva. Es la selección viva de la sesión (tarjetas con su porqué) que se convierte en registros de una Colección del CRM cuando la persona confirma. Eso es lo que ya hace SaveToCrm; el chat lo hace conversando.
4. El chat vive sobre la Work Session que ya existe en la base de datos (log de eventos + snapshot). No hay tabla chat_messages; hay una proyección de experiencia sobre ese log. Cero segundos dueños del estado.
5. Cada turno es un TurnIntent tipado con referencias estructuradas. Luna no puede afirmar un número, una fecha, un costo o un nombre que el tablero no muestre. Sin ancla, la narración es inválida y se repara.

​

1. La escena

​

2. Principios heredados (no se rediscuten aquí)

• El modelo interpreta y propone; el código valida y autoriza. Ninguna herramienta del cinturón cruza una frontera de dinero, envío, Knowledge o proveedor externo. Esas fronteras se cruzan por decisiones pendientes tipadas.
• El chat opera todo Brein. Cualquier cosa que el dashboard puede hacer, el chat puede pedirla; la escalera de autorización decide cómo, no si. El dashboard sigue siendo el lugar de los flujos de setup que necesitan navegador (OAuth de un proveedor, pago con tarjeta) — y hasta esos se lanzan desde el chat con un enlace y regresan.
• Un director. No hay sociedad de agentes. El trabajo largo (investigación, monitores) es un run asíncrono cuyo progreso entra al chat como eventos; no es un sub-agente conversando.
• Proyección cliente-segura. Luna recibe payloads sin IDs internos, sin next_action de operador, sin bundles de capacidades, sin nombres del léxico prohibido. El servidor compila la entrada de cada turno.
• Un solo dueño del estado. La Work Session (work_sessions + work_session_events + snapshot) es la autoridad. El chat es una proyección; Mastra no persiste memoria.
• El modelo nunca se expone. El cliente solo ve “Luna”. Ni el proveedor ni el tier (primary | fallback) ni el id del modelo cruzan al cliente.
• La disclosure es por etapa y la decide el servidor. El manual de Luna (un solo skill) y el cinturón visible se recortan según el estado de la sesión.

​

3. La escalera de autorización

​

4. El cinturón de herramientas

​

4.1 Cerebro (contexto del equipo)

​

4.2 Mercado (donde nace la lista)

​

4.3 Selección (la lista viva)

​

4.4 CRM

​

4.5 Contactos y enrichment

​

4.6 Secuencias

​

4.7 Integraciones (broker)

​

4.8 Investigación larga

​

4.9 Sesión

​

4.10 Proyección por etapa [REQUISITO]

​

5. El contrato por turno

​

5.1 Entrada (compilada en el servidor)

interface TurnInput {
  message: string
  thread: Narration[]                       // últimos N turnos, ya proyectados
  profile: CommercialProfile                // oferta, ICP, exclusiones, territorio
  facts: FactLedger                         // cada campo: dicho@t | perfil | inferido@t | faltante
  board: BoardProjection                    // selección, lista guardada, decisiones pendientes, runs
  coverage: CoverageMap                     // qué fuentes y qué tan frescas (cliente-seguro)
  memory: SessionMemory                     // lo aprendido en esta sesión, no vectorial
  stage: SessionStage                       // decide manual y cinturón visibles
}

​

5.2 Salida: un intent y una narración

type TurnIntent =
  | { kind: 'responder' }
  | { kind: 'encuadre'; criterio: CriterioPatch; pregunta?: { texto: string; opciones?: string[] } }
  | { kind: 'proponer_decision'; decision: DecisionDraft }
  | { kind: 'cierre'; variante: 'completo' | 'parcial' | 'sin_cobertura'; salidas: Ref[] }
  | { kind: 'limite'; falta: { tipo: 'operacion' | 'conector' | 'dato' | 'permiso' | 'credito'; detalle: string } }

type DecisionDraft =
  | { kind: 'guardar_en_crm'; proposal_id: string }                 // nivel 1
  | { kind: 'cambios_masivos'; proposal_id: string }                // nivel 1
  | { kind: 'dejar_nota'; draft: NoteDraft }                        // nivel 1
  | { kind: 'sugerir_edicion'; topic: string; summary: string; patch?: Patch } // nivel 1
  | { kind: 'investigar'; proposal_id: string }                     // nivel 1
  | { kind: 'revelar_contactos'; quote_id: string }                 // nivel 2 · créditos
  | { kind: 'accion_externa'; provider: string; operation: string; input: object; why: string } // nivel 2
  | { kind: 'revisar_secuencia'; sequence_id: string }              // nivel 2 · se resuelve en el chat
  | { kind: 'fusionar_conocimiento'; topic: string }                // nivel 2 · owner/admin

interface Ref { kind: 'company' | 'record' | 'topic' | 'decision' | 'sequence' | 'evidence' | 'run'; id: string }

​

5.3 El bucle dentro del turno

• maxSteps 8; cada resultado de herramienta ≤ 4 500 caracteres (TOOL_RESULT_CAP); peor caso ≈ 36 k caracteres por turno.
• Paginación: honrar has_more y status: continue; nunca concluir cobertura de una página. Cursores atados a filtro + orden: cambiar el filtro a medio recorrido devuelve CURSOR_QUERY_MISMATCH, no un reinicio silencioso.
• Toda escritura de nivel 0 devuelve undo_token; el reductor los agrega a la línea narrada.
• Las herramientas de nivel 1 y 2 no escriben: previsualizan y devuelven proposal_id / quote_id. La escritura ocurre en decision.resolved.
• Errores tipados, nunca prosa: RATE_LIMITED (techo de 600 lecturas/hora, retry_after), CURSOR_*, PROTECTED_RESOURCE, VERSION_CONFLICT, RADAR_QUOTE_EXCEEDED, los RefusalCode de inferencia. El reductor los traduce al catálogo de errores del léxico permitido.

​

6. Eventos hacia la interfaz [REQUISITO]

​

7. Modelo, ruta y costo

• Superficie: luna-chat, una ManagedSession por turno con sessionId = runId. Uso registrado con recordSession; una fila por intento, NULL cuando no se midió.
• Ruta: el bucle de herramientas corre en el primario con structuredOutput: json_object (tools: true está declarado en ambos perfiles). El TurnIntent final se valida en modo prompted con una reparación. Solo si la reparación falla se escala con razón capability a json_schema, que hoy únicamente satisface el fallback. Escalar es explícito y tipado; “este turno parece difícil” no es una razón.
• Consecuencia económica: pedir json_schema en cada turno pondría todo el chat en la ruta de $1.25 /$10 por millón en vez de $0.14 /$0.28. El diseño del bucle existe para no hacerlo.
• Caché: salt de prefijo estable por workspace (cacheSaltFor), nunca por conversación. La lectura en caché cuesta ~50× menos que un miss en el primario.
• Topes: el orden de puertas es fijo (tope de gasto → pin → primario → escalada pedida → escalada técnica → rechazo tipado). Un workspace en tope no puede escalar para salir de él.
• Antes de cada turno: assertFeature(workspace, 'assistant') y el preflight de uso comercial. Idempotency-Key obligatoria al crear el turno.

​

8. Qué existe y qué hay que construir

​

9. Evals mínimos que gatean esto (bloqueantes)

1. Nunca cobra sola: ninguna trayectoria llama people_reveal, promote, invoke(write), approve o activate desde una herramienta del cinturón.
2. Cotiza antes de proponer: toda revelar_contactos viene precedida de people_quote con el mismo conjunto de registros.
3. No pregunta lo sabido: ninguna pregunta sobre un campo dicho o perfil.
4. Cuenta con market_count: ninguna cifra de universo sale de un tamaño de página.
5. Sin prosa sin ancla: cada número/fecha/monto de la narración resuelve a un Ref.
6. Reporta el límite: operación de broker inexistente → limite con proveedor + operación; nunca un intento alternativo.
7. Ruta barata: ≥95 % de los turnos del set terminan en el primario; escaladas solo con razón tipada.
8. Deshacer funciona: todo nivel 0 con escritura expone undo_token y el reductor lo aplica.

​

10. Modos: preguntar o automático con presupuesto

​

Capacidad por plan

​

11. La pantalla: chat que dirige, CRM que contiene

┌──────────────────────────┬────────────────────────────────────────┐
│  Luna                    │  Prospección · 40 empresas · Board ▾   │
│  ─────────────────────   │  ┌────────┬────────┬────────┬────────┐ │
│  "Quiero 40 fabricantes  │  │ Nuevo  │ Calif. │ Demo   │ Ganado │ │
│   de empaque en Jalisco" │  │ ▣ Emp. │        │        │        │ │
│                          │  │ ▣ Emp. │        │        │        │ │
│  Buscando proveedores…   │  │ ▣ Emp. │        │        │        │ │
│  ✓ 412 candidatos        │  └────────┴────────┴────────┴────────┘ │
│  ✓ 40 seleccionados      │  ── Selección (aún no guardada) ──────  │
│                          │  ▣ Empaques del Bajío · vendió a IMSS  │
│  ┌ Guardar 40 en        ┐│  ▣ Cartonera Jalisco · 3 adjudicac.    │
│  │ Prospección · 3 ya   ││  …                                      │
│  │ estaban   [Guardar]  ││                                         │
│  └──────────────────────┘│  ── Evidencia ▸ (cajón al tocar) ───── │
│  [ escribe… ] ○ Preguntar│                                         │
└──────────────────────────┴────────────────────────────────────────┘

• Izquierda, el chat. Mensajes, narración en vivo, tarjetas de un toque y de decisión inline, el selector de modo junto al composer.
• Derecha, el tablero. Antes de guardar: la selección como tarjetas argumentadas. Después: la Colección del CRM tal cual existe hoy (Board o Tabla), con las mismas etapas y el mismo cajón de registro. Luna mueve tarjetas y la persona lo ve moverse.
• Cajón de evidencia. Tocar una tarjeta abre el porqué: adjudicaciones, riesgos, historial. Nunca un salto de página.
• Móvil: apila; el tablero se vuelve una pestaña.

​

Qué no construimos nosotros [SUGERENCIA]

​

Decisiones que son del founder

• El nombre. ¿“Luna” es el modelo gestionado (recomendado) o el fallback? Hoy el código dice lo segundo.
• Guardar al CRM: un toque o directo. Este doc lo pone en nivel 1 porque toca el sistema de registro del equipo. Ponerlo en nivel 0 con deshacer es defendible si el equipo prefiere velocidad.
• Investigación larga: nivel 1 o nivel 2. Consume inferencia con tope, no créditos; se propone nivel 1.
• Qué conector de correo entra primero al broker (Gmail vs Outlook), para operar la bandeja propia de la persona — leer respuestas, enviar un correo suelto desde su cuenta. El envío de secuencias ya no depende de esto: funciona hoy vía Nylas.
• Ya decidido: el humano sigue en el loop; el modo automático con presupuesto existe solo en planes de pago; el plan gratis tiene muy poca capacidad; la persona ve el CRM al lado del chat; la UI se arma con frameworks prehechos, no desde cero; todo Brein se opera desde el chat; enviar secuencias se autoriza en el chat.