--- type: PP asset_id: PP-XX-BMF-FuerzaLaboralAgentica-Arquitectura-v01 version: v01 status: Canonical · Ratificado por Victor (L3+) · 2026-06-20 owner: Victor Heredia sherpa_owner: Jay ratificador: Victor Heredia (L3+) fecha_creacion: 2026-06-20 fecha_ultima_actualizacion: 2026-06-20 intellbank: IB-XX-Maestro subbank: IPI-XX-IP-Infraestructura / IPI-XX-BMF-Engine tipo: PP — Position Paper / Propuesta de arquitectura proposito: Encuadrar la Fuerza Laboral Agéntica de EmpowerLabs — ontología unificada (skill/agente), Registro, Despachador, dos Factorías y membrana de exportación cliente/interno — dentro de BMF y MacroLoopX, con grounding en el estado del arte mundial 2026. disparador: Sesión 2026-06-20 con Victor — petición de trabajo quirúrgico de arquitectura para potenciar el ecosistema con un equipo de agentes / fuerza laboral agéntica + factorías de skills y de fuerza laboral. relacionados: - ARQ-XX-BMF-Architecture-v01 - ARQ-XX-BMF-MPB-Kernel-v01 - PP-XX-BMF-MetaLoopX-Arquitectura-v01 - PP-EL-LoopX-MacroLoopX-Arquitectura-v01 - DC-XX-FAC-SherpaX-LoopContract-v01 - PP-XX-SX-SherpaXComoPlataforma-BrainX-v01 - DC-XX-SX-ConceptoEmpowerTeamX-v01 - CP-EL-SX-SherpaXConcepto-v01 - CP-EL-SkillsRegistry-v01 - SOP-EL-SkillsAlta-v01 - PLAN-EL-UltraSherpaX-v01 - CP-MPX-SherpaIA-Concepto-v01 tags: [propuesta, arquitectura, fuerza-laboral-agentica, agentes, skills, factoria, registro, despachador, ontologia, bmf, macroloopx, gobernanza, sota-2026] --- # Fuerza Laboral Agéntica — arquitectura para elevar el ecosistema ## Propuesta de arquitectura · v01 · 2026-06-20 > **Tesis en una línea:** EmpowerLabs no necesita "un banco de skills". Necesita una **ontología componible**, un **registro**, un **despachador** y **dos factorías** que produzcan y orquesten una **Fuerza Laboral Agéntica** instanciada por cada loop y proceso crítico — gobernada por BMF y validada contra el estado del arte mundial de IA agéntica 2026. --- ## ✓ Estado de ratificación (2026-06-20) Ratificado por Victor (L3+) en sesión 2026-06-20. Decisiones tomadas: 1. **Ontología `Shell × Brain Code × Harness × Gobernanza`** — ratificada como canónica. Se formaliza en `CP-XX-BMF-OntologiaAgentica-v01`. 2. **Nomenclatura** — se adopta una distinción de dos niveles: - **SherpaTeamsX** = la **Fuerza Laboral Agéntica** (equipos de sherpas/agentes). - **EmpowerTeamsX** = los **equipos híbridos humano + sherpa** (los humanos dirigen SherpaTeamsX). EmpowerTeamsX *abraza* a SherpaTeamsX. - Refina y supera el `EmpowerTeamX` previo, que mezclaba humano+IA sin separar. 3. **Loop piloto (F3)** — **LoopXDG · Demand Gen** (no LoopXSA): es donde hay volumen/repetición para evals, donde lo agéntico paga sus tokens, donde la autonomía puede ser real, y destraba el cuello de pocos prospectos que hace mal piloto a ventas. Titan×Hormozi se conserva como prueba F0; el piloto de SherpaTeamsX corre en DG. *(Victor afina la decisión final el fin de semana.)* 4. **Factoría de Fuerza Laboral** — **interno primero, gradúa a producto** vía la membrana de exportación. --- ## 0. Resumen ejecutivo (90 segundos) Victor planteó cinco cosas que parecen separadas y en realidad son una sola arquitectura: 1. Un **banco de skills curado**, separado en lo que se entrega a clientes (instalable) y lo que es interno (no compartible), con agentes que a veces se adaptan por cliente. 2. Una **fuerza laboral agéntica** (no "banco" — un equipo de agentes), encuadrada en el ecosistema y en LoopX. 3. **Sherpas especializados** por loop y por proceso crítico, potenciados con uno o varios **Brain Codes**. 4. Un **asesor/skill** que, ante un problema, sugiere el agente + Brain Code correcto. 5. Una **factoría de skills** y una **factoría de fuerza laboral agéntica**. Este documento demuestra que las cinco se resuelven con **un solo sistema de seis órganos**: **Ontología → Registro → Despachador → 2 Factorías → Membrana de exportación → Memoria compartida.** Lo encuadra dentro de la arquitectura existente (BMF · QUÉ·CÓMO·QUIÉN · MacroLoopX · Loop Contracts · SVA/UltraSherpaX), cierra las brechas que el propio vault ya declara abiertas, y lo eleva con los patrones que ganaron en el mundo en 2026 (supervisor jerárquico, MCP + Agent Skills + A2A, tool-search/composición en runtime, gobernanza por niveles de autonomía, eval-gating, memoria con permisos). **El reencuadre central:** *Un agente especializado no es un "skill con nombre" ni un agente desde cero. Es una **composición** sobre una sola columna: Shell × Brain Code × Harness × Gobernanza. Quitas el harness y es un skill; lo pones y es un agente. El producto estrella no es ningún agente individual — es **el sistema que los receta, los produce y los gradúa**.* --- ## 1. Punto de partida — lo que ya existe (Gate G0) Antes de proponer, se reconoce lo que el vault ya tiene. **No inventamos sobre vacío; cerramos un sistema medio construido.** | Pieza existente | Qué aporta | Estado en el vault | |---|---|---| | **BMF · QUÉ·CÓMO·QUIÉN** (`ARQ-XX-BMF-Architecture-v01`) | El modelo de 3 partes de Victor, ya canonizado: Infraestructura (QUÉ) · Método (CÓMO) · Interfaz (QUIÉN). El **QUIÉN tiene dos mitades: SherpaX (operativo) + Brain Code (cognitivo)** — "el actor y su mente no compiten, se componen". | Canónico | | **BMF Kernel L0–L4** (`ARQ-XX-BMF-MPB-Kernel-v01`) | L0 Kernel/constitución · L1 Factory Builder · L2 MetaFactories · L3 Instancias · L4 Producción. Invariante: *un gate debe poder dar FAIL*. | Draft | | **MacroLoopX** (`PP-EL-LoopX-MacroLoopX-Arquitectura-v01`) | El proceso de innovación como **5 loops encadenados**: PR (productización) → DG (demand gen) → SA (ventas) → OP (operación) → KZ (kaizen, transversal). Cada loop tiene equipo, tablero, métricas y **agentes humanos + IA**. | **Ratificado** | | **MetaLoopX** (`PP-XX-BMF-MetaLoopX-Arquitectura-v01`) | El loop que orbita **factorías**, no productos. La "fábrica de fábricas". | Draft | | **Loop Contract** (`DC-XX-FAC-SherpaX-LoopContract-v01`) | El arnés de 10 elementos que instancia cualquier loop/factoría. *"Sin contrato, no hay loop."* Incluye el equipo: tripleta humana + **agentes IA con nivel de autonomía**. | Activo / piloto | | **SherpaX como plataforma + BrainX** (`PP-XX-SX-SherpaXComoPlataforma-BrainX-v01`) | SherpaX = host/kernel; **BrainX = motor de especialización enchufable**; BrainCode = la mente. BrainX + BrainCode = matriz **N×M** (roles × cogniciones). Dominios canónicos: SX, MX, PX, TX. | Canónico | | **SVA / UltraSherpaX** (`PLAN-EL-UltraSherpaX-v01`) | Ya es "el Sherpa especializado potenciado por Brain Codes": **SVA = SherpaX + Brain Code(s) + Skill(s) + Gobernanza**, producido por un **generador**. Prototipo **F0 validado: Titan × Hormozi**. 33 Brain Codes instanciados. | F0–F2 ✅, F3 en curso | | **EmpowerTeamX** (`DC-XX-SX-ConceptoEmpowerTeamX-v01`) | La fuerza laboral híbrida IA+humano, jerarquía de 4 niveles (CEO → MetaPlaybook → Managers → especialistas de estación). Instancia ETX-1 con 5 agentes. | Draft | | **Skills Registry + Alta** (`CP-EL-SkillsRegistry-v01`, `SOP-EL-SkillsAlta-v01`) | Registro con Bloque A (propias, gobernables) y Bloque B (terceros, los 70 AI Specialists). Alta de 7 pasos. Marketplace privado con 3 plugins. | Draft | | **Gobernanza WORX** | Tripleta (Owner+Sherpa+Ratificador) · Gate G0 Vault-First · autonomía L0–L3 por valor×complejidad · naming BMF · CAL guards · MEL (capa de enforcement, *pendiente de implementación*). | Vigente | **Conclusión del Gate G0:** el 80% de las piezas existen. Lo que falta no son conceptos nuevos — es **unificarlos en una sola ontología y darles tres órganos que el vault aún no tiene: un Registro Agéntico, un Despachador y la formalización de las dos Factorías.** --- ## 2. Las brechas que el propio vault declara abiertas El análisis del ecosistema encontró cinco tensiones reales (no inventadas — están escritas en los docs): 1. **Modelo de fuerza laboral fragmentado.** Hay *cuatro* mentales distintas sin reconciliar: EmpowerTeamX (jerarquía manager/worker), motores BrainX (enchufables al host), SVAs (skill×BrainCode), y "Layer 5: AI Agents as Workforce" de HIOrg. **No hay un modelo canónico único de la fuerza laboral agéntica.** → *Esta propuesta lo unifica.* 2. **Distinción skill / agente / motor difusa.** Se usan de forma intercambiable. → *Esta propuesta da una ontología componible.* 3. **No hay despacho/routing canónico.** Nadie decide "qué agente para qué problema" de forma sistemática. → *El Despachador.* 4. **No hay registro de agentes distinto del de skills.** Los SVA viven dentro del SkillsRegistry; no hay registro de *instancias desplegadas* con ciclo de vida ni telemetría. → *El Registro Agéntico.* 5. **La "factoría de agentes" se afirma pero está inmadura.** `factory-spawner.skill` existe pero sin proceso formal; FI-SHA (la factoría de SherpaX) corre en modo **Héroe-Operador**: depende de Victor. → *Las dos Factorías + matar la dependencia del héroe.* > **La brecha #5 es la más importante.** Una fuerza laboral agéntica cuya fábrica depende de una sola persona no es una fuerza laboral — es Victor con más pestañas abiertas. **El primer entregable real de esta arquitectura es independizar la fábrica del héroe.** --- ## 3. Cuatro reencuadres del problema (las "alteraciones") Victor pidió al menos tres replanteamientos para destrabar una propuesta poderosa. Aquí van cuatro — cada uno mueve la solución a otro nivel. ### Reencuadre 1 — De "banco de skills" a "fábrica + registro + despachador" Un **banco** es un sustantivo estático: una repisa de capacidades que envejece. El activo real no es la repisa — es **el sistema vivo que produce, cataloga, recomienda y mejora** las capacidades. El estado del arte 2026 (AgentFactory, SkillFoundry, "factory + registry loop") confirma: *lo durable no es la colección, es el bucle fábrica→registro→eval→mejora.* Tu MetaLoopX ya es ese bucle a nivel de factorías; aquí lo aplicamos a nivel de agentes/skills. **Consecuencia:** dejamos de "curar un banco" y empezamos a **operar una fábrica con un catálogo que se ordena solo**. ### Reencuadre 2 — De "¿skill o agente?" a "una sola columna componible" La pregunta de Victor — *"¿son agentes o skills con nombre?"* — tiene una respuesta arquitectónica exacta, respaldada por el campo: **"un skill es una capacidad que el modelo *carga*; un agente es un loop que el modelo *corre*"**. No son dos categorías rivales: son **la misma columna con o sin harness**: ``` AGENTE/SKILL ESPECIALIZADO = Shell × Brain Code(s) × Harness × Gobernanza (¿qué?) (¿con qué (¿loop (tripleta + capacidad criterio/mente?) autónomo?) autonomía + pasiva) evals) • Sin Harness → es un SKILL (capacidad pasiva que el SherpaX invoca) • Con Harness → es un AGENTE (percibe → planea → actúa → observa, en bucle) ``` Esto **ya es tu fórmula SVA**, extendida con dos columnas que faltaban (Harness explícito + Gobernanza con autonomía/evals). Resuelve la confusión de raíz: *no debatimos si algo es skill o agente — declaramos sus cuatro columnas.* **Consecuencia:** una taxonomía limpia donde un Brain Code potencia a cualquier shell, y el mismo activo puede desplegarse pasivo (skill) o autónomo (agente) según el Loop Contract lo permita. ### Reencuadre 3 — De "población de agentes" a "capacidad instanciada por loop bajo contrato" La intuición de Victor es correcta y el campo la respalda: **no se pre-crea un organigrama de agentes que esperan trabajo.** Se **instancian** agentes especializados *por loop y por proceso crítico*, bajo su Loop Contract, y se disuelven. Esto honra tu invariante — *"los loops orquestan, las factorías producen — nunca soldar"* — y la economía de tokens del mundo real (multi-agente cuesta 3–15× tokens; se justifica solo donde el valor lo paga). **Consecuencia:** la Fuerza Laboral Agéntica **vive dentro de MacroLoopX**, no al lado. Cada loop (PR/DG/SA/OP/KZ) tiene su roster instanciado bajo contrato. La fábrica no puebla un zoológico — surte capacidad just-in-time. ### Reencuadre 4 — De "¿qué agente uso?" a "un médico que receta composiciones" El "asesor" que pidió Victor no es un agente más: es un **meta-producto diagnóstico**. Ante un problema, **diagnostica y receta**: *este shell × este(os) Brain Code(s) × este nivel de autonomía* — y si la cognición necesaria no existe, **receta crear un Brain Code nuevo**. El campo lo llama routing de dos etapas en espacio vectorial compartido (Tool-to-Agent Retrieval): se embeben shells *y* Brain Codes con descripciones ricas, se recuperan los mejores, se propone el par. **Consecuencia:** el **Despachador/Consejero** se vuelve la cara del ecosistema y, potencialmente, **un producto vendible por sí mismo** ("el que sabe qué inteligencia aplicar a tu problema"). --- ## 4. La arquitectura propuesta — un sistema de seis órganos Todo se encuadra dentro de BMF, sobre el eje QUÉ·CÓMO·QUIÉN existente: ``` ╔══════════════════════════════════════════════════════════════════════╗ ║ BMF — Big Meta Factory · L0 Kernel (gobernanza constitucional) ║ ╠══════════════════════════════════════════════════════════════════════╣ ║ CÓMO · MÉTODO WORX / MetaPlaybooks · Loop Contracts ║ ║ MacroLoopX: PR → DG → SA → OP → KZ · MetaLoopX ║ ╠══════════════════════════════════════════════════════════════════════╣ ║ QUIÉN · INTERFAZ SherpaX (host) ⊕ Brain Codes (mente) ║ ║ ║ ║ ┌─────────── SHERPATEAMSX · Fuerza Laboral Agéntica ──────────┐ ║ ║ │ │ ║ ║ │ ② DESPACHADOR/CONSEJERO ④ DOS FACTORÍAS │ ║ ║ │ (diagnostica y receta) (Skills + Fuerza Laboral) │ ║ ║ │ │ │ │ ║ ║ │ └────────► ① REGISTRO ◄───────┘ │ ║ ║ │ (ontología componible: │ ║ ║ │ AgentCards × Brain Codes × autonomía) │ ║ ║ │ │ │ ║ ║ │ ⑤ MEMBRANA DE EXPORTACIÓN │ ║ ║ │ (interno / instalable / adaptable-cliente) │ ║ ║ └──────────────────────────────────────────────────────────────┘ ║ ╠══════════════════════════════════════════════════════════════════════╣ ║ QUÉ · INFRAESTRUCTURA IntelliBanks · CorpBrainOS · SOMA ║ ║ ⑥ Memoria compartida con permisos (role-scoped)║ ╚══════════════════════════════════════════════════════════════════════╝ ``` ### ① El Registro Agéntico — la ontología que el vault no tiene Un registro **distinto** del SkillsRegistry, machine-readable, estilo **A2A AgentCard + AgentSkill**. Cada entrada es un objeto tipado y versionado: - **Shell** → ficha tipo AgentCard: `id`, `descripción` (escrita *para un recuperador*, con frases-gatillo, sinónimos y alcance negativo "NO usar para…"), `tags`, `examples`, `input/output modes`. - **Brain Code** → manifiesto de cognición: dominio, lentes, territorio, guardas CAL, confianza, confidencialidad. - **Composición desplegada (Sherpa Especializado)** → entrada propia con: par(es) shell×BrainCode, **Harness** (¿loop? ¿qué tools/MCP?), **nivel de autonomía** (L0–L3), **permiso/scope**, **estado de eval**, tripleta, versión, telemetría. Esto es la "odontología/ontología" que pidió Victor: el mapa machine-readable que permite **auto-sugerir** la composición correcta. *Tú dueño de tu taxonomía — el campo confirma que la ontología cross-org sigue sin resolverse; no esperamos un estándar externo.* ### ② El Despachador / Consejero — el médico que receta El "asesor" de Victor, hecho meta-producto. Pipeline (del estado del arte de routing 2026): 1. **Front-door barato:** clasificador ligero para casos obvios (sin gastar una llamada cara). 2. **Routing semántico de dos etapas** sobre el Registro (Tool-to-Agent): recupera shells *y* Brain Codes candidatos para el problema. 3. **Refinamiento iterativo** (estilo MCP-Zero) para problemas ambiguos: pide más capacidad conforme entiende. 4. **Receta:** propone `Shell × Brain Code(s) × autonomía` + Loop Contract aplicable; si falta cognición, **receta producir un Brain Code** y deriva a la factoría. 5. **Carga diferida (tool-search):** las fichas completas se cargan solo al confirmar — controla el "context bloat" (un catálogo grande quema 50K+ tokens si se carga entero). Implementación inicial: **un skill `/consejero`** (o `/despacha`) que vive en el marketplace y consulta el Registro. Evoluciona a agente con memoria. ### ③ Sherpas Especializados — la unidad de trabajo Cada uno es una composición del Reencuadre 2, instanciada por un loop/proceso. Ejemplos por dominio canónico: - **LoopXSA (ventas):** Sherpa-Oferta = `titan-business-offer × BC-Hormozi` (ya validado F0) · Sherpa-Objeciones · Sherpa-Diagnóstico-Prospecto. - **LoopXDG (demanda):** Sherpa-LinkedIn = `linx-linkedin × BC-ChrisWalker` · Sherpa-Contenido = `cara-repurposing × BC-MattGray`. - **LoopXPR (productización):** Sherpa-Productizador · Sherpa-Naming. - **LoopXOP (operación):** los skills de gobernanza del vault (vault-orphan-rescue, registry-updater) como agentes de mantenimiento. - **LoopXKZ (kaizen):** Sherpa-Evaluador que corre las baterías QA y realimenta el Registro. ### ④ Las dos Factorías — donde se produce, no se improvisa Ambas a **nivel L1/L2 del BMF Kernel** (Factory Builder / MetaFactory). No se arman a mano. - **Factoría de Skills** (productiza `SOP-EL-SkillsAlta` + `skill-creator`): spec → genera shell → **eval-gate** → registra → publica al marketplace. Output: *capacidades (shells)*. - **Factoría de Fuerza Laboral Agéntica** (extiende el `ultrasherpax-generator`): toma shell + Brain Code(s) + define Harness + autonomía → compone el Sherpa Especializado → **eval-gate** → registra → despliega bajo Loop Contract. Output: *agentes desplegables*. Es un **meta-agente** que construye agentes (patrón AgentFactory 2026), con auto-mejora segura (los agentes reescriben sus propias descripciones/prompts — el escalón production-safe; la auto-modificación total queda como I+D sandboxed). ### ⑤ La Membrana de Exportación — resuelve interno vs cliente No son dos bancos. Es **una fábrica con un gate de graduación** (espejo del estado "Replicable/Graduada" de MetaLoopX y del banco transferible `IB-CO-Consultoría`). Tres salidas: | Salida | Qué es | Dónde vive | |---|---|---| | **Interno** | Cognición core, no compartible (Brain Codes propios, skills de gobernanza del vault) | `IB-XX-Maestro` (nunca sale) · `IB-EL` | | **Instalable** | Pack cliente: `SKILL.md` + tools MCP + set de evals + (Brain Code o *slot* de Brain Code) — firmado y con procedencia (*los skills son cadena de suministro*) | Marketplace cliente · `IB-CO-Consultoría` | | **Adaptable-cliente** | Shell genérico instalable + **slot** para el Brain Code del cliente (su propia cognición destilada) — el agente se "viste" con la mente del cliente | Pack + onboarding | > Esto contesta literal a Victor: *los agentes que entregamos a clientes "quizás deberán ser adaptados"* → sí: se entregan con **slot de cognición** que se rellena con un Brain Code del cliente. El shell viaja; la mente se calibra. ### ⑥ Memoria compartida con permisos — el flywheel Una **memoria compartida role-scoped** (no un blackboard libre — el campo 2026 muestra que el global sin permisos genera basura y contención). Cuando un Sherpa Especializado produce un activo validado (una oferta, un ANA, un caso LabPraxis), se escribe de vuelta como **memoria tipada y consultable** (embeddings + control de acceso). Así: routing → composición → ejecución → **memoria** → mejor routing futuro. Tu IdeaBank/LabPraxis/Registry ya son la versión manual; el upgrade es hacerlos machine-queryable. --- ## 5. Dónde encaja en MacroLoopX (la respuesta a "dónde va la fuerza laboral") La Fuerza Laboral Agéntica **no es una capa nueva — es el equipo IA de cada loop**, surtido por las factorías y despachado por el Consejero: ``` LoopXPR ──► LoopXDG ──► LoopXSA ──► LoopXOP ──┐ (ideación) (demanda) (ventas) (entrega) │ ▲ │ └──────────── LoopXKZ (kaizen) ◄──────────┘ │ evalúa agentes, realimenta el Registro ▼ REGISTRO ◄── FACTORÍAS ◄── DESPACHADOR (receta por proceso) ``` Cada loop, en su **Loop Contract**, declara su roster de agentes IA con su **nivel de autonomía** (la matriz L0–L3 que ya tienes, mapeada al estándar 2026 **HITL / HOTL / asistido**). El **LoopXKZ** corre las evals y realimenta — convirtiendo todo el sistema en un **bucle auto-mejorante** (el patrón fábrica+registro+eval). A nivel superior, **MetaLoopX** replica factorías de agentes hacia clientes. --- ## 6. Gobernanza — fuerza laboral responsable (lo que separa lo serio de lo amateur) El estado del arte 2026 es claro: *la confiabilidad y la gobernanza son el foso, no la topología novedosa.* Se hereda y extiende lo que ya tienes: - **Tripleta en cada agente:** Owner + Sherpa + Ratificador. Ningún Advisory IA tiene voto decisorio — *BrainX recomienda, la tripleta decide.* - **Niveles de autonomía como superficie de control:** L0–L3 ↔ **HITL** (humano aprueba antes; pricing, GO/NO-GO, cierre) / **HOTL** (humano monitorea, reversible) / **asistido→promovido** (sube de autonomía *solo* cuando las evals muestran precisión estable). Promoción por **gates de desempeño auditables**. - **Identidad por agente:** cada agente desplegado con identidad verificable y scope de permisos (dirección 2026: SPIFFE + OAuth scoping). Sin identidad, los checkpoints HITL no tienen enforcement. - **Eval-gate antes del catálogo:** cada skill y cada Brain Code pasa una suite (capability + regression, LLM-as-judge para outputs blandos) **antes** de entrar al Registro. Suite de regresión por par shell×BrainCode, sembrada de problemas reales que el Consejero ruteó. *Un gate que solo puede dar PASS es teatro.* - **CAL guards heredadas:** percepción ≠ valor real; validación de frontera de dominio; nunca inventar datos/resultados. - **MEL** se vuelve la capa de enforcement runtime que hoy está pendiente: las reglas se vuelven física estructural. - **Seguridad nueva a vigilar (2026):** la memoria persistente es superficie de ataque (memory poisoning) → procedencia/validación de memoria; los skills son cadena de suministro → firma y revisión. --- ## 7. Principios de diseño no-negociables (destilados del mundo) 1. **Supervisor jerárquico sobre backbone durable** (grafo con checkpoints). Reservar swarm/blackboard solo para trabajo masivamente paralelo. 2. **No inventar substrato:** estandarizar en **MCP (tools) + Agent Skills (cognición empaquetada) + A2A (entre-agentes)** — los tres estándares de facto 2026. 3. **Default single-agent; multi-agente solo con evidencia.** ~79% de las fallas multi-agente vienen de mala especificación y handoffs rotos. Multi-agente cuesta 3–15× tokens — se usa donde el valor lo paga. 4. **Especificación disciplinada:** cada agente recibe objetivo + formato de salida + guía de tools + fronteras. 5. **Artefactos en filesystem + referencias ligeras** (evitar el "teléfono descompuesto" entre agentes). 6. **Carga diferida de capacidades** (tool-search) para no quemar el presupuesto de contexto. 7. **Eval-first y trazabilidad de producción.** La confiabilidad es el producto. --- ## 8. Hoja de ruta (serie F — convención del ecosistema) | Fase | Entregable | Mata qué brecha | |---|---|---| | **F0** | Ratificar esta propuesta + **canonizar la ontología** (Shell×BrainCode×Harness×Gobernanza) | #2 distinción difusa | | **F1** | **Registro Agéntico v1**: AgentCards de los shells existentes + 33 Brain Codes + el SVA Titan. **Despachador v1** (`/consejero`, routing semántico). Interno. | #3 routing, #4 registro | | **F2** | Formalizar **las dos Factorías** (productizar generadores + eval-gate + alta automatizada) | #5 factoría inmadura | | **F3** | Desplegar el **roster de un solo loop (LoopXDG · Demand Gen)** bajo Loop Contract con operación **no-Victor** → **matar la dependencia Héroe-Operador (FI-SHA)** | #1 + #5 (la crítica) | | **F4** | **Membrana de exportación**: primer pack cliente instalable + adaptable (slot de Brain Code) | separación cliente/interno | | **F5** | **Bucle auto-mejorante**: LoopXKZ realimenta evals al Registro; escalar a los 5 loops + replicación vía MetaLoopX | escala + foso de confiabilidad | **Regla de secuencia:** F3 es el corazón. *Hasta que un agente especializado opere un proceso crítico sin Victor, no tenemos fuerza laboral — tenemos demos.* Todo F1–F2 existe para habilitar ese momento. --- ## 9. Qué eleva esto a "top of the world" 1. **Unifica cuatro modelos rivales** (EmpowerTeamX ⊕ BrainX ⊕ SVA ⊕ HIOrg-L5) en una sola ontología componible — algo que ni los frameworks líderes han logrado para *su propio* stack interno. 2. **Convierte la cognición destilada (Brain Codes) en ventaja propietaria** sobre shells genéricos commodity. El mundo tiene shells; casi nadie tiene una fábrica de mentes expertas calibradas + gobernanza. 3. **El Despachador como meta-producto diagnóstico** — "el que sabe qué inteligencia aplicar a tu problema" — es un posicionamiento que casi nadie ocupa. 4. **La membrana de exportación** vuelve cada activo interno un producto cliente sin duplicar trabajo — fractalmente, vía MetaLoopX. 5. **Gobernanza como física estructural (MEL)** + eval-gating + autonomía graduada — exactamente donde el mundo 2026 dice que está el foso. > EmpowerLabs no estaría "usando agentes". Estaría operando **la fábrica, el catálogo, el médico y la membrana** de una fuerza laboral agéntica gobernada — el sistema que el resto del mundo apenas está empezando a nombrar. --- ## 10. Decisiones de Victor (L3+) — RATIFICADAS 2026-06-20 1. **Ontología `Shell × Brain Code × Harness × Gobernanza`** — ✅ **ratificada** como canónica. Se formaliza en `CP-XX-BMF-OntologiaAgentica-v01`. 2. **Nombre de la fuerza laboral** — ✅ **SherpaTeamsX** (fuerza laboral agéntica) + **EmpowerTeamsX** (equipos híbridos humano+sherpa). EmpowerTeamsX abraza a SherpaTeamsX. Supera el `EmpowerTeamX` previo. 3. **Loop piloto para F3** — ✅ **LoopXDG · Demand Gen** (volumen para evals, autonomía real, destraba el cuello de prospectos). Titan se conserva como prueba F0. *(Victor afina la decisión final el fin de semana.)* 4. **Alcance de exportación** — ✅ **interno primero, gradúa a producto** vía la membrana de exportación. --- ## Conexiones - [[BigMetaFactory]] · [[WORX]] · [[DOIX]] · [[HIOrgs]] - [[SherpaX]] · [[BrainCodes]] · [[Arquetipos-SherpaX]] - [[BrainX-Loop]] · [[XDoc-Sistema]] · [[Skills-Home]] - [[CP-MPX-SherpaIA-Concepto-v01]] — la otra superficie que estas factorías alimentan --- **Ficha** · Tipo: PP — Position Paper · Entidad: XX · v01 · Creado 2026-06-20 · Owner: Victor Heredia · Sherpa: Jay · Ratificador: Victor Heredia (L3+) · Estado: Draft · Propuesta · Pendiente ratificación **Fuentes internas (vault):** `ARQ-XX-BMF-Architecture-v01` · `ARQ-XX-BMF-MPB-Kernel-v01` · `PP-EL-LoopX-MacroLoopX-Arquitectura-v01` · `PP-XX-BMF-MetaLoopX-Arquitectura-v01` · `DC-XX-FAC-SherpaX-LoopContract-v01` · `PP-XX-SX-SherpaXComoPlataforma-BrainX-v01` · `DC-XX-SX-ConceptoEmpowerTeamX-v01` · `CP-EL-SX-SherpaXConcepto-v01` · `PLAN-EL-UltraSherpaX-v01` · `CP-EL-SkillsRegistry-v01` · `SOP-EL-SkillsAlta-v01` **Fuentes externas (estado del arte 2026):** Anthropic — multi-agent research system & Agent Skills · A2A Protocol v1.0 (AgentCard/AgentSkill, Linux Foundation) · MCP + registries + tool-search/deferred loading · Tool-to-Agent Retrieval (2511.01854), MCP-Zero (2506.01056) · PersonaAgent (2506.06254), Knowledge Activation (2603.14805), SkillFoundry · AgentFactory (2603.18000) · gobernanza HITL/HOTL + SPIFFE/OAuth + NIST AI Agent Standards (feb-2026) · eval (τ²-Bench, MCP-Bench, LLM-as-judge) · memoria con permisos (Mem0/Zep/Letta) · MAST failure taxonomy (Redis) · Salesforce Agentforce / Sierra / Factory.ai / Cognition. **Tags:** #propuesta #fuerza-laboral-agentica #arquitectura #bmf #macroloopx #ontologia #despachador #factoria #gobernanza