## Asset Header

- **Asset ID:** ARQ-XX-AI-SherpaOS-Canonical-v0.1
- **Version:** v00
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-Maestro
- **Tipo:** ARQ — Architecture
- **Propósito:** AI Sherpa OS — Documento Canónico v0.1
- **Última actualización:** 2026-04-11

---

# AI Sherpa OS — Documento Canónico v0.1
**EmpowerLabs / MasterPlaybooks**
Última actualización: 24 marzo 2026

---

## Introducción

Este documento no es solo un diseño técnico.

Es la base de una nueva forma de operar conocimiento dentro de EmpowerLabs y del ecosistema de MasterPlaybooks.

Hasta ahora, la mayoría de las implementaciones de IA funcionan como capas superficiales: generan texto, responden preguntas, automatizan tareas aisladas. Pero no construyen memoria real. No sostienen contexto a largo plazo. No generan continuidad operativa.

Y por eso no escalan como sistemas inteligentes.

Lo que estamos construyendo aquí es distinto.

Estamos diseñando el sistema nervioso del AI Sherpa — un sistema capaz de recordar, interpretar, evolucionar con el usuario, tomar decisiones basadas en evidencia, orquestar acciones y convertirse en una capa operativa real dentro del negocio.

**Actualización v0.1 (24 marzo 2026):** Este documento incorpora tres decisiones estratégicas nuevas:

1. **Mi Sherpa IA as a Service es la infraestructura de la Memory Layer del Sherpa.** No son proyectos paralelos — son el mismo sistema servido en dos contextos.
2. **El stack técnico se basa en el patrón OB1** (Supabase + pgvector + OpenRouter + MCP), validado como implementable por un solo equipo en días, no semanas.
3. **División de equipos clara:** Alex construye la infraestructura (Event Ledger + Memory Layer). Juan Carlos construye el puente MasterPlaybooks → CRM. El lanzamiento Tribus RRHH avanza en paralelo sin esperar a esta capa.

---

## Índice

1. Propósito
2. Principio fundamental
3. Cambio de paradigma
4. Arquitectura del AI Sherpa OS
5. Mi Sherpa IA as a Service — La infraestructura compartida
6. Specialization Packs
7. Assessment Layer (antes CEM)
8. Relación con MasterPlaybooks
9. Modelo de datos mínimo
10. Stack técnico validado
11. Flujo operativo
12. Roadmap de implementación
13. División de equipos — Sprint activo
14. Principios de diseño
15. Conclusión

---

## 1. Propósito

El AI Sherpa OS es el sistema operativo cognitivo que da vida a los MasterPlaybooks Inteligentes (MPI).

Su propósito es transformar contenido estático en experiencias dinámicas capaces de:

- Guiar a un usuario hacia un objetivo concreto
- Acompañar procesos de aprendizaje y transformación
- Generar artefactos accionables (planes, resúmenes, checklists)
- Detectar señales de progreso, bloqueo y oportunidad
- Activar recomendaciones contextuales
- Conectar la experiencia del usuario con el CRM y el equipo de ventas

El AI Sherpa OS no es un chatbot.
Es un sistema de guía, memoria, evaluación y orquestación.

---

## 2. Principio fundamental

El Sherpa no se define por su conocimiento.
Se define por su capacidad de:

- **Recordar** — persistir contexto entre sesiones
- **Interpretar** — extraer señales de las interacciones
- **Evaluar** — medir progreso y readiness
- **Decidir** — determinar el siguiente mejor paso
- **Actuar** — disparar acciones en sistemas externos

Esto implica que el core del sistema no es el prompt ni los documentos.
Es el **estado del usuario y su evolución en el tiempo.**

---

## 3. Cambio de paradigma

| Antes | Ahora |
|-------|-------|
| Prompt + Documentos + Chat | Estado + Memoria + Eventos + Orquestación |
| Sin memoria entre sesiones | Memoria persistente semántica |
| Respuestas genéricas | Respuestas contextuales basadas en historial |
| El usuario repite su contexto | El Sherpa lo recuerda |
| Conversaciones aisladas | Transformación trazable |

Este cambio permite: persistencia de contexto, evaluación acumulativa, decisiones coherentes y experiencias personalizadas a escala.

---

## 4. Arquitectura del AI Sherpa OS

### 4.1 Sherpa Core Runtime

El núcleo del sistema que gestiona:

- Identidad del usuario (user_id, perfil)
- Sesiones (inicio, fin, resumen)
- Memoria persistente (acceso al Memory Layer)
- Estado actual (derivado del Event Ledger)
- Contexto activo del MasterPlaybook en ejecución

### 4.2 Event Ledger

**Fuente de verdad operativa. Este es el paso 1.**

Registro append-only de todo lo que sucede entre el usuario y el Sherpa.

Cada evento contiene:
- `user_id` — identidad del usuario
- `session_id` — sesión de la interacción
- `event_type` — tipo de evento (ver catálogo)
- `event_category` — interaction / progress / artifact / signal / commercial
- `payload` — datos estructurados del evento (JSONB)
- `timestamp` — momento exacto
- `embedding` — vector semántico generado automáticamente (1536 dim)

Sin Event Ledger, el Sherpa no tiene qué recordar.
Con Event Ledger, cada interacción construye historia accionable.

### 4.3 Memory Layer

**Memoria persistente con recuperación semántica.**

Basada en el patrón OB1 (validado). Almacena:

- Resúmenes de sesión generados automáticamente
- Memorias episódicas extraídas de eventos clave
- Inferencias sobre el usuario (objetivos, bloqueos, patrones)
- Embeddings vectoriales para búsqueda semántica

La búsqueda semántica permite al Sherpa recuperar contexto relevante sin keyword matching — encuentra lo que importa aunque el usuario no lo mencione explícitamente.

**Nota estratégica:** Esta capa es la misma infraestructura que sirve a Mi Sherpa IA as a Service. No es trabajo duplicado — es infraestructura compartida.

### 4.4 State Engine

Consolida el estado del usuario a partir del Event Ledger:

- `active_goal` — objetivo declarado activo
- `current_stage` — etapa del MasterPlaybook
- `progress_score` — avance medible
- `engagement_level` — alto / medio / bajo
- `readiness_level` — listo para siguiente paso
- `risk_level` — señales de abandono o bloqueo
- `next_best_action` — acción recomendada

El estado se recalcula cada N eventos o al cerrar sesión.

### 4.5 Orchestration Engine (Maestro)

Determina qué hace el Sherpa en cada momento:

- Educar (continuar con el MasterPlaybook)
- Preguntar (recopilar información faltante)
- Recomendar (sugerir siguiente paso)
- Generar artefacto (plan, resumen, checklist)
- Activar capa especializada (Specialization Pack)
- Escalar (notificar al equipo humano)
- Disparar al CRM (señal comercial detectada)

### 4.6 Artifact Engine

Genera outputs accionables que quedan registrados como eventos:

- Planes de acción personalizados
- Resúmenes de sesión
- Frameworks aplicados al contexto del usuario
- Templates completados con datos reales

### 4.7 Integration Layer

Puente hacia sistemas externos:

- **CRM:** recibe señales de readiness y oportunidad comercial
- **WhatsApp/Telegram:** entrega notificaciones y seguimiento
- **MasterPlaybooks (plataforma):** registra progreso y dispara el Sherpa

---

## 5. Mi Sherpa IA as a Service — La infraestructura compartida

**Este es el insight estratégico central de v0.1.**

Mi Sherpa IA es un producto de memoria personal persistente — el "segundo cerebro" de un usuario construido sobre el mismo stack técnico que necesita el Sherpa OS.

La decisión es: **construir una sola infraestructura que sirve a ambos.**

| Dimensión | Mi Sherpa IA | AI Sherpa OS |
|-----------|-------------|--------------|
| Entidad que recuerda | El usuario individual | El usuario dentro de un MasterPlaybook |
| Tipo de memoria | Pensamientos personales, contexto de vida | Eventos de interacción, progreso, señales |
| Recuperación | Semántica (¿qué sé sobre X?) | Semántica + estructurada (¿dónde está el usuario?) |
| Output | Respuestas personalizadas | Guía, recomendaciones, artefactos |
| Monetización | Mi Sherpa IA as a Service (SaaS para clientes) | MasterPlaybooks Inteligentes |

**Stack compartido:**
- Supabase (PostgreSQL + pgvector + Edge Functions + Auth)
- OpenRouter (gateway multi-LLM: Claude, GPT, Gemini)
- MCP como capa de herramientas que el Sherpa consume
- Row Level Security para aislamiento por usuario

**Responsable:** Alex + equipo técnico de EmpowerLabs

**Ventaja de construir en Mi Sherpa IA primero:** laboratorio sin riesgo para el producto principal, con Victor como usuario de prueba perfecto. Todo lo aprendido se porta al Sherpa sin reescribir.

---

## 6. Specialization Packs

Módulos que se activan sobre el Sherpa Core según el dominio:

| Pack | Propósito | Sherpa Prioritario |
|------|-----------|--------------------|
| Coaching / Goal Achievement | Acompañamiento hacia objetivos | Sherpa RRHH |
| Learning / Mastery | Dominio progresivo de conocimiento | Todos |
| Team Progress | Seguimiento de equipos | Sherpa Team |
| Transformation Guidance | Cambios organizacionales complejos | Change Management Sherpa |
| Commercial Qualification | Detección de oportunidades de venta | Todos |

Cada pack define eventos relevantes, métricas propias, reglas de evaluación y outputs específicos. Se activan como capas opcionales, no reemplazan el core.

---

## 7. Assessment Layer (antes CEM)

**Reposicionamiento estratégico: CEM no es el core, es una especialización.**

La capa de evaluación avanzada (antes llamada CEM — Customer Engagement Model) se convierte en el **Assessment Specialization Pack**, una capa opcional que se activa cuando el Sherpa necesita scoring sofisticado.

Funciones:
- Evaluar estado de readiness del usuario
- Detectar señales de progreso o abandono
- Enrutar decisiones a flujos específicos
- Generar scoring para el equipo comercial

Tipos de assessment disponibles:
- Progress Assessment
- Transformation Assessment
- Team Assessment
- Commercial Qualification

---

## 8. Relación con MasterPlaybooks

```
MasterPlaybook = conocimiento estructurado (el qué)
Sherpa OS      = ejecución del conocimiento (el cómo)
```

El MasterPlaybook define los módulos, el contenido, la estructura del viaje.
El Sherpa interpreta ese contenido, guía al usuario, adapta la experiencia y activa acciones en función del estado real del usuario — no de un flujo predefinido genérico.

**Disparadores de MasterPlaybooks → Sherpa:**
- Usuario inicia un módulo → `module_started`
- Usuario completa una tarea → `task_completed`
- Usuario declara un objetivo → `user_goal_declared`
- Usuario hace una pregunta fuera del flujo → señal de contexto
- Usuario menciona precio o siguiente paso → señal comercial

**Puente MP → CRM (responsabilidad de Juan Carlos):**
Estos eventos del Sherpa deben conectarse al CRM para que el equipo de ventas y onboarding tenga visibilidad en tiempo real del estado del usuario.

---

## 9. Modelo de datos mínimo

### Entidades principales

**users**
- user_id, email, name, created_at
- profile (JSONB): objetivos, industria, rol

**sessions**
- session_id, user_id, sherpa_id, started_at, ended_at
- summary (texto generado al cerrar)

**events** ← El corazón del sistema
- event_id, user_id, session_id
- event_type, event_category
- payload (JSONB)
- embedding vector(1536) ← búsqueda semántica
- created_at

**state** (derivado del Event Ledger)
- user_id, active_goal, current_stage, progress_score
- engagement_level, readiness_level, risk_level
- next_best_action
- updated_at

**memories** ← Memory Layer
- memory_id, user_id
- content (texto autocontenido)
- embedding vector(1536)
- metadata (JSONB): people, topics, action_items, type
- created_at

**artifacts**
- artifact_id, user_id, session_id
- type (plan / summary / checklist / framework)
- content (JSONB)
- created_at

---

## 10. Stack técnico validado

Basado en el análisis del patrón OB1 (NateBJones-Projects/OB1):

| Componente | Tecnología | Propósito |
|------------|------------|-----------|
| Base de datos | Supabase (PostgreSQL) | Almacenamiento principal + Auth + RLS |
| Vector search | pgvector (extensión de Postgres) | Búsqueda semántica sin Pinecone/Weaviate |
| Edge functions | Supabase Edge Functions | Metadata extraction + embedding generation |
| LLM gateway | OpenRouter | Multi-modelo: Claude, GPT, Gemini desde una cuenta |
| Herramientas | MCP (Model Context Protocol) | Interfaz entre el Sherpa y el backend |
| Aislamiento | Row Level Security (RLS) | Un brain por usuario, acceso seguro |

**Ventajas del stack:**
- Supabase incluye todo en una sola plataforma (DB + auth + storage + realtime + edge functions)
- pgvector elimina la necesidad de una base vectorial separada en esta fase
- OpenRouter evita lock-in con un solo proveedor de LLM
- MCP permite que el Sherpa use las herramientas de memoria como funciones nativas

---

## 11. Flujo operativo

```
1. Usuario entra → session_start registrado
2. Declara objetivo → user_goal_declared + embedding generado
3. Sherpa consulta Memory Layer → contexto previo recuperado semánticamente
4. Sherpa genera plan → plan_generated registrado
5. Usuario completa módulo → module_completed
6. Sistema detecta progreso → engagement_increase_detected
7. State Engine actualiza estado → next_best_action definido
8. Orchestrator decide: continuar / escalar / disparar CRM
9. Al cerrar sesión → summary generado + memory actualizada
10. Ciclo continúa en siguiente sesión con contexto completo
```

---

## 12. Roadmap de implementación

### Fase 1 — Event Ledger v0.1 (Semana 1)
**Responsable: Alex**

- [ ] Proyecto Supabase creado
- [ ] Tabla `events` con schema completo (incluyendo embedding vector)
- [ ] Edge function: POST /events → persiste + genera embedding automáticamente
- [ ] Tabla `state` con recálculo básico
- [ ] GET /state/{user_id} funcional
- [ ] RLS configurado por user_id
- [ ] Catálogo de event_types inicial implementado

### Fase 2 — Memory Layer v0.1 (Semana 2)
**Responsable: Alex — basarse en patrón OB1**

- [ ] Tabla `memories` con embedding vector(1536)
- [ ] Edge function: metadata extraction al guardar memoria (personas, temas, action items)
- [ ] search_memories: búsqueda semántica (cosine similarity)
- [ ] list_recent_memories por user_id
- [ ] POST /session/end → genera summary + crea memoria episódica
- [ ] Herramientas MCP: capture_memory, search_memories, list_memories, memory_stats

### Fase 3 — Puente MasterPlaybooks → CRM (Semana 2-3)
**Responsable: Juan Carlos**

- [ ] Mapa de disparadores: qué eventos del MP generan qué acciones en CRM
- [ ] Webhook desde plataforma MasterPlaybooks → POST /events
- [ ] Integración con CRM: señales comerciales → notificación al equipo
- [ ] Dashboard mínimo: estado de usuarios activos en tiempo real

### Fase 4 — State Engine + Orchestration (Semana 3-4)
**Responsable: Alex**

- [ ] Reglas de next-best-action
- [ ] GET /recommendations/{user_id}
- [ ] Lógica de escalamiento (cuándo notificar al equipo humano)

### Fase 5 — Specialization Packs (Q2 2026)
- NOM-035 Sherpa Pack
- Recruitment Sherpa Pack
- Change Management Sherpa Pack

### Fase 6 — Mi Sherpa IA as a Service (Q2-Q3 2026)
- Misma infraestructura, interfaz para usuarios finales
- Multi-tenant con RLS
- Panel de administración para clientes

---

## 13. División de equipos — Sprint activo

| Persona | Responsabilidad | Entregable inmediato |
|---------|----------------|----------------------|
| **Alex** | Event Ledger + Memory Layer (stack OB1) | Supabase project + tabla events + POST /events funcional |
| **Juan Carlos** | Puente MasterPlaybooks → CRM | Mini-spec de disparadores + webhook inicial |
| **Todos** | Onboarding Tribus RRHH + plan de lanzamiento | Sherpa RRHH operativo para demo |

**Principio de coordinación:** Alex y Juan Carlos trabajan en paralelo. El lanzamiento de Tribus RRHH NO espera a que Event Ledger esté completo — ambas pistas avanzan simultáneamente.

---

## 14. Principios de diseño

- **Memoria primero** — sin persistencia, no hay sistema
- **Eventos antes que prompts** — registrar antes de responder
- **Estado antes que respuestas** — saber dónde está el usuario antes de hablar
- **Orquestación antes que automatización** — decidir con criterio, no solo ejecutar
- **Especialización sobre el core** — los packs no contaminan la base
- **Infraestructura compartida** — Mi Sherpa IA y el Sherpa comparten stack, no duplican trabajo
- **Implementar antes de perfeccionar** — Event Ledger v0.1 esta semana, perfeccionar en iteraciones

---

## 15. Conclusión

El AI Sherpa OS redefine el rol del contenido.

El valor no está en lo que el usuario lee.
Está en lo que el sistema logra que el usuario haga.

El Sherpa convierte conocimiento en acción.

Con el Event Ledger como base, la Memory Layer como cerebro, y Mi Sherpa IA como la misma infraestructura monetizada como servicio — EmpowerLabs no está adoptando IA como herramienta.

Está construyendo la capa de inteligencia que diferencia a MasterPlaybooks de cualquier competidor durante los próximos 3-5 años.

Ese es el verdadero motor del sistema.

---

*Documento generado: 24 marzo 2026 | Versión: v0.1 | Próxima revisión: al completar Fase 1*