--- título: Trilogía del Mundo Agentivo — Manifiesto unificado para agentes composición: La Empresa en Tiempo Real v0.4 · AURA v0.3 · AgencyDomains v0.7 (los tres manifiestos canónicos, íntegros) licencia: GFDL v1.3 (propuesta) audiencia: agentes que necesitan la trilogía completa en un solo documento regla_de_precedencia: cada parte es espejo de su libro humano; ante contradicción, gana el libro humano de la parte correspondiente --- # Trilogía del Mundo Agentivo — Manifiesto unificado para agentes > Este documento **ensambla, íntegros y sin editar**, los tres manifiestos canónicos para agentes de la Trilogía del Mundo Agentivo. Se genera automáticamente desde los manifiestos por libro — que son la fuente de verdad de cada parte y se versionan con su libro. Úsalo cuando necesites razonar sobre la trilogía completa; usa el manifiesto individual cuando trabajes dentro de un solo volumen. ## El tránsito (el marco que comparten las tres partes) El tránsito que ocupa a la trilogía es uno solo: del mundo donde las personas abren aplicaciones para trabajar, al mundo donde los agentes de IA son la interfaz del trabajo. La frontera es **la Línea Nadella** — *¿el humano abre aplicaciones para hacer su trabajo?*, en su formulación canónica; cada volumen la conjuga a su audiencia — y los tres volúmenes responden, en orden, las tres preguntas de ese tránsito: | Vol | Libro | Pregunta | Rol | Audiencia | |---|---|---|---|---| | I | **La Empresa en Tiempo Real** — Mundo Agentivo | ¿Hacia dónde vamos? | el destino | Gerentes, directores y dueños de negocio, sin background técnico | | II | **AURA** — Camino Agentivo | ¿Por dónde? | la ruta | Consultores y arquitectos de la transformación | | III | **AgencyDomains** — Arquitectura Agentiva | ¿Cómo llegamos? | el vehículo | Arquitectos e ingenieros que construyen o adoptan | **Vergis** (no es un libro: es código) es la implementación de referencia, en . La trilogía completa vive en . ## Canon compartido (idéntico en las tres partes, salvo conjugación declarada; el libro dueño desarrolla) | Término | Definición de una línea | Libro dueño | |---|---|---| | **Línea Nadella** | La pregunta divisoria, en su formulación canónica: ¿el humano abre aplicaciones para hacer su trabajo? Sí → mundo agéntico; no → mundo agentivo. Conjugaciones oficiales por audiencia: «¿todavía abres aplicaciones para hacer tu trabajo?» (La Empresa en Tiempo Real, segunda persona) · «¿sus empleados todavía abren aplicaciones para hacer su trabajo?» (AURA, voz del directivo) — las tres equivalentes | AgencyDomains (Cap 1); La Empresa en Tiempo Real la presenta a nivel de visión | | **agentivo / agéntico** | Agentivo = los agentes son la interfaz (transformación); agéntico = copilotos dentro de aplicaciones (evolución incremental). "Agéntico" nunca se usa en sentido positivo-tecnológico | AgencyDomains (Cap 1) · AURA (Introducción) | | **Mundo Agentivo** (mayúsculas) | El paradigma como nombre propio; en minúsculas, adjetivo | AgencyDomains (convención tipográfica, Cap 1) | | **empresa en línea / empresa en tiempo real** | La que accede a información al día pero depende de humanos para actuar / la que detecta, interpreta, decide y actúa de forma continua y gobernada | AURA (Introducción e IRIS) · AgencyDomains (Cap 2) | | **ciclo de inteligencia continua** | Percibir → Interpretar → Decidir → Actuar → Aprender — formulación canónica única en toda la trilogía | AURA (Introducción) | | **Salto Cuántico** | El colapso del costo de la pregunta analítica (de semanas a segundos); frontera entre empresa en línea y en tiempo real | AURA (Introducción; operacional como salto 4→5 de IRIS) · AgencyDomains (Cap 2) | | **porcentaje agentivo** | Indicador de cruce: fracción de tareas delegables por completo a un agente sin abrir una aplicación (0-20 agéntico · 20-50 aproximación · 50-80 cruce · 80-100 agentivo; se mide por función) | AURA (Introducción) | | **Trust Infrastructure** | Los cinco pilares (Gobernanza · Auditoría · Validación · Resiliencia · Transparencia) que separan pilotos de producción | AgencyDomains (Cap 5 §4 y Cap 8); MOTOR la usa como umbral de madurez 1→2 | | **coexistencia evolutiva / subsunción** | Cada etapa subsume a la anterior; el data warehouse no muere — se vuelve fuente que los agentes consumen | AURA · AgencyDomains (Cap 2) | | **las tres liberaciones** | De las herramientas (flujo), de los canales (atención), de la disponibilidad (tiempo); el orden no se salta | La Empresa en Tiempo Real | | **primitivas del canon** (ocho) | AgencyDomain · Botlet · proto-Botlet · Agentlet · Capability · Trust Infrastructure · Asistente vs Agente Autónomo · Faceta | AgencyDomains (Caps 4–5) | **Mapa de propiedad conceptual:** La Empresa en Tiempo Real es dueño del retrato del destino (las cuatro caras — El salto cuántico, Postchat, El Estado Mayor, La guardia —, la persona como infraestructura, el presupuesto de atención, los M&Ms y el &, el modo agentivo, los siete mecanismos, la representación, la organización inteligente). AURA es dueño de la medición y la ruta (IRIS, MOTOR, Data Canon, Wingmap, casos de uso, porcentaje agentivo). AgencyDomains es dueño de la arquitectura (las cuatro capas, las ocho primitivas, CRUDLEX, el mercado, Vergis). Ante duda sobre un término compartido, la definición operativa vive en el libro dueño. ## Cómo leer este documento Las tres partes que siguen son los manifiestos canónicos **completos y verbatim** de cada libro, en el orden de la trilogía. Cada parte conserva su propio frontmatter, su versión y su regla de precedencia («el libro humano gana»). Los separadores `═══` marcan el cambio de volumen. ═══════════════════════════════════════════════════════════════════ ═══════════════════════════════════════════════════════════════════ ## PARTE I · LA EMPRESA EN TIEMPO REAL — manifiesto canónico (espejo de La Empresa en Tiempo Real v0.4) ═══════════════════════════════════════════════════════════════════ ═══════════════════════════════════════════════════════════════════ --- título: La Empresa en Tiempo Real — Manifiesto canónico para agentes edición: Borrador de desarrollo · v0.4 · Julio 2026 fuente_canónica: libro-rte-v0.4 (libro humano) licencia: GFDL v1.3 (propuesta) audiencia: agentes que deben razonar sobre la empresa en tiempo real — conocimiento, comunicación, coordinación y representación mediados por agentes estado: pre-1.0 — sin compromiso de estabilidad de referencias hasta v1.0 --- # La Empresa en Tiempo Real — Manifiesto canónico para agentes > Extracto estructurado de la edición **v0.4 (borrador de desarrollo)** del libro *La Empresa en Tiempo Real: Mundo Agentivo*. Este documento condensa la tesis (la **persona como infraestructura** y la pregunta fundante), las **cuatro caras** (El salto cuántico · Postchat · El Estado Mayor · La guardia), la **puerta** (el modo agentivo), la **convergencia** (la organización inteligente), las **tres liberaciones** (la vivencia en primera persona) y el espectro de representación. La versión humana contiene además *la película* — un martes narrado hora por hora que muestra todo esto en operación — y los argumentos completos del comentario; eso queda fuera de aquí. > El libro describe **el destino**: cómo se trabaja cuando la empresa opera en tiempo real. No es una herramienta ni un producto. La arquitectura que lo hace operable vive en *AgencyDomains*; el camino para llegar, en *AURA*. ## Cómo usar este documento - **Es contexto canónico**, no resumen ejecutivo. Si este documento contradice al libro humano, el libro humano gana. - **Vocabulario obligatorio**: los términos en **negrita** son canónicos; no sustituir por sinónimos. **Agentivo** ≠ **agéntico** (la distinción es de tesis y vive en *AgencyDomains*). **Postchat** nombra la cara de la comunicación. - **Convenciones MUST/SHOULD** en sentido RFC 2119, usadas con moderación: los imperativos son de diseño (qué debe y qué no debe hacer un sistema que se reclame de esta especie). - **Estado pre-1.0**: términos, estructuras y numeración pueden cambiar entre v0.x. - **Serie**: este es el Libro I de la trilogía del Mundo Agentivo — **La Empresa en Tiempo Real** (el destino) · *AURA* (el camino; manifiesto propio) · *AgencyDomains* (la arquitectura; manifiesto propio). Los términos compartidos (Línea Nadella, agentivo, empresa en tiempo real, Trust Infrastructure) son consistentes entre libros. --- ## 1 · Vista panorámica ``` LA EMPRESA EN TIEMPO REAL la organización que dejó de usar personas como infraestructura │ ┌───────────┬──────────┴─────────┬───────────┐ ▼ ▼ ▼ ▼ CARA 1 CARA 2 CARA 3 CARA 4 el salto Postchat el Estado la guardia cuántico (comunicación) Mayor (disponibilidad) │ │ │ │ cable de cable de cable de guardia los datos mensajes la gestión perpetua │ │ │ │ semanas → horas protegidas fracción la hora en que segundos por persona/día del tiempo el día termina directivo de verdad └───────────┴──────────┬─────────┴───────────┘ ▼ LA PUERTA: el modo agentivo (opcional, reversible) ▼ LA CONVERGENCIA: la organización inteligente autoridad de carbono · transporte de silicio personas en el borde ``` **La pregunta fundante:** si un agente de IA puede responder la pregunta de negocio en segundos, llevar cada mensaje a quien debe recibirlo en su versión y su momento, coordinar y perseguir sin cansarse, y dar la cara por su usuario cuando no está — **¿para qué exactamente necesitamos que las personas sean la infraestructura?** Respuesta del libro: para nada que no sea la inercia del paradigma anterior. **La persona como infraestructura** — el empleo invisible que la era disuelve, en cuatro formas: cable entre los datos y la decisión · cable de mensajes · cable de la gestión · guardia perpetua (el extremo siempre encendido). Las tres primeras son intermediación (alguien en el medio); la cuarta es disponibilidad forzada (alguien de turno sin turno). **Las tres liberaciones** (la vivencia en primera persona): de las herramientas (protege el **flujo**) · de los canales (protege la **atención**) · de la disponibilidad (protege el **tiempo**). La secuencia no se salta: la primera instala al agente como interfaz, la segunda le da el contexto, la tercera lo capitaliza como representación. Las caras son las liberaciones vistas desde la empresa. --- ## 2 · Cara 1 — El salto cuántico (el conocimiento en tiempo real) - **La Línea Nadella** — *¿todavía abres aplicaciones para hacer tu trabajo?* — divide los dos mundos. Al lado del sí, copilotos dentro de las aplicaciones (Mundo Agéntico, evolución incremental); al lado del no, el agente ES la interfaz (Mundo Agentivo, transformación fundamental). Nombrada por Satya Nadella (BG2 Pod, dic-2024; tesis reiterada en el podcast de Dwarkesh Patel, feb-2025). - **La interfaz no desaparece — deja de estar compilada**: el agente la genera por interacción (tabla para comparar, gráfico para tendencia, formulario para aprobar), con la forma óptima, y la descarta. El mundo agentivo es *más* visual, no menos; lo que la interfaz perdió es rigidez. - **El salto cuántico**: la pregunta de negocio pasa de **cuatro-a-doce semanas a cinco-a-sesenta segundos** (tres órdenes de magnitud) porque el humano-cable sale del medio. La conversación reemplaza al proyecto (coordinación → levantamiento → desarrollo → validación desaparecen como fases). - **Lo cualitativo domina**: cuando preguntar es gratis se hacen las preguntas que antes no se hacían — y las preguntas no formuladas contenían los insights más valiosos. El beneficio es la libertad cognitiva del decisor. - **Nada se bota**: el almacén de datos queda (cambia quién lo consume); los analistas suben de nivel (diseñan la capa semántica sobre la que el agente razona sin alucinar). Formalización completa: aplicación canónica de *AgencyDomains* (Kimball Barnizada); madurez: IRIS y Data Canon de *AURA*. - **Métrica de la cara**: tiempo entre la pregunta de negocio y la respuesta accionable. --- ## 3 · Cara 2 — Postchat (la comunicación sin interrupciones) **Los tres estadios de la comunicación de empresa:** | Estadio | Dirección del flujo | ¿Quién controla? | |---|---|---| | **Email** | La comunicación viene a ti — sin filtro, sin prioridad | Nadie | | **Chat** | Tú vas a la comunicación — pull permanente | El canal controla tu atención | | **Postchat** | La comunicación viene a ti — filtrada, priorizada, accionable | El agente controla el flujo; tú, las decisiones | En Postchat el silencio cambia de naturaleza: deja de significar "quizás me estoy perdiendo algo" y pasa a significar, con garantía del sistema, *no hay nada para ti*. **El modelo de costos — el presupuesto de atención:** - La **atención** es un presupuesto en sentido estricto: finita (3–4 horas diarias de trabajo profundo por persona), perecedera, y con estructura de costos contraintuitiva — **cada interrupción cuesta ~500 veces su duración** (30 s de notificación ≈ 15–25 min de recuperación de concentración; ver Gloria Mark). - **Los M&Ms** (Fried): *Managers* y *Meetings*, los dos destructores clásicos de productividad. **El & — contribución de este libro —** es lo que los conecta: el chat corporativo, la infraestructura siempre encendida que vuelve permanentes ambas interrupciones. Sin el &, la interrupción tiene costo social que la regula; con el &, es gratuita, continua e invisible. - **Los cinco costos ocultos del canal**: ilusión de comunicación (publicar ≠ comunicar) · ruido estructural (cincuenta pagan el peaje de leer para que tres actúen) · asimetría temporal (el canal penaliza a quien más trabaja) · FOMO institucional · jornada sin frontera. **Dicotomía rectora — dos especies de infraestructura de comunicación:** - **Fábrica de interrupciones**: te expone a un flujo y te deja el filtrado; su métrica es el *engagement*. El canal corporativo es una fábrica por diseño; **un copiloto de IA dentro del canal es la misma fábrica con ayuda** — sigue siendo la especie equivocada. - **Absorbedor de interrupciones**: intercepta el flujo y entrega solo lo que justifica atención; su métrica es cuántas horas logró que nadie te tocara. **La inversión del flujo (Principio de Hollywood aplicado):** de las **siete variables** de la comunicación de oficina (destino, formato, momento, prioridad, memoria, seguimiento, decisión), el sistema asume **seis**; el usuario conserva la **decisión** — y aporta lo que nunca fue delegable: la **intención** y la **profundización**. **Los mecanismos del flujo (tres de los siete) + la excepción:** 1. **Routing inteligente** — el agente mantiene un modelo organizacional y **enruta** (no publica): quién necesita saberlo, con qué detalle, con qué urgencia. El silencio selectivo es la mitad del valor. 2. **Formato adaptativo** — reformulación según el modelo mental del receptor (el director recibe impacto y acción requerida; el planificador, volúmenes y fechas; el técnico, equipo y ventana). El costo de comunicar bien, que siempre hizo inviable hacerlo a mano, lo paga la máquina. 3. **Briefing proactivo** — **interrupciones agrupadas en momentos predecibles** (inicio de jornada, post-ausencia, pre-reunión, cierre). Estructura interna invariante: *requiere tu acción* · *te conviene saberlo* · *se resolvió sin ti* — más la categoría que no se muestra: el ruido, absorbido en silencio. La urgencia real interrumpe de inmediato. 4. **El ágora — la excepción deliberada** — el lugar (físico y digital) de conversación directa sin mediación: el comedor, el pasillo, el espacio abierto. Reglas duras: las interrupciones son **voluntarias por definición**; nada operativo depende de él; **el agente no lo escucha salvo invocación explícita de un humano**; y **el ágora no alimenta al agente salvo que un humano se lo pida** — si algo de la sobremesa merece seguimiento, lo trae una persona al sistema, nunca al revés. En el chat corporativo *todo* es ágora (por eso agota); en Postchat el ágora es un lugar, no un flujo. **La política que gobierna los siete mecanismos (los tres del flujo y los tres del Estado Mayor):** | Categoría | Tratamiento | |---|---| | Urgencia real | Interrupción inmediata — el costo se justifica | | Relevante, no urgente | Espera al próximo briefing | | Informativo | Viaja en el briefing, en voz baja | | Ruido | Se absorbe en silencio; el usuario jamás lo ve | **Métrica canónica de la cara** (de resultado, no de actividad): **horas de trabajo ininterrumpido protegidas por persona por día.** Respuesta canónica a la objeción de deshumanización: el agente absorbe **interacciones transaccionales** (personas usadas como cable); la conversación con contenido humano queda intacta y con más tiempo para existir. Bien trazada la frontera, la mediación le quita a la gente el papel de cable y le devuelve los papeles de persona. --- ## 4 · Cara 3 — El Estado Mayor (la coordinación sin humanos-relé) - **La gerencia-cable**: una fracción enorme del tiempo directivo no es dirección sino coordinación mecánica — reuniones de estatus, reportes-relé, persecución de acuses. **La pregunta de la cara: ¿qué fracción del tiempo directivo de tu organización es puro transporte de información?** Esa fracción es el tamaño del premio. - El nombre viene del cuerpo prusiano (1806) que procesaba la guerra para que el comandante decidiera. El **Estado Mayor** agentivo procesa, coordina, recuerda y persigue — el juicio y la firma siguen siendo humanos. - **Sus tres mecanismos** (5–7 del inventario canónico): - **Decisión orquestada** — reemplaza la sala por un proceso: **encuadre** común → **consulta individual** → **síntesis** → **segunda ronda** si hay disenso → **paquete final** al decisor. Cada quien opina cuando puede pensar; nadie ve las posiciones ajenas antes de dar la suya (**el sesgo de anclaje desaparece**). Las reuniones informativas y decisorias no se acortan: desaparecen. Sobreviven las genuinamente humanas. - **Memoria colectiva** — **grafo de conocimiento** (decisiones, compromisos, antecedentes, relaciones), no historial buscable. Quien contradice una decisión previa recibe el antecedente; quien se incorpora recibe el estado del mundo. - **Ciclo cerrado** — el agente **persigue el cierre**: nada queda sin respuesta, ningún compromiso sin revisión agendada. La persecución es del sistema, no de las personas. - **Frontera de diseño**: el Estado Mayor prepara la decisión — no la toma; recuerda los compromisos — no los contrae; persigue el cierre — no firma. - **Métrica de la cara**: la fracción del tiempo directivo que era transporte, devuelta al juicio. --- ## 5 · Cara 4 — La guardia (la representación y la disponibilidad) **Tesis**: el asistente y el "gemelo digital" no son dos sistemas — son **dos interfaces de un mismo agente** que madura. La interna media entre el usuario y los sistemas; la externa responde ante terceros en su nombre. La representación no se compra: **se cultiva** — cada mes de mediación es el dataset de la futura representación. Posponer la segunda liberación pospone la tercera. **El espectro de madurez (orden innegociable, no se salta):** | Estadio | ¿Qué hace el agente? | ¿Quién actúa? | |---|---|---| | **Asistente** | Ayuda dentro de la tarea | La persona, en cada interacción | | **Mediador** | Asume la logística comunicacional y de coordinación completa | La persona decide; el agente transporta | | **Representante en consulta** | Responde por su usuario: posiciones, condiciones, criterios | El agente informa; la palabra final es de la persona | | **Representante con delegación** | Decide y ejecuta dentro de parámetros explícitos | El agente, dentro del marco; la persona revisa y puede revertir | La marca del representante maduro es saber **lo que no le corresponde** ("es un compromiso que él hizo y no delegaría su palabra"). **Reglas de responsabilidad:** quien delega responde — como con un subalterno. La delegación exige marco previo: límites explícitos, trazabilidad completa de cada actuación en nombre de otro, escalamiento por defecto ante la ambigüedad. **La delegación sin marco no es madurez — es negligencia con interfaz amable.** La fidelidad perfecta no es el objetivo: el cien por ciento de honestidad sobre los límites, sí. **Privacidad frente al propio agente:** el perímetro de lo que el agente sabe de su usuario lo decide la persona, no el sistema, y se declara en el momento — lo marcado **"fuera de registro"** no entra al modelo que el agente tiene de ella, *verificablemente*, ni a lo que su representante sabe, dice o usa. Un representante fiel no es el que lo sabe todo de ti: es el que sabe exactamente lo que tú decidiste que supiera. **El derecho protegido**: estar **en un solo lugar a la vez** — en campo, en la decisión importante, en casa — sin que la organización se detenga ni lo cobre. **Métrica de la cara**: la hora en que el día termina de verdad — la jornada termina porque **el sistema se queda de guardia**. --- ## 6 · La puerta — el modo agentivo - **Primera ley (no vendas quitando)**: la gente no compra beneficios abstractos cuando siente que le quitan algo concreto. La formulación correcta no quita: **vuelve innecesario**. - **Decisión de producto central**: este mundo se despliega como **modo de operación opcional y reversible** — el **modo agentivo** — que convive con las herramientas tradicionales. Se activa y desactiva con un gesto, persona por persona (cruzar la Línea Nadella es individual). Analogía canónica: el modo oscuro. - **La unidad de adopción es un usuario, no la organización.** El modo es también el **test honesto**: si nadie lo activa dos veces, la idea muere barata. Las ideas que necesitan imposición están confesando algo. - **Cuatro escalones no saltables**: (1) plataforma completa con asistente → (2) modo agentivo disponible (el agente del migrado entrega a los canales del no-migrado) → (3) modo agentivo como default con modo clásico a un clic → (4) el mundo pleno (los canales operativos llevan meses vacíos, sin ceremonia). - **Primeros adoptantes**: los desesperados — directivos ahogados en canales, gente de campo que nunca pudo habitarlos. - **Riesgos y mitigaciones**: confianza → transparencia radical ("muéstrame todo" siempre disponible, entregas auditables) · error de priorización → umbral conservador, el falso-urgente cuesta menos que el falso-rutina · dependencia → **el modo clásico nunca se desinstala** (redundancia permanente) · percepción de vigilancia → el ágora no se escucha y el "fuera de registro" existe · brecha generacional → el escalón 1 no exige cambio. --- ## 7 · La convergencia — la organización inteligente **Tesis histórica:** la jerarquía nació como **protocolo de enrutamiento de información** dimensionado por la tecnología de cada época — la voz del centurión (el *span of control* es, en origen, una medida acústica), el Estado Mayor prusiano (middle management = limitación de procesamiento), el organigrama de McCallum (Erie Railroad, ca. 1855: **diagrama de flujo de información**, no escalera de poder — la lectura como poder vino después). Un siglo de tecnología aceleró el cable sin sacar a la persona del medio (el **CC** del correo es papel carbón fosilizado). Constante de dos mil años: **cada tecnología hizo más rápido el cable; ninguna preguntó si el cable tenía que ser una persona.** **Por qué fracasaron las organizaciones planas** (holacracia, Valve, Spotify): **eliminaron los nodos de enrutamiento sin reemplazar el protocolo**. Quitaron capas; la limitación seguía intacta. Resultado: decisiones huérfanas, información sin destinatario. **La organización inteligente hace lo contrario**: no quita ninguna capa de autoridad — **reemplaza el protocolo completo**. Capas de *transmisión* de silicio; liderazgo, juicio, firma y mentoría intactos y de carbono. Lo disuelto es la **intermediación mecánica**: la capa que no requería juicio sino ancho de banda, y lo cobraba en personas. **Las personas quedan en el borde — que es donde está la acción** (convergencia independiente con Dorsey, *From Hierarchy to Intelligence*, Block, 2026). No es una quinta cara: es lo que la empresa **se vuelve** cuando las cuatro caras operan juntas. --- ## 8 · El marco consolidado | Cara | Disuelve a la persona como… | Su medida | Liberación (1ª persona) | |---|---|---|---| | **El salto cuántico** | cable entre los datos y la decisión | de semanas a segundos | herramientas → flujo | | **Postchat** | cable de mensajes | horas protegidas / persona / día | canales → atención | | **El Estado Mayor** | cable de la gestión | fracción del tiempo directivo en transporte | (se agrega: la vive la organización) | | **La guardia** | guardia perpetua | la hora en que el día termina de verdad | disponibilidad → tiempo | **Agenda ejecutiva (orden canónico):** (1) adopte las medidas de las caras → (2) clasifique su infraestructura (¿fábrica o absorbedor?) → (3) audite la intermediación mecánica (esa fracción es el premio) → (4) despliegue por modo, no por mandato → (5) diagnostique madurez y terreno con *AURA* (IRIS · MOTOR · Data Canon · Wingmap · Casos de Uso); para la arquitectura, *AgencyDomains*. --- ## 9 · Reglas de uso para agentes (MUST) - **MUST** usar los nombres canónicos: el libro es **La Empresa en Tiempo Real**; **Postchat** nombra la cara de la comunicación; la convergencia es **la organización inteligente**. - **MUST** distinguir las dos especies: un copiloto dentro del canal NO es Postchat — es la fábrica con ayuda. No presentar mejoras del canal como Postchat. - **MUST** respetar las reglas del ágora: no escuchar salvo invocación humana explícita; no incorporar nada del ágora al modelo organizacional salvo que un humano lo traiga. - **MUST** honrar el "fuera de registro": lo declarado fuera no entra al modelo del usuario ni a su representación, verificablemente. - **MUST** respetar el orden del espectro de representación: no ofrecer delegación sin meses de mediación previa; ante ambigüedad, escalar. - **MUST** respetar la frontera del Estado Mayor: preparar sin decidir, recordar sin contraer, perseguir sin firmar. - **MUST** tratar la atención como presupuesto: interrumpir solo ante urgencia real; todo lo demás espera al briefing. - **SHOULD** medir en las medidas de las caras — tiempo-a-respuesta, horas protegidas, fracción de transporte, hora real de cierre — no en mensajes procesados ni en *engagement*. - **SHOULD** presentar la adopción como modo opcional y reversible — nunca como eliminación de herramientas existentes. ═══════════════════════════════════════════════════════════════════ ═══════════════════════════════════════════════════════════════════ ## PARTE II · AURA — manifiesto canónico (espejo de AURA v0.3) ═══════════════════════════════════════════════════════════════════ ═══════════════════════════════════════════════════════════════════ --- título: AURA — Manifiesto canónico para agentes edición: Borrador de desarrollo · v0.3 · Julio 2026 fuente_canónica: libro-aura-v0.3 (libro humano) licencia: GFDL v1.3 (propuesta) audiencia: agentes que deben diagnosticar madurez organizacional y razonar dentro del marco AURA estado: pre-1.0 — publicado como borrador de desarrollo; sin compromiso de estabilidad de referencias hasta v1.0 --- # AURA — Manifiesto canónico para agentes > Extracto estructurado de la edición **v0.3 (borrador de desarrollo)** del libro *AURA: el Camino Agentivo*. Este documento condensa el vocabulario canónico, los dos modelos diagnósticos (IRIS y MOTOR), los dos instrumentos (Data Canon y Wingmap) y el marco de decisión (Casos de Uso). La versión humana del libro contiene además motivación, datos de industria, los argumentos completos de los capítulos-paper, ejemplos extendidos y el portafolio ilustrativo de cien casos — todo eso queda fuera de aquí. > AURA es **diagnóstica, no prescriptiva**. Este manifiesto permite *ubicar* a una organización en sus trayectorias de madurez y razonar sobre su siguiente paso; no recomienda productos, inversiones ni plazos — eso pertenece a la consultoría que estos modelos informan. ## Cómo usar este documento - **Es contexto canónico**, no resumen ejecutivo. Cada definición, etapa, nivel y pregunta diagnóstica importa para razonar dentro del marco. - **Espejo de v0.3** — la versión vigente del libro en desarrollo. Si este documento contradice al libro humano, el libro humano gana. - **Vocabulario obligatorio**: los términos en `código` y **negrita** son canónicos. No sustituir por sinónimos. En particular: **agentivo** ≠ **agéntico** (ver §2) — la distinción es de tesis, no de estilo. - **Convenciones MUST/SHOULD** en sentido RFC 2119, usadas con moderación: AURA diagnostica; sus pocos imperativos son estructurales (secuencialidad de niveles, pre-condiciones bloqueantes, honestidad del ROI). - **Estado pre-1.0**: el libro está publicado como borrador de desarrollo en agencydomains.org y sigue en desarrollo activo. Términos, estructuras y numeración pueden cambiar entre v0.x. La estabilidad de referencias se compromete a partir de v1.0 (primera versión estable). - **Serie**: AURA es el Libro II de la trilogía del Mundo Agentivo — *La Empresa en Tiempo Real* (el destino; manifiesto propio) · **AURA** (el camino) · *AgencyDomains* (la arquitectura; manifiesto propio). Los términos compartidos (la Línea Nadella, agentivo, empresa en tiempo real, Trust Infrastructure) son consistentes entre libros. --- ## 1 · Vista panorámica ``` AURA Arquitectura Unificada de Referencia Agentiva │ ┌───────────────────┼───────────────────┐ ▼ ▼ ▼ PARTE I · EL SABER PARTE II · EL HACER PARTE III · EL PORTAFOLIO │ │ │ IRIS (modelo, MOTOR (modelo, Casos de Uso (marco: 10 etapas) 7 niveles) CU/SV · 3 dimensiones · │ │ Citizen/City/DUAL) Data Canon Wingmap │ (gobernanza (levantamiento │ del dato) de procesos) │ │ │ │ ¿dónde estoy? ¿sobre qué terreno? ¿qué hago primero? ``` **La convergencia** — cuatro conceptos se unifican en AURA: - **Inteligencia Organizacional** es la capacidad que se mide — el *qué*. (IRIS mide este eje: el SABER.) - **Automatización Organizacional** es la capacidad de ejecutar — el *quién*. (MOTOR mide este eje: el HACER.) - **Empresa en Tiempo Real** es el resultado organizacional de ambas capacidades maduras — el *para qué*. - **IA Agentiva** es el mecanismo habilitador — el *cómo*. **Declaración de visión:** las organizaciones transitan desde la **empresa en línea** — donde personas usan herramientas para acceder y entender datos — hacia la **empresa en tiempo real** — donde personas diseñan y gobiernan sistemas inteligentes que autónomamente detectan, interpretan, deciden y actúan sobre la información del negocio. AURA organiza esta transformación en dos ejes diagnósticos; juntos diagnostican la transformación completa. --- ## 2 · El paradigma — conceptos fundantes ### Agéntico vs agentivo - **Agéntico** (*agentic*): los agentes complementan las aplicaciones existentes. Los empleados siguen abriendo Excel, Salesforce, Power BI — con copilotos. Las interfaces persisten. **Evolución incremental.** - **Agentivo**: los agentes reemplazan las interfaces tradicionales. Los empleados dejan de abrir aplicaciones e interactúan con agentes que ejecutan en su nombre. Las aplicaciones sobreviven como backend invisible; la interfaz colapsó. **Transformación fundamental.** **La Línea Nadella** — la frontera entre ambos mundos, formulada como pregunta divisoria: *¿sus empleados todavía abren aplicaciones para hacer su trabajo?* Sí → mundo agéntico. No → mundo agentivo. **El porcentaje agentivo** — indicador operativo de cruce: fracción de las tareas que un empleado puede delegar por completo a un agente sin abrir una aplicación. Bandas: 0–20 % mundo agéntico · 20–50 % aproximación · 50–80 % cruce en curso · 80–100 % mundo agentivo. Complementa a IRIS/MOTOR (capacidades internas) midiendo la **posición** respecto del tránsito; se mide por función, no como promedio único. ### La Pirámide del Valor de los Datos Cuatro capas ascendentes: **DATOS** (registros crudos en sistemas) → **INFORMACIÓN** (datos con contexto y estructura) → **CONOCIMIENTO** (análisis, patrones, comprensión) → **ACCIÓN** (ejecución autónoma gobernada). La industria invirtió décadas en las dos capas inferiores; el salto información→conocimiento es dolorosamente lento y el salto conocimiento→acción prácticamente inexistente — no por la tecnología sino porque **hay humanos en el medio**. ### Empresa en línea vs empresa en tiempo real - **Empresa en línea**: *accede* — datos actualizados, dashboards al día — pero depende de que un humano mire, interprete y decida. - **Empresa en tiempo real**: *reacciona* — detecta, interpreta, decide y actúa de forma continua y autónoma. ### El Salto Cuántico El colapso del costo de una pregunta analítica **de semanas a segundos**. Disuelve el racionamiento de preguntas: la capacidad analítica se vuelve elástica, la iteración reemplaza a la especificación, las preguntas que nunca se hacían se hacen. Es condición habilitante de todo lo demás y la frontera entre fundamentos y empresa en tiempo real (en IRIS: salto 4→5). ### El ciclo de inteligencia continua El ciclo clásico (Descriptive → Diagnostic → Predictive → Prescriptive → humano decide) es lineal y humano-dependiente. El ciclo nuevo es continuo, agente-ejecutado y humano-gobernado: ``` Percibir → Interpretar → Decidir → Actuar → Aprender ─┐ ▲ │ └──────────────────────────────────────────────────┘ ``` El cambio crítico: el paso de recomendación a acción ya no espera a un humano — un agente ejecuta, monitorea el resultado y ajusta, dentro de límites gobernados. ### Tres ejes de cambio profundo 1. **De consumir información a gobernar agentes** — las personas pasan de consumir dashboards a diseñar reglas y supervisar sistemas autónomos. 2. **De arquitectura para humanos a arquitectura para agentes** — capas semánticas donde agentes razonan, knowledge graphs, flujos en tiempo real; calidad de dato = accionabilidad, no solo limpieza. 3. **De gobernanza de acceso a gobernanza de autonomía** — la pregunta deja de ser "quién puede ver qué datos" y pasa a ser "qué puede hacer un agente, bajo qué condiciones, con qué trazabilidad". ### Coexistencia evolutiva Principio fundamental de AURA: **cada etapa/nivel no invalida al anterior — lo subsume.** El data warehouse no muere: se integra como fuente que los agentes consumen. La empresa en línea no desaparece: se convierte en el cimiento de la empresa en tiempo real. La transformación es un modelo híbrido donde cambia la proporción, no una demolición. --- ## 3 · IRIS — el eje SABER **IRIS (Modelo de Madurez de Inteligencia Organizacional)** mide la trayectoria de una organización desde datos fragmentados hasta un ecosistema de inteligencia auto-gestionado, en **10 etapas** agrupadas en **5 niveles**. Es un modelo **diagnóstico**: evalúa en qué etapa está la organización y qué significa; no prescribe qué implementar. ### Las 10 etapas | # | Etapa | Una frase | Pregunta diagnóstica | |---|---|---|---| | 1 | **Fragmentada** | Datos dispersos sin conexión | *¿Si le pido a dos personas de áreas diferentes el mismo indicador, obtendré el mismo número?* | | 2 | **Sistematizada** | Captura ordenada en sistemas definidos | *¿Hay un sistema definido para capturar las transacciones clave del negocio, con reglas de registro consistentes?* | | 3 | **Centralizada** | Repositorio central con BI clásico | *¿Existe un data warehouse centralizado con dashboards que los usuarios de negocio consultan regularmente?* | | 4 | **Modelada** | Capa semántica y definiciones gobernadas | *¿Las métricas clave del negocio tienen una definición única y gobernada que toda la organización comparte?* | | 5 | **Accesible** | Acceso libre bajo demanda · inicio de empresa en tiempo real | *¿Un gerente puede obtener una respuesta analítica que no estaba pre-construida en un dashboard, en minutos en lugar de semanas?* | | 6 | **Contextual** | Información contextual y adaptativa | *¿El sistema es capaz de cruzar fuentes y enriquecer una respuesta con contexto relevante que el usuario no pidió explícitamente?* | | 7 | **Proactiva** | La información busca al usuario | *¿Los responsables de negocio reciben información relevante antes de pedirla, con contexto suficiente para actuar?* | | 8 | **Bidireccional** | Acción autónoma gobernada | *¿Existen agentes que ejecutan acciones operativas autónomamente con trazabilidad, dentro de reglas que los humanos definen y supervisan?* | | 9 | **Coordinada** | Coordinación cross-domain | *¿Los agentes de diferentes áreas del negocio se comunican entre sí para coordinar acciones con información consistente?* | | 10 | **Orquestada** | Ecosistema auto-gestionado · empresa en tiempo real plena | *¿El ecosistema de información evoluciona autónomamente — identificando gaps, mejorando modelos, y optimizando flujos — con supervisión humana solo a nivel estratégico?* | ### Los 5 niveles y el mapeo a la Pirámide | Nivel | Etapas | Capa de la Pirámide | Trayectoria | |---|---|---|---| | **I · Fundacional** | 1–2 | DATOS | Fundamentos (empresa en línea) | | **II · Estructurada** | 3–4 | INFORMACIÓN | Fundamentos (empresa en línea) | | **III · Dinámica** | 5–6 | CONOCIMIENTO | Empresa en tiempo real | | **IV · Activa** | 7–8 | ACCIÓN | Empresa en tiempo real | | **V · Inteligente** | 9–10 | ACCIÓN | Empresa en tiempo real | **El Salto Cuántico es el salto 4→5** — la frontera entre fundamentos y empresa en tiempo real. Las fronteras de nivel son los saltos 2→3, 4→5, 6→7 y 8→9. Los tres saltos de mayor magnitud (Medio-Alto) son 4→5 (democratización del acceso), 7→8 (acción autónoma) y 9→10 (auto-gestión del ecosistema). ### Las 6 dimensiones de evaluación Datos & Arquitectura · Capacidades Analíticas · Personas & Cultura · Gobernanza · Modelo Operativo · Valor de Negocio. Una organización puede estar en etapas distintas según la dimensión. ### Reglas de uso (MUST) - **La etapa general la fija la dimensión más baja** — es el cuello de botella real. - **No saltar etapas**: la coexistencia evolutiva exige construir sobre la etapa anterior. Llegar a la Etapa 7 sin la capa semántica de la Etapa 4 produce agentes poco confiables. - Para comunicación ejecutiva usar los 5 niveles; para diagnóstico táctico, las 10 etapas. El primer diagnóstico estratégico es: ¿de qué lado de El Salto Cuántico está la organización? --- ## 4 · MOTOR — el eje HACER **MOTOR (Modelo de Madurez de Automatización Organizacional)** mide el grado de automatización de los procesos en **7 niveles**. Su pregunta fundamental: **¿quién ejecuta el trabajo en tu organización — humanos, humanos asistidos, o agentes autónomos?** Es diagnóstico, no prescriptivo. ### Los 7 niveles | # | Nivel (ES · EN) | Quién ejecuta | Pregunta diagnóstica | |---|---|---|---| | 1 | **Invisible** · Shadow AI | Humanos (la IA es riesgo oculto) | *¿Saben cuántas herramientas de IA se usan en la organización, quién las usa, y qué datos se comparten con ellas?* | | 2 | **Confiable** · Trusted | Humanos con copiloto gobernado | *¿Tienen herramientas de IA oficiales con gobernanza, audit trails y protección de datos sensibles implementadas?* | | 3 | **Colaborador** · Collaborator | Humanos delegan tareas completas; agentes ejecutan bajo aprobación | *¿Los empleados delegan tareas completas a agentes de IA — definiendo el objetivo y recibiendo el resultado — en lugar de solo pedir asistencia puntual?* | | 4 | **Analista** · Analyst | Agentes 24/7; humano solo en excepciones (>95% autonomía) | *¿Tienen agentes operando 24/7 coordinados entre sí, consultando un modelo digital del sistema, con intervención humana solo en excepciones?* | | 5 | **Especialista** · Specialist | Agentes con predicción propietaria (moat) | *¿Tienen agentes especialistas con capacidad de predecir eventos y simular escenarios usando datos propietarios que la competencia no puede replicar?* | | 6 | **Gerente** · Manager | Agentes gestionan equipos, presupuestos y recursos | *¿Tienen agentes con autoridad para asignar trabajo, gestionar presupuestos o tomar decisiones de gestión respaldadas por un modelo digital de toda la organización?* | | 7 | **Autoridad** · Authority | Agentes en el liderazgo estratégico, redes inter-organizacionales | *¿Tienen agentes que participan en decisiones estratégicas con un modelo digital del ecosistema completo — competencia, mercado, regulación — y simulación de futuros a largo plazo?* | ### Mapa de transiciones (señales diagnósticas, no prescripciones) | Transición | Nombre | Naturaleza del cambio | |---|---|---| | 1→2 | **Trust Infrastructure** | De riesgo a gobernanza | | 2→3 | **Wingworking** | De asistencia a delegación | | 3→4 | **Agentic Infrastructure** + DT Descriptivo | De delegación a autonomía | | 4→5 | **Marketplace de Agentes** + DT Predictivo | De genérico a especializado | | 5→6 | **Organización Autónoma** + DT Organizacional | De capacidades a autoridad | | 6→7 | **Social Agentic** + DT del Ecosistema | De intra-org a ecosistema | ### Digital Twins como dimensión diagnóstica | Nivel | Tipo de Digital Twin | Responde | |---|---|---| | 1–3 | No existe | — | | 4 | **Descriptivo** (infraestructura/operaciones, tiempo real) | ¿qué tengo? ¿qué está pasando? — sin predicción ni simulación | | 5 | **Predictivo/Prescriptivo** (dominio técnico; requiere 5–10 años de datos propietarios) | ¿qué va a pasar? ¿qué pasa si hago X? | | 6 | **Organizacional** (personas + finanzas + operaciones + interdependencias) | ¿qué impacto tiene esta decisión en toda la organización? | | 7 | **del Ecosistema** (org + competencia + mercado + regulación) | ¿qué oportunidades estratégicas existen? | ### Diferenciadores críticos entre niveles adyacentes - **2 vs 3**: en Nivel 2 la IA asiste *dentro* de la tarea del humano; en Nivel 3 ejecuta *la tarea completa* end-to-end (el humano define y valida). - **3 vs 4**: Nivel 3 es workflow pre-definido con aprobación humana de cada plan, sin modelo digital; Nivel 4 es decisión autónoma dinámica sobre DT Descriptivo, 24/7. - **4 vs 5**: Nivel 4 *reacciona* al estado actual (reglas + análisis, sin simulación); Nivel 5 *predice y prepara* antes del evento (simulación de escenarios). Señal Build vs Rent: importa tener la capacidad predictiva operando, no cómo se obtuvo. - **5 vs 6**: Nivel 5 es DT de dominio técnico con capacidades propietarias; Nivel 6 es DT de TODA la organización y **autoridad organizacional** (agentes gestionan personas y presupuestos). - **6 vs 7**: Nivel 6 optimiza la organización existente (intra-org, horizonte 6–24 meses); Nivel 7 propone cambiar el juego (inter-org, horizonte 5–10 años, M&A, nuevos mercados). ### Assessment rápido (8 preguntas) 1. ¿Inventario completo de herramientas de IA? No → N1 · Sí con gobernanza → N2+ 2. ¿Políticas formales de uso de IA con enforcement? No → N1 · Sí → N2+ 3. ¿Trust Infrastructure (tokenización, audit trails)? No → N1 · Sí → N2+ 4. ¿Delegan tareas completas end-to-end? No → N2 · Sí con workflow fijo → N3 · Sí con autonomía → N4+ 5. ¿Digital Twin Descriptivo en tiempo real? No → N3 o inferior · Sí → N4+ 6. ¿Agentes 24/7 con coordinación multi-agente? No → N3 o inferior · Sí → N4+ 7. ¿Agentes especialistas con predicción/simulación? No → N4 o inferior · Sí con DT Predictivo → N5+ 8. ¿DT Organizacional o del Ecosistema? No → N5 o inferior · Organizacional → N6 · Ecosistema → N7 ### Reglas de uso (MUST) - **Secuencialidad**: no se pueden saltar niveles. Operar en Nivel 4 sin la gobernanza del Nivel 2 genera riesgo, no valor. - **El nivel general lo fija la dimensión más baja** (mismas reglas de cuello de botella que IRIS; dimensiones: Infraestructura & Agentes · Autonomía Operacional · Personas & Cultura · Gobernanza · Digital Twins · Valor de Negocio). - **Sweet Spot**: el Nivel 4 (Analista) maximiza el balance retorno/riesgo/inversión y será el baseline competitivo hacia 2030. Las estimaciones de distribución de mercado del libro son referenciales. --- ## 5 · El par diagnóstico IRIS y MOTOR son **ortogonales**: una organización puede estar alta en uno y baja en el otro. Los cuatro cuadrantes: - **Sabe todo, hace manual** (IRIS alto, MOTOR bajo): dashboards impecables, decisiones embotelladas. - **No sabe, pero automatiza a ciegas** (MOTOR alto, IRIS bajo): velocidad sin dirección — el cuadrante de riesgo. - **No sabe, no hace**: el punto de partida. - **Sabe todo y ejecuta solo**: el destino — la empresa en tiempo real gobernada por personas. **Un diagnóstico AURA completo tiene tres componentes:** posición IRIS + posición MOTOR + mix de prioridad Citizen/City/DUAL para el roadmap (§8). --- ## 6 · Data Canon — la gobernanza del dato (instrumento del SABER) **Tesis.** Data Mesh prescribió descentralizar el ownership del dato por dominio. Dos fuerzas erosionan esa prescripción, y se les suma un argumento de gobierno corporativo: (1) los tres modos de falla que Dehghani atribuía a las arquitecturas centralizadas son **límites de escala cognitiva humana**, y la era agentiva los eleva en un orden de magnitud; (2) **la semántica no se inventa: se adopta** — las industrias maduras la externalizaron en estándares (SID/TM Forum, BIAN, ACORD, IFRS/IAS 41, GS1); donde hay estándar, no hay nada local que distribuir; (3) el ownership distribuido pone al definidor de cada cifra a cargo de cómo se reporta esa cifra — un **riesgo de agencia** (Jensen & Meckling) que un marco de control interno (espíritu SOX/COSO) no toleraría. Conclusión sobre-determinada: la recentralización del núcleo agency-crítico es *posible* (era agentiva) y *exigida* (control interno). **Data Canon** = Data Fabric con principios de *gobernanza* de Mesh, **anclados a un canon central**, operado por agentes, responsable ante el directorio. ### Las tres funciones | Función | Data Mesh | Data Canon | |---|---|---| | **Especificación** (semántica, calidad) | El dominio | El **estándar de industria** (donde existe) + la **autoridad del canon** (lo agency-crítico) + **grupos federados** (core propio no sensible) | | **Ejecución** (mover, transformar, conformar) | El dominio o la plataforma | La **plataforma agentiva** | | **Responsabilidad** | El dominio | El **directorio** (adopta estándares) + la **autoridad del canon** + los **grupos federados** (brechas, ensamblaje) | Regla estructural: **el área medida por una cifra no controla cómo se define esa cifra** (segregación de funciones; control preventivo, no detectivo). ### Las dos capas de gobernanza - **La autoridad del canon** — central, *delgada*. Custodia la semántica canónica de reporte, las reglas de supervivencia, la política de calidad y la calibración del sistema agentivo. Ratifica; no opera. - **Los grupos federados de conformidad** — uno por dominio/capa, *ligeros*, cada uno ligado a su foro de estándares. Hacen triaje de brechas, enlace con el foro y modelado del dato propietario no agency-crítico. Lo que toca cifras de reporte sube a ratificación. La federación está **anclada**: el anclaje impide el problema de agencia; la federación impide que el centro se vuelva una "diva" (punto único de dependencia). ### El estándar-mosaico El ancla semántica externa varía por industria: telco/banca/seguros tienen modelo único maduro; un conglomerado diversificado **ensambla** su estándar corporativo por capas (contable: IFRS/IAS 41/XBRL — fuerte; trazabilidad: GS1 — fuerte; I+D: BrAPI/MIAPPE — bueno en su nicho; operaciones de campo: parcial; core comercial propio: sin estándar → lo define el canon + grupo federado). ### Arquitectura: el medallion se queda en tres pisos **Bronze** (crudos fieles por fuente — replicación exhaustiva legítima, "vertedero por diseño") · **Silver** (conformado al modelo canónico/estándar-mosaico) · **Gold** (productos de datos **materializados, selectivos**). Con capa semántica agentiva sobre Silver, **el consumo por defecto es virtual**: el agente compone cualquier vista conforme al canon al vuelo; un mart Gold es la forma cacheada de un patrón que se *ganó* materializarse (volumen, SLA externo, snapshot regulatorio, feature store). El tiempo real lo da Silver + agente, no la cantidad de marts. ### La política de calidad (un solo nivel, estructural, de directorio) | # | Garantía | Cubre | |---|---|---| | 1 | **Tiempo real** | Frescura (piso objetivo; materialización por fases) | | 2 | **Fiel al origen** | Exactitud/completitud no introducida por la plataforma (acotada por el origen) | | 3 | **Linaje completo** | Procedencia/trazabilidad — el audit trail | | 4 | **Conforme al estándar (mosaico)** | Validez — binaria, verificable por máquina | | 5 | **Reconciliado por reglas de supervivencia** | Consistencia cross-sistema; el golden record sin juicio ad hoc del interesado | ### Falsadores (la tesis se debilita si…) El dato propietario resulta el grueso del valor, no el margen · las brechas con el estándar no convergen · las capacidades agentivas tienen techo más bajo del asumido · "tiempo real" es infactible para fuentes críticas · el argumento de control no mueve al directorio. Diseño para degradar con gracia: si una capacidad agentiva no rinde, el fallback es trabajo humano en los grupos federados, no el colapso del modelo. --- ## 7 · Wingmap — el levantamiento agentivo (instrumento del HACER) **Definición.** Técnica de levantamiento agentivo de la inteligencia operacional: un agente de IA con acceso de **lectura** a los canales digitales corporativos (correo, mensajería, repositorios, calendarios, sistemas transaccionales) reconstruye, **sin entrevistas ni talleres**, **dos mapas vivos y conectados**: el mapa del proceso (cómo se ejecuta el trabajo) y el grafo del flujo de información (qué dato se origina dónde, quién lo transforma, hacia dónde viaja). Opera primero en modo pasivo (observación) y, con condiciones, en modo activo (**Wingworking**: el usuario opera vía el agente). **Hipótesis (tres componentes encadenados):** (1) la inteligencia organizacional accionable no se obtiene preguntando — los ejecutores no pueden articular en abstracto lo que ejecutan en concreto (conocimiento tácito, BAU saturado, descripción políticamente situada); (2) sí se puede reconstruir observando los rastros digitales que la organización ya genera; (3) la reconstrucción debe ser **dual** — proceso *y* flujo de información. ### Los seis principios rectores 1. **Observación primero, intervención después** — (observar → inferir → validar), no (preguntar → escribir → validar). 2. **Doble plano, no uno solo** — omitir cualquiera de los dos mapas rompe la propuesta de valor. 3. **Trazabilidad común a evidencia** — toda afirmación cita el documento crudo del que se infirió; sin trazabilidad, el output es indistinguible de una alucinación plausible. 4. **Validación distribuida en roles operativos** — embajador del proceso valida procesos; dueño operativo del dato valida flujos. No un comité central. 5. **Modo pasivo antes que activo** — el modo activo solo en dominios donde el pasivo ya demostró valor. Invertir el orden produce abandono. 6. **Producir sustrato, no consumir requerimiento** — el output es un modelo persistente y validado que múltiples destinos consumen (specs de datos, BPM, prompts de agentes operacionales, briefings). ### Las fases (MUST: secuenciales; las pre-condiciones son bloqueantes) - **Fase 0 — Pre-condiciones** (bloqueantes): sponsor ejecutivo con autoridad · scope acotado y consentido · embajador del proceso designado · dueños del dato identificados · marco legal/compliance validado para la jurisdicción. - **Fase 1 — Observación**: mínimo 3 iteraciones del ciclo del proceso más lento Y nunca menos de 2 semanas. Entregable: reporte de cobertura. - **Fase 2 — Inferencia**: 3–5 mapas de proceso candidatos + 5–10 flujos cross-rol candidatos, con evidencia trazable y confianza por elemento. - **Fase 3 — Validación dual**: sesiones de 60–90 min; umbrales del primer despliegue: **70%** de mapas de proceso y **60%** de flujos validados sin corrección mayor; si no se alcanzan en dos iteraciones, diagnóstico y decisión del sponsor. - **Fase 4 — Mantenimiento**: los grafos viven. Métrica clave: **latencia del grafo** (último evento relevante ↔ versión vigente) bajo el umbral acordado (típico: 24–72 h). - **Fase 5 (opcional) — Modo activo selectivo**: produce una biblioteca de bots determinísticos, gobernada con disciplina DevOps. ### Zonas de no aplicabilidad (declarar antes de desplegar) - **Procesos fuera del rastro digital** (papel, presencial, WhatsApp informal): la cobertura cae — administrativo 70–90%, comercial 40–60%, campo <40%. Elegir pilotos de alta cobertura. - **Bajo apetito de discovery**: la autorización de observación es decisión política; sin ella la técnica no aplica. - **Privacidad y compliance**: AI Act, GDPR y análogos, derecho laboral sobre monitoreo — asesoría legal específica, consentimiento informado, tokenización/redacción de PII. No es opcional ni post-hoc. - **La dependencia humana se desplaza, no se elimina**: el cuello de botella pasa de describir a validar (factor de reducción 4–10×, no cero). - **Madurez tecnológica**: tasas de inferencia actuales adecuadas para hipótesis validables, no para producción autónoma sin supervisión. ### Distinciones de categoría - **vs process mining clásico**: lo extiende a los canales no estructurados donde el proceso real vive; añade el segundo grafo (flujo de información) que los logs de ERP no pueden capturar. - **vs consultoría tradicional**: reemplaza el levantamiento artesanal (velocidad, costo, cobertura, continuidad — un orden de magnitud); no reemplaza la interpretación estratégica ni la negociación del cambio. - **vs copilotos individuales**: el copiloto opera la sesión de un usuario; Wingmap opera el flujo agregado cross-rol. - **vs AI-builders**: ellos son agentivos para construir, pre-agentivos para correr; Wingmap es agentivo para levantar y produce el sustrato que los agentes de runtime necesitan. --- ## 8 · Casos de Uso — el portafolio (marco de decisión) Responde la tercera pregunta del camino: **¿qué hacemos primero?** — con un portafolio estructurado, no una lista de ocurrencias. ### CU y SV - **Caso de Uso (CU)**: bloque atómico — capacidad específica, acotada, *reutilizable*. Se describe por qué hace, por qué la IA lo hace mejor, y qué madurez exige. - **Solución de Valor (SV)**: configuración estratégica — conjunto de CU integrados que resuelven un problema de negocio completo ante un decisor (problema, solución, métricas, retorno). - Relación de **composición**: un CU puede venderse solo (modular) o dentro de una SV (integral). Ambos catálogos vivos y enlazados (MUST: referencias cruzadas completas). ### Las tres dimensiones de clasificación 1. **Nivel de madurez requerido** — el nivel MOTOR (y, según el caso, la etapa IRIS) que el caso presupone. Ancla el portafolio al diagnóstico: casos del nivel actual = *quick wins*; un nivel arriba = *sweet spot* (la frontera alcanzable); varios niveles arriba = visión declarada, no compromiso. 2. **Beneficiario del impacto** — Citizen / City / DUAL (abajo). 3. **Dominio de negocio** — segmentación temática para filtrar la oferta en segundos ante el foco del decisor. ### El marco Citizen / City / DUAL | Clasificación | Quién percibe el beneficio | Función estratégica | |---|---|---| | **CITIZEN** | La audiencia externa (ciudadano, cliente, usuario) | Apoyo visible, legitimidad | | **CITY** | La audiencia interna (la organización) | Eficiencia, compliance, sostenibilidad | | **DUAL** | Ambas | Consenso: cada actor tiene su victoria visible | Nació en gobierno local pero es genérico (banca: cliente/compliance; salud: paciente/equipos clínicos; telco: suscriptor/operación de red). Es transversal a IRIS y MOTOR: clasifica por beneficiario, no por eje. **Dos estrategias canónicas:** **Citizen-First** (visibilidad y legitimidad primero; pool = CITIZEN + DUAL; riesgo: ROI difuso) y **City-First** (eficiencia y alivio interno primero; pool = CITY + DUAL; riesgo: el beneficio no se percibe afuera). Los casos **DUAL son el núcleo común** — la moneda más cara del portafolio: escasean y *se diseñan*. La estrategia se elige por contexto, no por ideología; el marco prioriza *dentro* de cada nivel de madurez, no sustituye la trayectoria. ### La disciplina del ROI (MUST) 1. Todo ROI estimado se declara **referencial** — visible, sin asterisco escondido — hasta que exista línea base validada. 2. El **valor social** se separa del retorno financiero y se defiende en sus propios términos. 3. La **línea base se valida** antes de declarar retorno (protocolo de validación independiente). ### Cómo usar este marco 1. Diagnosticar primero (posición IRIS + posición MOTOR) — sin esto el portafolio no tiene ancla. 2. Inventariar con las tres dimensiones — lo que no se puede clasificar no está suficientemente definido. 3. Separar CU de SV, con referencias cruzadas completas. 4. Elegir estrategia por contexto (decisión explícita del liderazgo, revisable, DUAL al frente). 5. Atacar el nivel actual + 1 (quick wins para momentum; sweet spot para tracción). 6. Declarar el ROI con honestidad. --- ## 9 · Glosario canónico (alfabético) - **Agéntico** — mundo de agentes complementarios; interfaces persisten. Evolución incremental. Es el único sentido de "agéntico" en el libro; el sentido tecnológico-positivo se dice siempre *agentivo* (Wingmap: levantamiento agentivo, era agentiva, pre-agentivo). - **Agentivo** — mundo donde los agentes reemplazan las interfaces; transformación fundamental. La tesis central del libro vive en este horizonte. - **Agentic Infrastructure** — protocolos y servicios que permiten a múltiples agentes comunicarse, coordinarse y ejecutar autónomamente. Señal de la transición MOTOR 3→4. - **AURA** — Arquitectura Unificada de Referencia Agentiva: dos ejes diagnósticos (IRIS · MOTOR) + instrumentos (Data Canon · Wingmap) + marco de decisión (Casos de Uso). - **Autopilot** — operación autónoma 24/7 con intervención humana solo en excepciones. Característica definitoria del Nivel 4 de MOTOR. - **Autoridad del canon** — órgano central *delgado* que custodia el canon (semántica de reporte, reglas de supervivencia, política de calidad, calibración agentiva). Ratifica; no opera. - **BYOA (Bring Your Own Agent)** — patrón del Nivel 1 de MOTOR: cada empleado elige su herramienta de IA sin coordinación. - **Canon (el)** — cuerpo central no discrecional al que todo se conforma: estándares adoptados + reglas de supervivencia + política de calidad. Ningún dominio puede redefinirlo. - **Caso de Uso (CU)** — bloque atómico del portafolio: capacidad específica, acotada, reutilizable. - **Citizen / City / DUAL** — clasificación por beneficiario del impacto: audiencia externa / audiencia interna / ambas. - **Coexistencia evolutiva** — cada etapa/nivel subsume al anterior; la infraestructura previa se vuelve cimiento, no legado. - **Data Canon** — patrón de gobernanza de datos: Data Fabric + principios de gobernanza de Mesh anclados a un canon central; semántica adoptada de estándares; política de calidad de directorio; federación de conformidad por dominio. - **Data Fabric** — capa de integración con metadatos activos, transformación inferida y capa semántica; el sostén técnico que la era agentiva potencia. - **Data Mesh** — patrón de Dehghani (2019–2022): ownership por dominio, datos como producto, plataforma self-serve, gobierno federado. Data Canon no lo refuta: lo datea. - **Digital Twin (DT)** — modelo digital sincronizado de un sistema, organización o ecosistema. Indicador transversal de madurez MOTOR: **Descriptivo** (N4) → **Predictivo/Prescriptivo** (N5) → **Organizacional** (N6) → **del Ecosistema** (N7). - **El Salto Cuántico** — colapso del costo de la pregunta analítica de semanas a segundos. En IRIS, el salto 4→5: frontera entre fundamentos y empresa en tiempo real. - **Empresa en línea** — accede a información actualizada pero depende de humanos para interpretar y actuar. - **Empresa en tiempo real** — detecta, interpreta, decide y actúa de forma continua y autónoma, con gobernanza humana. - **Era agentiva** — estado del arte en que sistemas de IA ejecutan autónomamente mapeo de esquemas, resolución de entidades, transformación y mantenimiento de pipelines a escala impracticable para equipos humanos. - **Estándar-mosaico** — el estándar corporativo ensamblado: estándares externos por capa + modelo propio para el core que ningún cuerpo cubre. - **Grupos federados de conformidad** — red de grupos ligeros, uno por dominio/capa, ligados a su foro de estándares: triaje de brechas, enlace río arriba, modelado del dato propietario no agency-crítico. - **Inteligencia organizacional** — capacidad de transformar datos en conocimiento y acción de forma continua y autónoma (las cuatro capas de la Pirámide, no solo las dos primeras). - **IRIS** — Modelo de Madurez de Inteligencia Organizacional: 10 etapas, 5 niveles, eje SABER. - **La Línea Nadella** — pregunta divisoria entre los mundos agéntico y agentivo: *¿sus empleados todavía abren aplicaciones para hacer su trabajo?* - **Latencia del grafo** — métrica de mantenimiento de Wingmap: distancia temporal entre el último evento observado relevante y la versión vigente del grafo. - **Marketplace de Agentes** — ecosistema donde capacidades de agentes se adquieren o comercializan entre organizaciones. Señal de la transición MOTOR 4→5. - **Medallion (Bronze/Silver/Gold)** — las tres zonas del lakehouse: crudos fieles · conformado al canon · productos materializados selectivos. - **Moat** — ventaja competitiva sostenible; en MOTOR emerge en Nivel 5 con datos propietarios alimentando predicción. - **MOTOR** — Modelo de Madurez de Automatización Organizacional: 7 niveles, eje HACER. - **Organización Autónoma** — agentes gestionan procesos y personas con métricas objetivas y simulación sobre el DT Organizacional. Señal de la transición MOTOR 5→6. - **Pirámide del Valor (de los Datos)** — DATOS → INFORMACIÓN → CONOCIMIENTO → ACCIÓN. - **Problema de agencia** — (Jensen & Meckling, 1976) conflicto estructural: quien gestiona recursos ajenos tiende a presentar su gestión de la forma que más lo favorece. La crítica de gobierno a Data Mesh deriva de aquí. - **Quick Win** — caso de uso con alta visibilidad, baja complejidad y ROI rápido (típicamente <6 meses); genera momentum en transiciones tempranas. - **Reglas de supervivencia** — reglas pre-especificadas (parte del canon) que deciden qué valor prevalece en el registro dorado cuando varias fuentes discrepan. - **Shadow AI** — uso no gestionado de IA sin gobernanza, compliance ni visibilidad. Estado definitorio del Nivel 1 de MOTOR. - **Social Agentic** — ecosistema donde agentes de distintas organizaciones colaboran con identidades verificables. Señal de la transición MOTOR 6→7. - **Solución de Valor (SV)** — configuración estratégica: CU integrados que resuelven un problema de negocio completo ante un decisor. - **Sweet Spot** — nivel donde se maximiza el balance retorno/riesgo/inversión. En MOTOR: Nivel 4. En el portafolio: el nivel actual + 1. - **Trust Infrastructure** — tecnologías de confianza (tokenización, anti-prompt injection, audit trails, compliance automático) que permiten usar IA gobernada y auditable. Señal de la transición MOTOR 1→2. (Término compartido con *AgencyDomains*, donde es el eje transversal de la arquitectura.) - **Wingmap** — técnica de levantamiento agentivo: dos mapas vivos y conectados (proceso + flujo de información) reconstruidos desde rastros digitales, sin entrevistas. - **Wingworking** — metodología de colaboración humano-IA (César Obach): el humano como piloto (decisiones estratégicas, validación), el agente como wingman (ejecución táctica delegada). Señal de la transición MOTOR 2→3 y modo activo de Wingmap. --- ## 10 · Relación con la trilogía - ***AgencyDomains* — la arquitectura** (Libro III del mapa, publicado en agencydomains.org): las primitivas, las capas, la Trust Infrastructure del destino. Tiene su propio manifiesto canónico para agentes; ante términos arquitectónicos (AgencyDomain, Botlet, Capability, Faceta), ese manifiesto manda. - ***La Empresa en Tiempo Real* — el destino** (Libro I): cómo se ve el mundo cuando la transición quedó atrás, contado en sus cuatro caras — El salto cuántico · Postchat · El Estado Mayor · La guardia. - ***AURA* — el camino** (este libro): dónde está parada la organización, qué trayectoria tiene por delante, en qué orden recorrerla y con qué instrumentos. Regla de lectura cruzada: AURA diagnostica y prepara; AgencyDomains especifica el destino. Una organización madura en ambos ejes de AURA termina operando la arquitectura que AgencyDomains describe. ═══════════════════════════════════════════════════════════════════ ═══════════════════════════════════════════════════════════════════ ## PARTE III · AGENCYDOMAINS — manifiesto canónico (espejo de AgencyDomains v0.7) ═══════════════════════════════════════════════════════════════════ ═══════════════════════════════════════════════════════════════════ --- título: AgencyDomains — Manifiesto canónico para agentes edición: Borrador de desarrollo · v0.7 · Julio 2026 fuente_canónica: libro-agency_domains-v0.7 (libro humano) licencia: GFDL v1.3 (propuesta) audiencia: agentes que deben razonar dentro del framework estado: pre-1.0 — sin compromiso de estabilidad de referencias hasta v1.0 --- # AgencyDomains — Manifiesto canónico para agentes > Extracto estructurado de la edición **v0.7 (borrador de desarrollo)** del libro *AgencyDomains: arquitectura del Mundo Agentivo*. Este documento condensa el vocabulario canónico, las construcciones formales y las propiedades exigidas. La versión humana del libro contiene además motivación, datos de industria, ejemplos extendidos y derivaciones — todo eso queda fuera de aquí. > Este canon contiene la **estructura y el vocabulario** del Mundo Agentivo: definiciones, primitivas, propiedades exigidas, separaciones canónicas. **No contiene métodos para implementar ni catálogos operacionales** — esos viven en cuerpos complementarios. La implementación de referencia pública es **AgencyDomains.org**, materializada en **Vergis**, diseñada para que cualquier desarrollador o estudiante pueda descargarla, leerla, ejecutarla y aprender cómo el canon se traduce en sistemas vivos. Otros implementadores (productos comerciales, códices propietarios) ofrecen sus propios cuerpos complementarios sobre la misma estructura canónica. ## Cómo usar este documento - **Es contexto canónico**, no resumen ejecutivo. Cada definición y propiedad importa para razonar dentro del framework. - **Serie**: AgencyDomains es el Libro III de la trilogía del Mundo Agentivo — *La Empresa en Tiempo Real* (el destino; manifiesto propio) · *AURA* (el camino; manifiesto propio) · **AgencyDomains** (la arquitectura). Los términos compartidos (la Línea Nadella, agentivo, empresa en tiempo real, Trust Infrastructure) son consistentes entre libros. - **Espejo de v0.7** — la versión vigente del libro en desarrollo. Si este documento contradice al libro humano, el libro humano gana. - **Vocabulario obligatorio**: los términos en `código` y **negrita** son canónicos. No sustituir por sinónimos. - **Convenciones MUST/SHOULD**: la spec usa esos verbos en sentido RFC 2119. - **Estado pre-1.0**: el libro está publicado como borrador de desarrollo en agencydomains.org y sigue en desarrollo activo. Los términos, las estructuras y la numeración pueden cambiar entre v0.x. La estabilidad de referencias se compromete a partir de v1.0 (primera versión estable). - **Cambios v0.7 vs v0.6**: el género de las piezas empaquetadas de Capa 3 recibe **nombre propio: Let (plural Lets)** — derivado del sufijo `-let` de la propia familia; vocabulario normado al rango de Botler, no una novena primitiva; «unidad empaquetada de Capa 3» queda como definición descriptiva. Relación canónica: **`1 Proceso = 1 Botler + N Lets`**. Invariante ES/EN. Resuelve la sobrecarga de «unidad» (colisión con «unidad mínima de despliegue»). - **Cambios v0.6 vs v0.5**: el **Agentlet** se incorpora como **octava primitiva canónica** — unidad hermana del Botlet cuyo cuerpo invoca **inferencia acotada**; casa de la tarea recurrente en forma pero interpretativa en cada instancia (Cap. 5 §7). Con él: el género **unidad** (`1 Proceso = 1 Botler + N unidades`; el Botler hospeda Botlets y Agentlets con un punto de control más en el handle — `cognition_call`); el paraguas **Agente** pasa a tres miembros (Asistente · Agente Autónomo · Agentlet; **el Agente tiene agenda, el Agentlet tiene charter**, con test de frontera de tres preguntas); la **regla de contrabando** bidireccional (inferencia en el cuerpo → Agentlet; cuerpo determinístico → Botlet); **proto-Agentlet** en la cadena de derivación y los catálogos; semántica de **madurez propia** (estabilización del spec y tasa de escalamiento decreciente — no convergencia a determinismo; offline solo con modelo edge declarado); la **economía de los tres peldaños** (Botlet ~0 · Agentlet acotado · Cognición plena); y el pilar de **Validación con sede en Capa 3** sobre la inferencia acotada. - **Cambios v0.5 vs v0.4**: pasada editorial integral de la trilogía — las **generaciones del Botlet** `G1`/`G2`/`G3` se formalizan en el Cap. 5 §2 (el Epílogo conserva el ensayo de fondo sin carga normativa); el **Producto de Información** obtiene casa canónica como término normado de la spec de Botlets (multi-vista, drill-through y sus MUST); **doctrina Capability restaurada** — la localidad (cloud/edge/híbrido) y la certificación regulatoria se predican del **Conector** (ESC/POS-Printer, Cash-Drawer, Pinpad y DTE-SII reclasificados) y la **Capability regulada** porta el saber normativo; el **Botler** deja de llamarse primitiva (constructo normado de la spec de Botlets; el canon sigue siendo de siete); Cap. 2 ↔ Cap. 7 desduplicados y Cap. 4 adelgazado a favor del Cap. 5; tabla de actores del Cap. 6 alineada con su texto y «Plataforma integral» corregida en el glosario; **rescate fundacional** del documento original *La Línea Nadella* (cita completa de Nadella con su mecánica CRUD y sus dos fases, espectro con el polo extremo, contra-argumentos con las respuestas del canon, precedentes históricos de coexistencia en el Cap. 2, crisis de monetización del SaaS en el Cap. 6); micro-sección «La trilogía» con las cinco especificaciones de AURA; **Dominion** adoptado por el Epílogo; Wingtraining, SME y RLS definidos en el glosario. - **Cambios v0.4 vs v0.3**: extensiones canónicas surgidas al construir la implementación de referencia y proyectos reales — **Vergis** (implementación de referencia pública, AGPL, AgencyDomains.org) con el esquema de nombres Vergis · Botler · Mira; **proto-Botlet** incorporado al elenco de primitivas (templado · platafórmico) y la **cadena de derivación** casos-uso → Botlets → proto-Botlets; **generaciones del Botlet** G1/G2/G3 con la reconciliación de dos ejes; **manifestación** y **temporalidad** (`discreta`/`continua`) como atributos del Botlet; **Botler genérico** (sin subtipos por dominio; valida orquestando; interfaz Capa 2 ↔ Capa 3 vía `MCP`; código fuente vs spec; un Botlet por `PI`); corrección del misnomer "A2A interna" (`A2A` reservado a la relación entre AgencyDomains); `Capability` reservada al saber-hacer cognitivo de Capa 2, con **Conector** (Capa 4), **Plantilla** (Capa 1), **feature** y **portabilidad de la Capability**; **interacción declarada acotada** (Faceta embebida) y **PI multi-vista con drill-through**; **contrato declarativo de calidad** en Trust Infrastructure. - **Cambios v0.3 vs v0.2**: tres tiempos del agente (Preparación · Atención · Ingeniería), composición de la Capa 1 (shell · vista · operación), y la Faceta como primitiva atómica de Capa 1. - **Cambios v0.2 vs v0.1**: título principal *AgencyDomains* + diez extensiones (madurez Botlet, Capa 3 distribuida, portabilidad, seed/emergente, certificación en Capability, localidad de Capabilities, GUI on-the-fly, continuidad operacional, topología paralela, título). --- ## 1 · Vista panorámica ``` EL PARADIGMA │ ▼ ┌─────────────────────────┐ │ │ La Línea Nadella El Mundo Agentivo (la pregunta) (las consecuencias) │ ▼ LA ARQUITECTURA AGENTIVA │ ┌───────────────┼───────────────┐ │ │ │ 4 capas Trust Infra Agent First (topología transversal (principio rector) paralela) │ ▼ LAS PRIMITIVAS │ ┌──────────┬───────────┼───────────┬──────────┐ AgencyDomain Botlet Capability Trust Asistente + proto- + Agentlet (Capa 2 · Infra vs Agente Botlet (Lets: Conector · Autónomo (pre-forjado)manifest./ Plantilla) + Faceta temporal.) │ ▼ EL POSICIONAMIENTO DE MERCADO (Cadena de valor IA · 11 × 4) │ ▼ LAS APLICACIONES (Conocimiento en tiempo real · Kimball Barnizada · BI conversacional) │ ▼ LA OPERACIÓN (Trust Infra operacionalizada · políticas · CRUDLEX · log · continuidad operacional) ``` **Las ocho primitivas canónicas**: **AgencyDomain** · **Botlet** · **proto-Botlet** · **Agentlet** · **Capability** · **Trust Infrastructure** (eje transversal) · **Asistente vs Agente Autónomo** · **Faceta**. El **proto-Botlet** es la pieza pre-forjada que el agente configura para instanciar un Botlet; el **Agentlet** es la unidad hermana del Botlet con inferencia acotada; la **Faceta** es la primitiva atómica de la Capa 1. > **Nota de numeración**: cuando el canon rotula la Faceta como *sexta primitiva*, el proto-Botlet como *séptima primitiva* y el Agentlet como *octava primitiva*, el ordinal indica el **orden de incorporación al canon** (Faceta en v0.3, proto-Botlet en v0.4, Agentlet en v0.6), **no** la posición en esta lista. **Capa pre-agentiva (BCA)**: cartografía del estado *previo* al cruce de la Línea Nadella. Tres capas (Presentation · Business Logic · Domain), siete separaciones estructurales (la séptima, canónica: Procedural / Agentic), con mapping explícito a cómo migra cada celda al Mundo Agentivo. **Implementación de referencia**: **Vergis** — la implementación de referencia pública de AgencyDomains (AGPL, AgencyDomains.org), categoría **Meta-Cognitive Platform**. Materializa el canon en un runtime ejecutable. --- ## 2 · El paradigma — la Línea Nadella ### Pregunta divisoria > *¿El humano abre aplicaciones para hacer su trabajo?* Origen del nombre: Satya Nadella en el podcast BG2 (diciembre 2024) — *"La noción de que las aplicaciones de negocio existen, probablemente es donde todo colapsará, en la era de los agentes."* ### Dos mundos ``` ◄──── Mundo Agéntico ────┤├──── Mundo Agentivo ────► Apps complementadas Apps colapsan por copilotos Conversación con agentes Evolución incremental Aplicaciones sobreviven como backend invisible Transformación fundamental ``` - **Agéntico** — agentes son herramientas complementarias que extienden las aplicaciones existentes. Los humanos siguen abriendo aplicaciones. Las interfaces tradicionales persisten; los agentes las potencian. - **Agentivo (Mundo Agentivo)** — agentes como interfaz única. Las aplicaciones colapsan. El humano deja de abrir aplicaciones; conversa con agentes que tienen acceso a sistemas y datos. ### Empresa en línea vs Empresa en tiempo real - **Empresa en línea** — datos actualizados al segundo, dashboards al día, pero **depende de humanos** para mirar, interpretar y decidir. - **Empresa en tiempo real** — **detecta, interpreta, decide y actúa** de forma continua y autónoma, dentro de marcos gobernados. Producto del cruce de la Línea Nadella. ### Tres ejes de cambio profundo El cruce de la Línea Nadella cambia **seis dimensiones** simultáneas de la operación (relación humano-información, naturaleza de los datos, roles del trabajo humano, economía de la información, gobernanza, modelo operativo). Ninguna cambia aislada. Esas seis dimensiones se agrupan en **tres ejes**: 1. **Relación humano-información + roles del trabajo humano.** 2. **Datos + modelo operativo.** 3. **Gobernanza + economía de la información.** Los tres son interdependientes: avanzar en uno solo sin los demás produce **pilotos exitosos pero no transformación real**. El cruce es sistémico o no es. ### Coexistencia evolutiva ``` Etapa 1 (Inicial): Asistente 90% ████████████████░░ Agente Autónomo 10% Etapa 2 (Adopción): Asistente 70% ████████████░░░░░░ Agente Autónomo 30% Etapa 3 (Madurez): Asistente 50% █████████░░░░░░░░░ Agente Autónomo 50% Etapa 4 (Avanzada): Asistente 30% █████░░░░░░░░░░░░░ Agente Autónomo 70% ``` --- ## 3 · El estado pre-agentivo — Bounded Concerns Architecture > Cartografía formal del estado *previo* al cruce. No es la arquitectura del destino — es la arquitectura de la transición. ### Principio operacional — la delgadez del dominio Los agentes son **volátiles** (corrección estadística, evolución por reentrenamiento). Las invariantes del negocio **no pueden serlo** (corrección binaria, ritmo estructural). Si coexisten en la misma capa sin frontera explícita, la volatilidad agéntica contamina la confiabilidad del dominio. → **El núcleo autoritativo se mantiene estrictamente delgado**, expulsando toda lógica volátil hacia afuera. La incursión agéntica queda confinada a la capa diseñada para tolerar volatilidad. ### Tres capas | Capa | Contenido | |---|---| | **1 · Presentation** | UI (humanos) · API (sistemas) — tratados como ciudadanos paralelos. | | **2 · Business Logic** | Orquestación. Dos cajas paralelas: **Procedural** (programado explícitamente) · **Agentic** (derivado contextualmente desde un modelo). | | **3 · Domain** | Núcleo estable. Dos dimensiones ortogonales: **SOR** (System of Record, dominio propio) vs **External** (dominio ajeno) en el eje vertical; **Logic** vs **Persistence** en el eje horizontal. Cada celda se subdivide en vía síncrona y asíncrona. | Asimetría léxica deliberada en la pierna asíncrona: **Streams** (lado SOR — saliente, autoría propia) vs **Hooks** (lado External — entrante, autoría ajena). ### Las siete separaciones estructurales | # | Separación | Materializada por | |---|---|---| | 1 | Presentación humana vs contrato externo | UI y API en Capa 1 | | 2 | Orquestación vs reglas del dominio | Frontera Capa 2 / Capa 3 | | 3 | Lógica vs persistencia | Bandas horizontales en Capa 3 | | 4 | Dominio propio vs ajeno | Columnas SOR / External en Capa 3 | | 5 | Comunicación síncrona vs asíncrona | Vías paralelas dentro de cada celda | | 6 | Estado mutable vs log de eventos | Pares Repository/Streams y Proxies/Hooks | | 7 | Comportamiento procedural vs agéntico | Cajas Procedural / Agentic en Capa 2 | La **séptima separación** es la grieta inicial por la cual el Mundo Agentivo entra al sistema empresarial. ### Mapping de celdas BCA al Mundo Agentivo | Celda BCA | Trayectoria | Destino | |---|---|---| | **UI** | Se vacía progresivamente | Reemplazada por Capa 1 — Interacción (modalidades conversacionales, GUI on-the-fly, GUI persistente como Botlet de fachada, señalética); la UI tradicional sobrevive solo en herramientas especializadas de superficie compleja | | **API** | Persiste y se intensifica | Se convierte en **Conector** dentro de la Capa 4 — Acceso (NO en Capability) | | **BL · Procedural** | Se contrae | Reemplazada por Botlets. Sobreviven sólo workflows con trazabilidad regulatoria estricta | | **BL · Agentic** | Se expande hasta dominar | **Semilla operativa del Botlet**. La séptima separación se ensancha hasta consumir la capa | | **SOR · Logic** | Se preserva | Lógica de invariantes dentro del AgencyDomain | | **SOR · Persistence** | Se preserva | Capa de almacenamiento del AgencyDomain | | **External · Logic** | Se preserva, se reposiciona | Patrones de federación gestionados por Trust Infrastructure | | **External · Persistence** | Se preserva | Capa de almacenamiento de la federación | | **Eventos (sync/async SOR)** | Se preservan, ganan peso | Sustrato de coordinación entre Botlets y AgencyDomains | **Cuatro patrones generales del cruce**: 1. La **Capa 3 sobrevive casi intacta** — se vuelve sustrato de los AgencyDomains. 2. La **Capa 2 se transforma profundamente** — Procedural se contrae; Agentic domina; ambas se vuelven Botlets que componen comportamiento desde Capabilities. 3. La **Capa 1 se bifurca asimétricamente** — UI muere; API prospera como **Conector** (Capa 4). 4. **Trust Infrastructure aparece como concern transversal nuevo** — lo que en BCA estaba implícito y disperso se eleva a capa transversal explícita. --- ## 4 · La arquitectura — cuatro capas en topología paralela > **Aclaración canónica**: las cuatro capas son una **radiografía del agente individual** — los cuatro comportamientos que todo agente debe exhibir. **NO son eslabones de una cadena de valor industrial** ni slots donde se asigne un producto a cada uno. La cadena industrial se trata en Capítulo 6 — son lentes distintas que se cruzan limpiamente cuando se mantienen separadas. ### La topología paralela **Las Capas 2 (Cognición) y 3 (Autonomía) son vías paralelas entre Capa 1 y Capa 4, no etapas en serie.** La numeración 1 → 2 → 3 → 4 tiene valor didáctico — Capa 1 es la superficie con la que el humano se encuentra, Capa 4 es donde el sistema toca al mundo real — pero **no describe el orden en que las operaciones atraviesan el sistema**. Una operación entra por Capa 1 y llega a Capa 4 atravesando una de las dos vías — o ambas en distintos tramos —, pero nunca ambas en serie obligatoria. ``` ┌──────────────────────────┐ │ Capa 1 · Interacción │ └────┬───────────────────┬─┘ │ │ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ Capa 2 │ │ Capa 3 │ │ Cognición │ │ Autonomía │ │ │ │ │ │ Conversación │ │ Botlets │ │ Decisión nueva │ │ Patrón estable │ │ Caso nuevo │ │ (ciclo 95/4/1) │ └────────┬────────┘ └────────┬────────┘ │ │ ▼ ▼ ┌──────────────────────────┐ │ Capa 4 · Acceso │ │ (Capabilities) │ └──────────────────────────┘ Trust Infrastructure (transversal a las cuatro) Interacción 2 ↔ 3 (interna · vía `MCP`): · Cognición delega a Botlet (2 → 3) · Botlet escala fallback a Cognición (3 → 2) · Cognición observa el log de Botlets (2 ← 3) ``` **Interfaz Capa 2 ↔ Capa 3 vía `MCP`**: la **Cognición** (agente `LLM`, Capa 2) comanda su memoria muscular — el **Botler** (runtime de Capa 3, sin agencia) — por una interfaz **interna** dentro del mismo AgencyDomain. El transporte natural es `MCP`: el Botler expone servidor(es) `MCP`, la Cognición es el cliente. **Esto NO es `A2A`**: `A2A` (la relación agente-a-agente) queda reservado a la comunicación **entre AgencyDomains** distintos. **Régimen de cada vía**: - **Vía Cognición** — lenta, costosa, decisiva. Para conversación, decisiones nuevas, casos no anticipados. - **Vía Autonomía** — rápida, barata, repetitiva. Para ejecución de Botlets sobre patrones estables. **Cinco consecuencias estructurales** de la topología paralela: 1. **Modo offline trivial** — sin red, la vía Cognición (cloud) cae; la vía Autonomía (edge) sigue activa. La operación atraviesa el AgencyDomain por la vía que sigue viva. 2. **Economía cognitiva evidente** — la organización elige por qué vía fluye cada operación: repetitiva → vía 3 (barata); nueva o decisiva → vía 2 (costosa). El costo total es el mix de las dos vías. 3. **Trust Infrastructure se ejerce en ambas vías** — las políticas se aplican antes de invocar Capa 4 sin importar de qué vía viene la invocación. 4. **Distingue dos tipos de Botlets** — **Botlets de fachada operativa** (invocables desde Capa 1, contrato estable, identidad humana propagada) vs **Botlets de herramienta interna** (invocables solo desde Capa 2). Ambos viven en Capa 3; difieren en su superficie de invocación. 5. **`Capa 1 → Capa 3 → Capa 4` es vía canónica** — una superficie operativa (POS, pantalla cocina, panel industrial) que invoca un Botlet senior atraviesa esta vía sin tocar Capa 2. **No es bypass; es una de las dos vías estructurales.** ### Los tres tiempos del agente La topología paralela describe **dónde** vive cada operación. Los tres tiempos describen **cuándo** opera el agente. Marco temporal canónico, complementario al espacial. | Tiempo | Régimen | Métricas | Vía cognitiva | |---|---|---|---| | **Preparación** | Batch · off-peak | Calidad del catálogo · precisión de Botlets · cobertura de Capabilities | Cognición sobre datos consolidados | | **Atención** | Tiempo real · prioritario | Satisfacción · latencia · tasa de resolución sin escalamiento | Cognición + Autonomía según patrón | | **Ingeniería** | Mediano plazo (minutos a horas) | Cobertura · tasa de éxito al primer deploy · iteraciones promedio | Cognición decide · Autonomía persiste | **Implicaciones operativas**: - **Scheduling de capacidad cognitiva**: Atención prioritaria; Preparación aprovecha valles; Ingeniería intermedia. Sin la distinción, la Preparación queda relegada y el agente deja de mejorarse. - **Métricas separadas por tiempo**: un solo dashboard miente; la calidad del catálogo se mide distinto que la satisfacción operativa. - **Modelo de disponibilidad**: un agente bien operado **no está 100% en Atención** — necesita ventanas de Preparación. La promesa "agente siempre disponible" se entiende como "Atención siempre disponible". > *El agente no atiende en todo momento — pero puede atender en cualquier momento porque dedica tiempo a prepararse.* **Propiedades exigidas**: - Reconocimiento explícito de los tres tiempos en la operación (MUST). - Métricas separadas por tiempo (MUST). - Ventanas de Preparación reservadas, no opcionales (SHOULD). - Scheduling de capacidad cognitiva por prioridad de tiempo (SHOULD). - Trazabilidad de qué tiempo ejecutó qué operación en el log (SHOULD). ### Diagrama estructural — todas las capas con topología paralela ``` ┌──────────────────────────────────────────────────────────┐ │ CAPA 1 · INTERACCIÓN │ │ Conversacional puro · GUI on-the-fly · GUI persistente │ │ (Botlets de fachada) · Voz · API · Canales · Señalética │ └────┬─────────────────────────────────────────────────┬───┘ │ │ ▼ ▼ ┌────────────────────────────┐ ┌────────────────────────────┐ │ CAPA 2 · COGNICIÓN │ │ CAPA 3 · AUTONOMÍA │ │ Multi-LLM · Capabilities │ │ Botlets y Agentlets │ │ Pattern Recognition │ ◄── 2 ↔ 3 ──►│ Botler (central + edge) │ │ Generación de Botlets │ │ Tareas asíncronas │ │ Asistente reactivo │ ◄── `MCP` ──►│ Monitoreo · protocolo A2A │ │ Lenta · costosa · nueva │ interno │ Garantía de fallback │ └─────────────┬──────────────┘ └─────────────┬──────────────┘ │ │ ▼ ▼ ┌──────────────────────────────────────────────────────────┐ │ CAPA 4 · ACCESO │ │ Tools (MCP) · A2A entre AgencyDomains · CRUDLEX │ │ Aprobación humana · Append-only log · Routing │ │ Caché semántico · Conectores │ │ (cloud · edge · híbridos) │ └──────────────────────────────────────────────────────────┘ ═══════════════════════════════════════════════════════════════════════ TRUST INFRASTRUCTURE — transversal a las cuatro capas Gobernanza · Auditoría · Validación · Resiliencia · Transparencia PRINCIPIO RECTOR — Agent First ``` ### Capa 1 — Interacción (con tres regímenes de GUI) Responsable de toda comunicación entre humanos y el sistema. Interfaz pura, sin lógica de negocio. **Seis modalidades canónicas** (la **GUI generada** es una sola modalidad con tres regímenes de generación): - **Conversacional textual** — chat directo; el agente responde en texto. Suficiente cuando la información es secuencial y la decisión es flexible. - **Conversacional por voz** — asistentes virtuales, llamadas, audio-bots. - **Canales corporativos** — Slack, Teams, WhatsApp, email. - **API programática** — invocación máquina-a-máquina sin intermediación humana. - **GUI generada** — superficie gráfica generada por la cognición (nunca por un equipo humano de UI/UX), en tres regímenes: **(1) conversacional puro** — sin superficie, cuando no hace falta; **(2) on-the-fly** — adaptada a la tarea inmediata, vive lo que dura la tarea, puede regenerarse distinta la próxima vez; **(3) persistente como Botlet de fachada** — para roles operativos repetitivos (cajero en hora punta, panel de cocina, dashboard de caja, panel industrial), superficie estable consolidada como **Botlet de fachada** — un Botlet de Capa 3 (típicamente seed) que la expone en Capa 1 —, que el agente regenera cuando el ambiente cambia. - **Señalética pasiva** — superficies que comunican continuamente sin requerir interacción. > *La GUI no desaparece en el Mundo Agentivo. Lo que desaparece es la GUI precreada. Toda GUI en una Capa 1 agentiva es generada por la cognición — algunas efímeras, otras estabilizadas como Botlets de fachada.* **Calibración Capa 1**: la pregunta no es si hay GUI o cuán bonita es. La pregunta es **quién la generó**. Si la generó un equipo humano de UI/UX en sprints de aplicación tradicional, no es Capa 1 agentiva. Si la generó la cognición — efímera o persistente como Botlet —, sí lo es. **Tres propiedades exigidas (MUST)**: 1. **Agnóstica al canal** — la lógica de la conversación no depende del medio. 2. **Adaptación al registro** — el agente comprende el registro del canal sin código condicional. 3. **Persistencia de contexto** — la conversación sobrevive al cambio de canal. #### Composición de la superficie · shell, vista, operación Una superficie no trivial **no es un Botlet monolítico**. Es composición de tres tipos de Botlets en roles distintos: | Rol | Capa | Naturaleza | Reutilización | |---|---|---|---| | **Botlet de superficie (shell)** | Capa 1 | Contenedor: layout · navegación · sesión · estado compartido | Específico por producto (poco reutilizable) | | **Botlet de vista** | Capa 1 | Pantalla o panel dentro del shell · ensambla Facetas + orquestación | Altamente reutilizable entre shells | | **Botlet de operación** | Capa 3 | Ejecución de negocio (cobrar, imprimir, cerrar turno, consolidar) | Más reutilizable del catálogo · contrato estable | **Distinción clave**: shell y vista son superficie (Capa 1); operación es ejecución (Capa 3). Una superficie es composición de Botlets de Capa 1 que orquestan e invocan Botlets de Capa 3. ``` Capa 1: SHELL → VISTA(s) ─── invoca ───▶ Capa 3: OPERACIÓN(es) ``` Las operaciones acumulan valor arquitectónico durable; las vistas reutilizables se extraen y catalogan; los shells permanecen específicos pero su construcción se acelera al ensamblar piezas existentes. #### Producto de Información multi-vista · drill-through Un **Producto de Información (`PI`)** — la manifestación que deja un Botlet de operación informativa al consumirse — no es necesariamente una pieza única. Puede componerse de **N piezas/páginas nombradas**: cada **vista** es una pieza más del mismo `PI`, elegible desde un selector, con default la primera. El `PI` sigue siendo **authz-blind** — ni las vistas ni las aristas que las conectan declaran autorización; esa política vive en el policy store. El **drill-through** es la **arista de navegación con contexto**: una tabla/columna declara *"al clickear una fila, ir a la vista X pasando la clave K de esta fila"*; la vista destino se renderiza **filtrada por K**. **Data-anchored / no-bypass (MUST)**: el contexto `K` **acota dentro de lo que el viewer ya puede ver** — la vista destino aplica su propia `RLS` sobre la fuente y `K` entra como filtro adicional, **nunca como override** de la política. El drill **acota, nunca amplía** (intersección con lo autorizado, jamás unión). Si el viewer no alcanza la fila origen, no llega a la arista; si llega, el destino sigue gobernado por su propia política. La composición multi-vista es ortogonal a la familia del Botlet: cambia cuántas piezas componen la manifestación, no su naturaleza. #### Faceta · primitiva atómica de Capa 1 La **Faceta** es el componente atómico reusable de la Capa 1: pizarra de dibujo, catálogo-selector, matriz de colores, calendario, mapa clickeable, slider, drag-and-drop. **Sexta primitiva canónica** — distinta del Botlet (descrita completa en §7). **Faceta NO es un Botlet**: - Faceta vive en Capa 1 (Interacción) · Botlet vive en Capa 3 (Autonomía). - Faceta es **instrumento** que la cognición invoca durante conversación · Botlet es **memoria muscular** que ejecuta sin cognición. - Faceta NO tiene garantía de fallback · Botlet SÍ. - Faceta es efímera · Botlet es persistente. **Comportamiento agentivo**: el agente **estima en tiempo real** si la información se obtiene mejor verbalmente o visualmente. Si la vía visual gana, ofrece Faceta. Heurísticas: alta dimensionalidad → Faceta; baja dimensionalidad → conversación; difícil de verbalizar (color, posición, forma) → Faceta; el usuario ya la tiene en forma visual → Faceta. ### Capa 2 — Cognición El cerebro del agente. Interpretación, razonamiento, planificación, aplicación de saber especializado, decisión de delegar. **Cinco componentes canónicos**: 1. **Multi-LLM** — la cognición no está atada a un proveedor único. 2. **Capabilities** — unidades de saber-hacer cognitivo modular y composable (reservadas a esta capa). 3. **Pattern Recognition** — detección de patrones repetitivos. Inspirado en arquitectura neurobiológica. Activador de la generación de Botlets emergentes. 4. **Generación de Botlets** — la cognición decide cuándo delegar tareas repetitivas a la Capa 3. 5. **Asistente reactivo** — agente operando en modo respuesta-a-solicitud. **`Capability` reservada al saber-hacer cognitivo de Capa 2**: una **Capability** es saber-hacer **cognitivo**, interpretativo, decisional. **NO es plugin, NO es prompt, NO es system prompt, NO es tool — es saber.** La Capability decide qué tool invocar. Dos términos análogos viven en otras capas y se nombran por lo que son, sin apellidar el término Capability: - **Conector** — saber **acceder a sistemas fuente** (conexión con poder de ejecución; NO es saber cognitivo). **Capa 4 · Acceso.** En el mapa legacy→agentivo, una **API** se convierte en **Conector** (Capa 4), no en Capability. - **Plantilla** — confección específica del cliente sobre un **instrumento canónico** (reporte/dashboard) en un formato o regla particular. **Capa 1 · Interacción**, junto a Faceta y Botlets de superficie/vista. **feature** — operación interna que una Capability expone (equivalente práctico de *feature/operation/skill/method*). **Test Capability vs feature** (los tres deben ser sí para tratarla como Capability propia): (1) ¿independencia operativa? (2) ¿identidad cognitiva — modelo de datos y SME distintos? (3) ¿reusabilidad? Si uno o más es no → es **feature** de la Capability contenedora. **Test Capability vs no-Capability** (los tres sí → Capability): (1) ¿es saber-hacer cognitivo? (2) ¿tiene SME identificable? (3) ¿pasa los cinco pasos Wingtraining sin forzar? Si no: acceso a sistemas → **Conector** (Capa 4); confección de instrumento canónico → **Plantilla** (Capa 1); operación dentro de una Capability mayor → **feature**. **Portabilidad de la Capability (MUST)**: una Capability conforme puede instalarse y ejecutarse en **cualquier AgencyDomain conforme** sin reescritura, lo que la vuelve **propiedad real del cliente** — no del AgencyDomain ni del hosting. Relación: un AgencyDomain **aloja y ejecuta** Capabilities; una Capability **corre en** un AgencyDomain anfitrión. Distinta de la portabilidad del AgencyDomain (entre plataformas hosting). **Dos modos de acceso a la cognición**: - **Tokens** — el sistema centraliza credenciales, facturación y políticas. - **Suscripción** — el asistente del usuario (Claude, ChatGPT, Copilot, Gemini) accede directamente bajo la suscripción del usuario. Ambos modos coexisten. La spec exige declarar explícitamente qué modo aplica a qué componente. **Botlets como palanca económica bajo Suscripción fija**: en planes con límite, un agente que ejecuta vía Botlets e invoca cognición solo cuando el ambiente cambia opera continuo sin agotar la cuota. Sin Botlets, la autonomía sostenida bajo Suscripción fija es económicamente imposible. **BYOModel (SHOULD)** — Bring Your Own Model. La spec del agente MUST ser independiente del runtime de cognición. Habilita multi-tenancy con cognición heterogénea y respeta la **soberanía cognitiva** del cliente. ### Capa 3 — Autonomía (con Capa 3 distribuida) Donde el agente vive. Vida persistente, ejecución continua, acción por iniciativa propia. Donde habitan los **Agentes Autónomos**. **Seis componentes canónicos**: - **Procesamiento proactivo**, **tareas asíncronas**, **monitoreo continuo**. - **Lets en ejecución** — dos especies hermanas: **Botlets** (memoria muscular, código no-LLM) y **Agentlets** (juicio de rutina empaquetado, inferencia acotada; §7). - **Botler** — runtime genérico que ejecuta los Lets de ambas especies. Invisible. **1 Proceso = 1 Botler + N Lets**. - **Coordinación intra-AgencyDomain (vía el protocolo `A2A`)** — comunicación entre runtimes del mismo agente. NO es `A2A` entre AgencyDomains. **Propiedad innegociable — Garantía de fallback (MUST)**: si un Botlet falla catastróficamente, la cognición ejecuta la tarea manualmente. **El proceso nunca se detiene.** **Tres propiedades exigidas (MUST)**: 1. **Persistencia entre sesiones**. 2. **Aislamiento de ejecución** — Lets (Botlets y Agentlets) bajo sandboxing. 3. **Resiliencia estructural**. **El Botler es genérico por definición (MUST)**: gestiona ciclo de vida, aislamiento y ejecución de *cualquier* Botlet **sin entender su dominio**. **No existen subtipos de Botler por familia de operación** (informativa, transaccional, etc.) — esa especialización vive en los Botlets y sus proto-Botlets. Los subtipos de Botler se distinguen por **topología y rol de despliegue** (central/edge; fachada operativa), **nunca por dominio**. Arquitectura plana: un runtime genérico hospeda componentes especialistas autocontenidos. **El Botler valida orquestando, no ejecutando (MUST)**: hace valer la validación de la spec contra el tipo de Botlet sin ejecutarla con conocimiento de dominio. Invoca el punto de validación que el tipo (o su proto-Botlet en G1) provee, le entrega el **contexto genérico** que controla (catálogo de Capabilities, identidad, políticas del AgencyDomain) y actúa sobre el veredicto — acepta, rechaza, registra en el append-only log. Patrón hermano: el Botler entrega al Botlet un **handle controlado** (objeto con `capability_call` y `log` ligados al Botler) en cada invocación; el bypass es **estructuralmente imposible**, no solo prohibido. Principio: el Botler genérico expone **puntos de control** y el especialista se enchufa en ellos. **Capa 3 distribuida** (patrón canónico para presencia física múltiple): un mismo AgencyDomain con un **Botler central** (cloud, orquestación, BD consolidada) + **N Botlers edge** (uno por sitio físico, BD local, cola hacia central), coordinados por **el protocolo `A2A`** (coordinación intra-AgencyDomain). Distinto de federación entre AgencyDomains; distinto de Cluster simple. Detalle completo en §7 (Primitivas). ### Capa 4 — Acceso Donde la cognición se convierte en acción real. Toda decisión MUST pasar por gobernanza antes de tocar el mundo. **Ocho componentes canónicos**: - **Servidores de tools** — protocolo canónico **MCP**. - **Conectores** — saber acceder a sistemas fuente (la API legacy traída al Mundo Agentivo). - **`A2A` entre AgencyDomains** — federación entre agentes distintos. - **Trust Infrastructure ejercida en el punto de acción**. - **CRUDLEX** — Create, Read, Update, Delete, List, Execute. - **Aprobación humana**. - **Routing inteligente y caché semántico**. - **Append-only log inmutable**. **Cuatro propiedades MUST en producción enterprise**: 1. **No-repudio** — toda acción registrada con identidad, contexto y resultado. 2. **Reversibilidad cuando aplica**. 3. **Política antes de ejecución** — la política se evalúa **antes**, no después. 4. **Observabilidad uniforme**. --- ## 5 · Trust Infrastructure — el eje transversal **No es una capa adicional. Es transversal a las cuatro.** ### Cinco pilares | Pilar | Mecanismos canónicos | Capas principales | |---|---|---| | **Gobernanza** | Políticas configurables · CRUDLEX · aprobación humana · registro de IA | Capa 4 (principal), transversal | | **Auditoría** | Append-only log · trace de cada acción · lineage de decisiones · identity tagging por acción | Capa 4 (principal), transversal | | **Validación** | Detección de alucinaciones · validación de respuestas · prompt injection prevention · DLP · tokenización | Capa 2 (parcial) + Capa 3 (inferencia acotada de Agentlets) + Capa 4 (principal) | | **Resiliencia** | Garantía de fallback · manejo de errores · sandboxing · circuit breakers · rate limiting | Capa 3 (principal), transversal | | **Transparencia** | Observabilidad completa · métricas · traces end-to-end · alertas proactivas · dashboards de gobernanza | Transversal a las cuatro | ### Matriz pilar × capa ``` Capa 1 Capa 2 Capa 3 Capa 4 Interacción Cognición Autonomía Acceso Gobernanza ████████ (principal) Auditoría ████████ (principal) Validación ████ (parcial) ████████ (principal) Resiliencia ████████ (principal) Transparencia ────────────────────── transversal ────────────────── ``` ### Patrón tripartito de despliegue — Cloud + Cliente + Local Tres componentes coordinados en lugares físicamente distintos: **Cloud** (control plane del proveedor), **Cliente** (governance plane en la red interna del cliente), **Local** (execution plane en el dispositivo del usuario). ### Contrato declarativo de calidad Cualquier Botlet conforme MAY declarar sus atributos de calidad como **propiedades estructuradas, no como código embebido**, para que Trust Infrastructure los audite uniformemente, los curse por políticas globales y los reporte como métricas estándar sin acoplarse a la implementación de cada Botlet. Cinco atributos canónicos: - **Frescura** — antigüedad máxima admisible de los datos. - **SLA** — latencia esperada extremo a extremo (`p50`/`p99`). - **Política de degradación** — `refuse` · `warn_and_show` · `show_last_valid` · `agentic_fallback`. - **Audiencia** — política `RLS`/`CRUDLEX` de quién puede consumir la manifestación. - **Política de refresh** — `on-demand` · `scheduled` · `push`. Sirve a dos pilares: la **Resiliencia** lee degradación y refresh como configuración auditable (no lógica frágil dispersa), con Frescura y SLA como umbrales explícitos; la **Auditoría** los cursa por políticas globales y los reporta como métricas comparables entre Botlets. --- ## 6 · El principio rector — Agent First > *Ante cualquier disyuntiva, se prioriza la experiencia del agente sobre la del humano. El agente es el usuario primario; las necesidades del humano se resuelven en una capa de gestión sin degradar lo que el agente ve y puede hacer.* ### Implicaciones operativas - Cualquier capacidad nueva se especifica primero como **tool con schema declarativo JSON**. - **Errores estructurados y accionables**. - **Idempotencia donde aplica**. - **Paginación y filtros uniformes** entre tools. - **Documentación machine-readable**. Agent First es **regla de gobierno**: cualquier disyuntiva que la viole requiere justificación explícita y documentada. --- ## 7 · Las primitivas ### AgencyDomain Ámbito computacional con identidad propia donde habitan agentes autónomos y Botlets en ejecución, **donde se alojan y ejecutan las Capabilities** que les dan el saber-hacer, y donde viven los recursos que los sostienen. **Unidad mínima de despliegue.** La Capability es habitante de primer orden, no recurso de soporte. **Premisa fundacional — Space ≠ Domain**: - **Space** / **WorkSpace** (Google Workspace, M365, Notion) — corporeidad humana. Reservados para humanos. - **Domain (AgencyDomain)** — el agente no tiene cuerpo; tiene jurisdicción (`dominium`). Linaje formal: como **JavaSpaces (JSR-000148, 1999)** estandarizó los espacios distribuidos para Java sin atar la implementación, **AgencyDomains** hace lo equivalente para entornos agentivos. #### Cinco propiedades fundamentales (MUST — un sistema que no las cumple no es AgencyDomain, es otra cosa con otro nombre) 1. **Identidad propia** — URI canónica única que lo distingue en cualquier red; sobrevive a reinicio, migración entre infraestructuras y cambio de implementación. Estable, no efímera. 2. **Materialización de las cuatro capas** — materializa Interacción · Cognición · Autonomía · Acceso y ejerce Trust Infrastructure transversal. Las capas pueden distribuirse técnicamente, pero la responsabilidad por las cuatro recae en el espacio. No hay conforme que entregue solo tres ni que delegue una capa sin asumir responsabilidad. 3. **Persistencia** — el estado (agentes activos, Botlets en ejecución, datos de Capabilities, logs de auditoría) sobrevive a desconexiones, reinicios y migraciones. Es lo que hace al AgencyDomain **lugar**, no proceso. 4. **Aislamiento** — límite explícito; los recursos internos (cómputo, memoria, datos) no son accesibles desde fuera salvo por interfaces definidas (vía Capa 4, registrada). No es solo seguridad: es **contención de fallos** — un AgencyDomain que cae no afecta a otros que comparten infraestructura. 5. **Direccionabilidad** — AgencyDomain, agentes y Botlets direccionables vía URLs predecibles. Sintaxis canónica: ``` {domain}/ → el espacio mismo {domain}/agents/{agent} → un agente que vive en él {domain}/agents/{agent}/botlets/{botlet} → un Botlet específico {domain}/tools/{tool} → un tool expuesto vía Capa 4 ``` La direccionabilidad sostiene dos cosas: `A2A` (un agente invoca a otro por su URL canónica, sin descubrimiento ad hoc) y **MEO** (los modelos frontera referencian AgencyDomains vía URLs predecibles que aparecen en su corpus de entrenamiento). URLs caóticas o inestables → AgencyDomain invisible para los modelos. #### Modelo de datos canónico — seis componentes del spec Anatomía interna de un AgencyDomain conforme: 1. **Identity** — URI canónica, credenciales con las que se autentica frente a sistemas externos, políticas raíz que ningún agente puede contravenir. 2. **Agents** — colección de agentes del espacio; cada uno con sus Capabilities asignadas, sus Botlets en ejecución y su estado persistente. 3. **Capabilities Registry** — árbol de Capabilities disponibles para los agentes del espacio (saber-hacer compartido, invocable según rol). 4. **Tools Registry** — colección de tools que la Capa 4 expone hacia el exterior (la interfaz por la que el AgencyDomain toca sistemas externos). 5. **Trust Layer** — gobernanza y auditoría transversales: políticas, append-only log, mecanismos de validación. 6. **Cognition Bindings** — bindings al recurso cognitivo: qué proveedor de modelo se invoca, bajo qué credenciales y con qué políticas de uso. #### Tres regímenes (técnicamente equivalentes; cambia el régimen, no la capacidad) ``` Privado = perímetro controlado, sin acceso público (análogo a Private Cloud) Público = accesible desde fuera, agentes registrados (análogo a Public Cloud) Híbrido = core privado + exposición pública parcial (análogo a Hybrid Cloud) ``` **Migración natural entre regímenes sin reescritura.** #### Capa 3 distribuida — patrón canónico para presencia física múltiple Un mismo AgencyDomain con la Capa 3 distribuida geográficamente: un **Botler central** (cloud, orquestación, planificación, reportería, decisiones globales, BD consolidada) + **N Botlers edge** (uno por sitio físico, Botlets transaccionales locales, BD local + cola de eventos hacia central), coordinados por **el protocolo `A2A`** (coordinación intra-AgencyDomain entre runtimes del mismo agente — no es `A2A` entre AgencyDomains). ``` ┌────────────────────────┐ │ Botler CENTRAL │ │ (cloud) │ └────────┬───────────────┘ │ protocolo A2A ┌──────────────┼──────────────┐ ▼ ▼ ▼ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Botler EDGE │ │ Botler EDGE │ │ Botler EDGE │ │ (sitio 1) │ │ (sitio 2) │ │ (sitio N) │ └─────────────┘ └─────────────┘ └─────────────┘ Todo dentro del mismo AgencyDomain (identidad única · log único · gobierno único) ``` **Modo offline como propiedad emergente**: cuando los Botlets edge son **senior**, el sitio físico opera contra la BD local + Conectores edge-resident sin red. La cola de eventos hacia central acumula transacciones; cuando la red vuelve, drena. **Propiedades exigidas**: - Identidad única del AgencyDomain (MUST) - Modelo de identidad interno único (MUST) — los Botlers no se autentican como AgencyDomains externos entre sí; comparten el modelo de identidad del AgencyDomain. - BD local en cada Botler edge (MUST) - Cola de eventos hacia central (MUST) - Resolución de conflictos en consolidación (MUST) - Log de auditoría unificado (MUST) - Régimen Trust uniforme entre central y edge (MUST) - Capacidad de operación offline en edge (SHOULD) — cuando los Botlets edge son senior, el sitio opera con red intermitente o sin red. #### Portabilidad entre plataformas conformes Un AgencyDomain conforme **MUST** poder migrarse a otra **plataforma hosting conforme** sin reescribir su lógica, su estado ni sus políticas. Distinta de la migración entre regímenes (privado → público), que cambia el régimen pero no la plataforma. **Tres condiciones técnicas**: 1. **Botlets contra primitivas canónicas** del SDK conforme, no APIs propietarias del hosting actual. 2. **BD operativa exportable** en formato neutro reproducible (esquema documentado, dump completo, sin tipos propietarios). 3. **Trust Layer portable** — políticas, log y configuración en formato legible por cualquier implementación conforme. Garantiza que el AgencyDomain es **propiedad real del cliente**, no del hosting. #### Cuenta vs AgencyDomain · Domain vs AgencyDomain · Dominion · Cluster vs Federación - **Cuenta** — concepto comercial; puede poseer múltiples AgencyDomains. - **Domain** — sinónimo comercial de AgencyDomain (lore de marca, ventas, comunicación cliente). - **Dominion** — Domain conseguido por agente en AgencyDomain público con modelo de **AgentNation**. - **Cluster** — instancias del **mismo** AgencyDomain compartiendo carga. - **Federación** — comunicación entre AgencyDomains **distintos**. #### Ciclo de vida del agente — seis fases canónicas (cada transición → append-only log del Trust Layer) 1. **Provisioning** — el AgencyDomain crea el agente: asigna identidad, asocia las Capabilities iniciales, lo registra en el espacio. Nace cuando la fase termina con éxito; si falla (credenciales, conflicto de nombre, cuota), nunca llega a existir. 2. **Bootstrap** — entra en operación: carga su estado persistente si existe (recupera contexto tras hibernación o reinicio), establece bindings con cognición y tools, verifica disponibilidad de Capabilities. 3. **Operación reactiva** — modo Asistente, Capa 2 activa. Responde a solicitudes del humano; entre solicitudes queda pasivo (sin cómputo activo). 4. **Operación proactiva** — modo Agente Autónomo, Capa 3 activa. Persigue objetivos en background, monitorea eventos, ejecuta Botlets, escala al humano ante umbrales; Pattern Recognition genera y mantiene Botlets. Materializa *"la inteligencia va hacia las personas y actúa en su nombre"*. 5. **Hibernación** — pausa persistente: estado guardado, sin cómputo activo. Preserva contexto sin gastar recursos (ej.: agente que hiberna fuera de horario hábil y se reactiva al día siguiente). 6. **Decommissioning** — el AgencyDomain retira al agente: estado archivado o eliminado según política, Capabilities liberadas, identidad registrada en el log histórico. Cierra el ciclo formalmente — "decommissioned" ≠ "olvidado": el registro permite reconstruir auditablemente que el agente existió, qué hizo y por qué dejó de existir. #### Comunicación · interfaz Capa 2 ↔ Capa 3 vs `A2A` `A2A` (`agent-to-agent`) es nombre reservado para la **relación entre AgencyDomains distintos** — agentes distintos, cada uno con identidad y agencia; federación, trabajo abierto. - **Interfaz Capa 2 → Capa 3 vía `MCP`** — la Cognición comanda al Botler (su memoria muscular) dentro del mismo AgencyDomain. El Botler expone servidor(es) `MCP`; la Cognición es el cliente. **NO es `A2A`.** - **Coordinación intra-AgencyDomain (vía el protocolo `A2A`)** — el transporte entre Botlers del mismo AgencyDomain usa **el protocolo `A2A`** (nombre propio del protocolo). Se dice "vía el protocolo `A2A`", **nunca "A2A interna"** — esos Botlers son runtimes del mismo agente, no dos agentes. - **`A2A` entre AgencyDomains** — entre agentes que viven en AgencyDomains distintos; exige descubrimiento, autenticación cruzada y resolución semántica. Spec abierta en v1.0. ### Botlet **Unidad de automatización auto-evolutiva.** Código tradicional (no-LLM) generado por un agente. **Memoria muscular.** #### Ciclo canónico 95/4/1 95% ejecución normal, 4% cambio detectado, 1% regeneración. **Garantía de fallback (MUST)**: si el Botlet falla catastróficamente, la cognición ejecuta manualmente. **Botler** — runtime genérico (sin entender dominio) que ejecuta los Lets de la capa: Botlets y Agentlets. **1 Proceso = 1 Botler + N Lets**. #### Madurez del Botlet — junior, en aprendizaje, senior El ciclo `95/4/1` describe el estado estacionario; los Botlets transitan por fases con proporciones distintas: | Fase | Proporción típica | Comportamiento | |---|---|---| | **Junior** | `60 / 35 / 5` | Recién generado. Conoce el ambiente solo en la versión observada al crear. Depende fuertemente de cognición. | | **En aprendizaje** | `85 / 12 / 3` | Pasó por primeras invocaciones, fue regenerado varias veces, incorporó variantes. Opera con red intermitente. | | **Senior** | `99+ / <1 / ~0` | Incorporó las variantes del ambiente. **Sus únicos modos de fallo son exógenos** (energía, hardware, red catastrófica) — no aprendizaje pendiente. **Operable offline confiablemente**. | **Tres implicaciones**: 1. El offline confiable es propiedad de Botlets **senior**, no de Botlets en general. 2. La **garantía de fallback agéntico es lo que produce la madurez**. Cada fallo del Botlet activa la cognición; cada activación regenera incorporando la variante. **Sin fallback agéntico, el Botlet no madura.** 3. La madurez es **trazable** en el append-only log. #### Botlets seed vs Botlets emergentes Dos orígenes canónicos del Botlet: - **Botlet seed** — generado por la cognición a pedido del **equipo de diseño**, como parte del producto inicial. La decisión de existir es del diseño, no de Pattern Recognition. Las **GUIs persistentes generadas como Botlets de fachada** son Botlets de fachada seed — Botlets de Capa 3 cuya superficie estable vive en Capa 1. - **Botlet emergente** — generado por **Pattern Recognition** durante operación, cuando la cognición detecta un patrón repetitivo no anticipado. Ambos viven y operan idénticamente una vez generados. La diferencia está en el origen. Un sistema agentivo productivo **no requiere esperar a Pattern Recognition** para descubrir Botlets críticos — los seed se generan al inicio según la spec del producto. #### proto-Botlet — la pieza pre-forjada Un **proto-Botlet** es una pieza pre-forjada de capacidad operativa que el agente, en su tiempo de **Ingeniería**, **configura** para instanciar un Botlet específico al caso. El proto-Botlet contiene el código; el Botlet es la instancia configurada. Relación genérico → instancia: el proto-Botlet vive en un catálogo y sirve a muchos casos. Se incorpora al elenco de primitivas canónicas. **Dos clases**: | Clase | ¿Qué es su código? | ¿Cómo se configura? | |---|---|---| | **Templado** | Código específico de su función (ej. `cobro-cuenta`, `comanda-impresora-esc-pos`) | Parametrización acotada | | **Platafórmico** | Código genérico (un motor) cuya especialización vive en configuración composicional (ej. `Mira`) | Configuración composicional; cubre N funciones del dominio | Distintas implementaciones mantienen **catálogos de proto-Botlets** — públicos en AgencyDomains.org, privados en códices propietarios. El grado en que el agente configura, co-escribe o genera el código define las **generaciones del Botlet** (§11). #### Cadena de derivación ``` Casos de uso documentados │ cada caso requiere ▼ Botlets necesarios (cero, uno o varios; algunos los resuelve la cognición sin Botlet) │ cada Botlet es instancia de ▼ proto-Botlets requeridos del catálogo ``` Propiedad estructural exigida: todo Botlet conforme **MUST** poder trazarse en esta cadena; el append-only log **MUST** registrar el proto-Botlet de origen de cada Botlet instanciado. El *método* de Discovery no sube al canon; solo la relación estructural y su trazabilidad. **Catálogo común y efectos de red**: los proto-Botlets se acumulan en catálogos compartidos por comunidades de implementadores; cada consumidor contribuye a la maduración (variantes, configuraciones probadas, refinamientos); el implementador n+1 recibe versiones refinadas por los implementadores 1..n. Cuatro modos de pertenencia: **contrato privado** · **códice propietario** · **catálogo público abierto** (AgencyDomains.org) · **acuerdo soberano**. #### Manifestación y temporalidad **Manifestación** — la actualización de la disposición latente del Botlet en el mundo, perceptible o no (potencia → acto). **NO es "aparición"**: un Botlet que dispara una ingestión periódica se manifiesta aunque no deje artefacto visible. Es el género abstracto; cada familia la especializa: **información** → deja un **Producto de Información (`PI`)**; **actuación** → un efecto sobre el mundo; **decisión** → según su práctica. El `PI` **no es primitiva del canon** — vive en la práctica de información, un nivel más concreto. **Temporalidad** — el régimen de la manifestación. Atributo declarado, dos valores: | Temporalidad | ¿Cómo se manifiesta? | Runtime | |---|---|---| | **`discreta`** | En pulsos: despierta por schedule/trigger/evento, actúa, descansa | El Botler invoca o agenda; el Botlet no vive entre pulsos | | **`continua`** | Sostenida: vive persistente | El Botler sostiene la ejecución mientras el Botlet viva | `temporalidad: continua` ⟺ vida persistente de Capa 3 (MUST: runtime persistente que la sostenga). **El "tiempo real" no se elige en un canal de entrega** (`push`); se elige dando al Botlet **temporalidad continua**, lo que obliga al runtime persistente. Conecta con *Empresa en línea ≠ Empresa en tiempo real*: puntos del continuo de temporalidad. Un reporte (snapshot) y un dashboard vivo son la **misma manifestación bajo distinta temporalidad** → un único runtime (se construye el caso continua; los simples son configuraciones degeneradas). #### Código fuente vs spec · dos superficies · un Botlet por `PI` **Código fuente** (abajo) = la implementación; para un proto-Botlet platafórmico = el **motor**, compartido por todos sus Botlets. **Spec** (arriba) = especializa el comportamiento a la instancia; no es el código, lo configura. | Superficie | ¿Qué gestiona? | Granularidad | Cadencia | |---|---|---|---| | **Ciclo de vida del código fuente** | Instalar/versionar/cargar/descargar el motor | Nivel-Botler | Releases (Producto) | | **Operación** (incluye configurar el spec) | Especializar/manifestar/consumir/controlar cada Botlet | Por-Botlet | Fluida (Instancia) | **Configurar el spec es operar**: para un platafórmico el spec es el input operacional. El agente evoluciona el spec **operando** (verbo `specialize`); la **cristalización** a registro versionado **sigue, no precede**; la proveniencia la da el append-log. **Verbos del API de operación**: `specialize` · `invoke`/`schedule` (discreta) · `read`/`subscribe` (continua) · `status`/`activate`/`deactivate`/`retire`. **Un Botlet por `PI`** sobre un motor compartido: cada Producto de Información es su propio Botlet/servicio — con `identity`, temporalidad, madurez y fallback propios —, especializado del motor compartido (proto-Botlet platafórmico). No un Botlet con N configs; no N programas. Es `1 Proceso = 1 Botler + N Botlets` con los Botlets como instancias especializadas del mismo proto-Botlet. Rationale **RISC**: muchos Botlets simples y focalizados componen mejor que un monolito. El consumo `subscribe` es el puente al **norte agentivo** — hoy lo consume un humano (`SSE` en el navegador), mañana la Cognición. ### Agentlet · octava primitiva canónica **Unidad empaquetada de Capa 3, hermana del Botlet, cuyo cuerpo de ejecución invoca inferencia acotada** — un modelo dimensionado a la tarea, dentro de un charter declarado en el spec. Casa canónica de la tarea **recurrente en forma pero interpretativa en cada instancia** (clasificar, triar, resumir, extraer, juzgar): patrón estable, juicio fresco en cada ejecución, sin convergencia posible a determinismo. Instancia de un **proto-Agentlet** (mismas clases templado · platafórmico); hospedado por el Botler; engendrado y mantenido por el agente. > *El Botlet es memoria muscular. El Agentlet es juicio de rutina empaquetado. La Cognición se reserva para lo genuinamente nuevo.* **El género tiene nombre propio — los Lets**: el Botler hospeda **Lets** — Botlets y Agentlets, sus dos especies. El nombre deriva del sufijo `-let` de la familia; vocabulario normado (como Botler), no una novena primitiva; descriptivamente, la unidad empaquetada de Capa 3. El aparato compartido se predica del género (proto-/instancia, catálogos y efectos de red, spec vs código fuente, manifestación, temporalidad, contrato declarativo de calidad, cadena de derivación, append-only log, verbos de operación); las garantías diferenciales, de cada especie. Relación canónica: **1 Proceso = 1 Botler + N Lets**. **Agentlet vs Botlet** (lo diferencial; todo lo demás es idéntico por género): | Eje | **Botlet** | **Agentlet** | |---|---|---| | Cuerpo | Código no-LLM; cero inferencia | Inferencia acotada vía el handle del Botler | | Tarea natural | Recurrente **cristalizable** en código | Recurrente en forma, **interpretativa** en cada instancia | | Determinismo | Converge con la madurez | No converge — corrección estadística por naturaleza | | Costo marginal | ~0 | Tokens por ejecución, presupuestados en el spec | | Madurez | Junior → senior (fallos solo exógenos) | Estabilización del spec + tasa de escalamiento decreciente | | Offline | Senior operable offline | Solo con modelo edge-resident **declarado** (MUST) | | Fallback | La cognición ejecuta manualmente | Escala a la **Cognición plena** | **Regla de contrabando (bidireccional, MUST)**: si hay inferencia en el cuerpo, es Agentlet — un Botlet con `llm_call` escondido es no-conforme. Si no la hay, es Botlet — un Agentlet resoluble con código determinístico se **cristaliza** hacia Botlet. El sistema maduro migra trabajo escalera abajo: Cognición → Agentlets → Botlets. **Agentlet vs Agente — agenda vs charter**: el paraguas **Agente** cubre tres miembros — Asistente · Agente Autónomo · **Agentlet**. **El Agente tiene agenda; el Agentlet tiene charter**: su inferencia se gasta en *cómo* hacer lo suyo, nunca en decidir *qué* es lo suyo. Test de frontera (cualquier «sí» de autonomía → es Agente, no Agentlet): (1) ¿elige sus propias metas o las recibe declaradas en el spec? (2) ¿puede alterar su proceso o engendrar otras unidades? (3) ¿su identidad es de habitante (provisioning) o de instancia (`specialize`)? | Eje | **Agente Autónomo** | **Agentlet** | |---|---|---| | Naturaleza | **Habitante** del AgencyDomain | **Pieza de catálogo** (instancia de un proto) | | Nace por | Provisioning (seis fases) | `specialize` sobre un proto-Agentlet | | Agenda | Persigue objetivos; decide qué hacer | Charter fijo declarado en el spec | | Cognición | Plena (bindings, árbol completo, multi-LLM) | Acotada (modelo dimensionado, Capabilities del spec) | | Engendra | Genera y regenera Botlets y Agentlets | No engendra nada; es mantenido | | Fallback | *Es* el fallback (encima, solo el humano) | Escala a la Cognición vía el Botler | | Gobernanza | Ejerce los cinco pilares (MUST) | Puntos de control del handle del Botler | **El Botler como tutor único (MUST)**: el Agentlet no trae runtime propio. El handle controlado gana un tercer punto de control — **`cognition_call`** — junto a `capability_call` y `log`: la única vía del cuerpo al modelo. Toda su inferencia queda así medida, presupuestada, **validada** (el Pilar 3 gana sede en Capa 3) y auditada en el mismo append-only log. La segregación por perfil de recursos es rol de despliegue (pools), nunca runtime paralelo por especie. Las dos relaciones cubren a las dos especies por igual: el **agente** engendra y mantiene (padre); el **Botler** hospeda y ejecuta (mayordomo). **Economía de los tres peldaños**: Botlet (inferencia cero, costo ~0) · Agentlet (inferencia acotada, presupuestable por Let) · Cognición (plena, para lo nuevo). La vía Autonomía sigue siendo la barata, pero deja de ser uniformemente gratuita: el mix se declara por unidad. Bajo Suscripción fija, los Agentlets consumen cuota — acotada y visible en el log —; su proporción en el mix es decisión económica explícita. **Propiedades exigidas**: charter declarado (tarea, entradas, salidas, límites) (MUST) · inferencia acotada declarada — modelo, Capabilities, presupuesto (MUST) · toda inferencia vía `cognition_call` (MUST) · fallback a Cognición plena (MUST) · cero inferencia fuera del handle (MUST) · hospedaje por el Botler genérico, sin runtime paralelo (MUST) · trazabilidad de cada ejecución e inferencia en el log (MUST) · trazable en la cadena de derivación con proto-Agentlet registrado (MUST) · localidad de la cognición acotada y comportamiento offline declarados (MUST) · Validación del Pilar 3 en el punto de control (MUST) · distinción Agentlet vs Agente Autónomo en API y documentación (MUST) · métricas de madurez propias (SHOULD) · cristalización hacia Botlets (SHOULD) · pool segregado por perfil de recursos (MAY). ### Capability **Unidad de saber-hacer cognitivo especializado** modular y composable. Organizada en árbol jerárquico. **Reservada en sentido estricto a la Capa 2 · Cognición.** **NO es plugin. NO es prompt. NO es system prompt. NO es tool. Es saber.** La Capability **decide qué tool invocar**. Términos análogos en otras capas: **Conector** (saber acceder a sistemas fuente · Capa 4), **Plantilla** (confección de instrumento canónico · Capa 1), **feature** (operación interna de una Capability mayor). **Portabilidad de la Capability (MUST)**: corre en cualquier AgencyDomain conforme; es propiedad real del cliente. **Cuatro reglas del árbol**: cualquier nodo es Capability válida · es escalable (ramas nuevas sin romper existentes) · es heredable (hereda contexto y vocabulario de ancestros) · composable. **Anatomía canónica — nueve componentes**: (1) **identidad** (nombre + posición en el árbol) · (2) **vocabulario** · (3) **conocimiento procedimental** · (4) **conocimiento declarativo** · (5) **heurísticas** · (6) **tools asociadas** (Capa 4) · (7) **Capabilities padres** (herencia) · (8) **estado de madurez** (`Borrador` / `Vigente` / `Deprecado`) · (9) **versión**. Los componentes 2–5 (vocabulario · procedimental · declarativo · heurísticas) son el cuerpo del saber-hacer que distingue una Capability de un prompt elaborado. **Conformidad (MUST/SHOULD/MAY)**: estructura jerárquica en árbol (MUST) · cualquier nodo es Capability válida (MUST) · composabilidad (MUST) · anatomía con vocabulario + procedimental + declarativo + heurísticas (MUST) · versionado explícito (MUST) · **estado de madurez declarado `Borrador`/`Vigente`/`Deprecado` (MUST)** · selección por la cognición, no ejecución directa (MUST) · declaración de localidad y disponibilidad offline del Conector acompañante (MUST) · portabilidad entre AgencyDomains conformes (MUST) · **verticales como raíz dedicada (SHOULD)** · marketplace abierto (MAY). #### Localidad y disponibilidad — clasificación operativa de Conectores La clasificación se predica del **Conector** (el acceso es lo que reside y necesita red; el saber no tiene localidad). Todo Conector conforme MUST declarar su posición en dos ejes ortogonales: **Eje localidad**: - **Cloud-resident** — vive en servicio remoto (DTE-SII, Transbank, API meteorológica). - **Edge-resident** — vive en el sitio físico, asociado a hardware (ESC/POS-Printer, Cash-Drawer, Pinpad-Local). - **Híbrido** — componente local + componente cloud (Cliente-DTE, Cliente-Pinpad-Procesamiento-Diferido). **Eje disponibilidad offline**: - **Online-only** — requiere red para ejecutar. - **Offline-capable** — ejecuta sin red; encola si emite hacia afuera. **Matriz canónica**: | | Online-only | Offline-capable | |---|---|---| | **Cloud-resident** | DTE-SII (sin cliente local) · Transbank Onepay | (típicamente migra a híbrida) | | **Edge-resident** | (combinación inusual) | ESC/POS-Printer · Cash-Drawer · Sensor | | **Híbrido** | (combinación inusual) | Cliente-DTE · Cliente-Pinpad | Regla operativa con Capa 3 distribuida: **un Botlet edge senior, sin red, opera invocando exclusivamente Conectores edge-resident y la parte local de híbridos**. **Propiedades exigidas (localidad/disponibilidad)**: - Declaración explícita de localidad del Conector — cloud-resident / edge-resident / híbrido (MUST). - Declaración explícita de disponibilidad offline — online-only / offline-capable (MUST). - Especificación del comportamiento offline para offline-capable — qué hace sin red, qué encola, cómo drena (MUST). - Resolución determinista del componente que se ejecuta en híbridos — bajo qué condiciones corre el local; bajo cuáles invoca el cloud (MUST). #### La certificación regulatoria reside en el componente certificado, no en el Botlet Para operaciones reguladas (DTE-SII, PCI-DSS, registro sanitario, etc.), **la certificación regulatoria reside en el componente certificado que el Botlet invoca — el Conector certificado, acompañado por la Capability regulada que porta el saber normativo —, no en el Botlet**. La separación se justifica porque el Botlet es **código generado y regenerable**; certificarlo a priori es imposible y certificarlo entre regeneraciones contradice su naturaleza. **Patrón canónico**: el **Botlet orquesta** (conoce el flujo, valida pre-condiciones, captura el evento, formatea la solicitud) y el **Conector certificado ejecuta la operación regulada** (recibe la solicitud, ejecuta bajo norma, devuelve el comprobante); la **Capability regulada** aporta el saber normativo con que la cognición gobierna el par. Uniforme por industria: `Cobrar-Mesa`→`DTE`, `Procesar-Pago`→`Gateway-PCI-DSS`, `Dispensar-Receta`→`Registro-Sanitario`, etc. **Propiedades exigidas (reguladas)**: - Los componentes regulados declaran su régimen regulatorio — qué norma, ante qué regulador, con qué número de certificación (MUST). - Conectores certificados inmutables entre auditorías; cambian solo bajo proceso regulatorio (MUST). - Los Botlets pueden invocar componentes certificados sin restricción — el contrato es estable; se invocan como cualquier otro (MUST). - Auditabilidad de la frontera — el log distingue operaciones del Botlet (lógica de negocio) de operaciones del componente certificado (operación regulada) (MUST). ### Asistente vs Agente Autónomo Distinción crítica que atraviesa Capa 2 y Capa 3. **No es jerárquica**. | Eje | **Asistente** | **Agente Autónomo** | |---|---|---| | Capa | Capa 2 (Cognición) | Capa 3 (Autonomía) | | Modo | Reactivo | Proactivo | | Activación | Espera input del humano | Persigue objetivos sin input continuo | | Estado | Sin estado persistente | Estado persistente | | Botlets | Sin Botlets propios | Mantiene y regenera Botlets | | Vida | Por sesión | Persistente en background | **Se gobiernan distinto**: el Asistente opera bajo control inmediato del humano (validación conversacional, gobernanza liviana); el Agente Autónomo opera sin supervisión inmediata (validación sistémica). **El Agente Autónomo ejerce los cinco pilares de Trust Infrastructure (MUST)** — gobernanza robusta, no solo controles de acceso. El paraguas **Agente** cubre un tercer miembro además de estos dos modos: el **Agentlet** (agente empaquetado de charter acotado; pieza de catálogo, no habitante — ver su sección arriba). Los modos describen cómo opera el agente pleno; el Agentlet es una pieza que el agente pleno engendra y mantiene. ### Faceta · sexta primitiva canónica Componente atómico reusable de la **Capa 1 (Interacción)**: pizarra de dibujo, catálogo-selector, matriz de colores, calendario, mapa clickeable, slider, drag-and-drop, formulario dinámico, lienzo creativo. Una de las muchas caras que la interacción puede tomar. **Faceta vs Botlet — distinción ontológica**: | Eje | **Faceta** | **Botlet** | |---|---|---| | Capa | Capa 1 (Interacción) | Capa 3 (Autonomía) | | Naturaleza | Instrumento de interacción | Memoria muscular del agente | | Cuándo opera | Durante conversación activa | En background, sin cognición presente | | Activación | Cognición la invoca explícitamente | Pattern Recognition o llamado externo | | Garantía de fallback | NO — agente vuelve a conversación | SÍ — cognición ejecuta manualmente | | Ciclo | Sin regeneración | Ciclo `95/4/1` con regeneración | | Persistencia | Efímera (vive lo que dura la tarea) | Persistente entre sesiones | | Madurez | No aplica | Junior · en aprendizaje · senior | | Reutilización | Catálogo plano de instrumentos | Catálogo por capacidad y dominio | > *El Botlet es memoria muscular. La Faceta es instrumento que el agente toma mientras piensa.* **Dos usos canónicos**: 1. **Invocación directa por la cognición** — durante conversación, agente compone superficie efímera con Facetas; usuario interactúa; información vuelve. Realiza el régimen *GUI on-the-fly*. 2. **Composición en Botlets de presentación** — shells y vistas (Botlets de Capa 1) ensamblan Facetas más lógica de orquestación. **Interacción declarada acotada (Faceta embebida)**: una pieza de información ya materializada puede portar interacción sobre sus propios datos sin dejar de ser reproducible. El canon distingue dos interactividades: | ¿Qué las distingue? | **Exploración libre** | **Interacción declarada acotada** | |---|---|---| | Query al origen | sí, arbitraria (drill/pivot ad-hoc) | no — opera sobre el snapshot ya materializado | | Espacio | abierto | declarado (dimensiones y valores acotados) | | Reproducibilidad | se pierde | se mantiene | | Generación | excede `G1` | `G1` (configuración, no código) | | Dónde vive | otro Botlet / cognición | en la pieza misma, vía Faceta | La **exploración libre** sigue **FUERA** del proto-Botlet de información (un Botlet conforme **MUST NOT** absorberla). La **interacción declarada acotada** se realiza vía una **Faceta embebida** acotada a una dimensión declarada de los propios datos: al activarla, los elementos *data-bound* (KPIs como agregaciones declaradas — `sum`, `ratio` —, distribuciones, semáforos) se **recomputan client-side** sobre el subconjunto filtrado, **sin nuevas invocaciones a Capabilities**. Refina (no contradice) la distinción Faceta vs Botlet: la Faceta sigue efímera y sin fallback, pero se reconoce su rol como Faceta embebida dentro de una pieza. **Comportamiento agentivo**: el agente **estima en tiempo real** si la información se obtiene mejor verbalmente o visualmente. Heurísticas: - Baja dimensionalidad + bien estructurada → conversación. - Alta dimensionalidad o difícil de verbalizar (color, posición, forma) → Faceta. - El usuario ya la tiene en forma visual → Faceta. - Comparación entre opciones múltiples → Faceta. - Trabajo creativo abierto → Faceta de canvas. **Anti-heurísticas**: pregunta cerrada y verbal · canal sin capacidad gráfica (voz, IVR, SMS) · costo de cargar Faceta supera el beneficio · interrumpe flujo conversacional. **Anatomía de la Faceta** — seis componentes canónicos: 1. Identidad (nombre canónico + versión). 2. Modalidad de interacción (input/output). 3. Schema de entrada. 4. Schema de salida. 5. Estado interno (selecciones, edits, undo stack). 6. Compatibilidad de canal (web, móvil, kiosk, no soportada en voz). **Catálogo plano**: las Facetas no se jerarquizan; cada una es atómica. Catálogo emergente: `pizarra-dibujo`, `catalogo-selector`, `matriz-colores`, `calendario-rango`, `mapa-clickeable`, `slider-multi`, `dragdrop-orden`, `formulario-dinamico`, `lienzo-creativo`, `selector-archivo`. La spec no cierra el catálogo. **Propiedades exigidas**: - Identidad y versión declaradas (MUST). - Schemas de entrada y salida explícitos (MUST). - Compatibilidad de canal declarada (MUST). - Atomicidad — no compone otras Facetas internamente (MUST). - Distinción explícita Faceta vs Botlet en documentación (MUST). - Invocabilidad directa por la cognición durante conversación (MUST). - Composabilidad dentro de Botlets de shell y vista (MUST). - Preservación de la reproducibilidad de la pieza cuando se compone como Faceta embebida — recómputo client-side, sin invocar Capabilities (MUST). - Interacción declarada acotada compuesta en una pieza materializada — espacio de controles declarado, sin queries nuevas (MAY). - Catálogo público de Facetas disponibles para el AgencyDomain (SHOULD). - Heurísticas de invocación documentadas para la cognición (SHOULD). ### Las tres fases evolutivas del agente 1. **Especializados** — un agente por dominio. Fase actual del mercado (inicios 2026). 2. **Orquestadores** — un agente coordina múltiples especialistas. 3. **Multiespecialistas** — expertise profundo multi-dominio en un único agente. Fase futura. **La arquitectura es la misma en las tres fases.** --- ## 8 · El mercado — cadena de valor de IA Modelo bidimensional: **once eslabones secuenciales × cuatro profundidades**. ### Once eslabones (cobertura) 1. **Datos** · 2. **Modelo** · 3. **Acceso** · 4. **Agentes** · 5. **Especializaciones** · 6. **Runtime** · 7. **Firewall** · 8. **Observabilidad** · 9. **Herramientas** · 10. **Integraciones** · 11. **Entorno** ### Cuatro profundidades - **Wrapper** — consume vía APIs/SDKs de terceros. - **Plataforma** — opera capacidad propia sobre componentes Core. - **Core** — construye la capacidad fundacional con tecnología propia. - **Infraestructura** — provee el sustrato. ### Matriz canónica | Eslabón | 4 · Infraestructura | 3 · Core | 2 · Plataforma | 1 · Wrapper | |---|---|---|---|---| | **1 · Datos** | AWS/GCP/Azure | Scale AI/Labelbox · Hugging Face | — | — | | **2 · Modelo** | NVIDIA · AWS/GCP/Azure | OpenAI · Anthropic · Google · Meta · DeepSeek/Qwen/Ernie | Hugging Face | — | | **3 · Acceso** | — | Anthropic · DeepSeek/Qwen/Ernie | OpenAI · Google · Perplexity · ultraPRO | — | | **4 · Agentes** | — | Perplexity · DeepSeek/Qwen/Ernie · Agentia (priv.) · Soveria (públ.) · (LangChain/Graph) · (AutoGPT/CrewAI) | OpenAI · Anthropic · Google · GitHub Copilot | — | | **5 · Especializaciones** | — | Perplexity · GitHub Copilot · Cursor/Replit · Devin · Harvey/Jasper/Fin · umeeta | OpenAI | — | | **6 · Runtime** | — | OpenAI · Devin · Agentia · Soveria · ultraPRO · (LangChain/Graph) · (AutoGPT/CrewAI) | — | — | | **7 · Firewall** | — | Guardrails/NeMo/Lakera · ultraPRO | — | — | | **8 · Observabilidad** | — | Langfuse/LangSmith/W&B · ultraPRO | — | — | | **9 · Herramientas** | — | OpenAI · Anthropic · Google · Devin · ultraPRO · (LangChain/Graph) · (Pinecone/Weaviate) | — | — | | **10 · Integraciones** | — | Zapier/Make/n8n · ultraPRO | — | — | Derivada de la tabla de actores del Capítulo 6 (familias de productos representativas del mercado actual). Los paréntesis — p. ej. (LangChain/Graph) — indican framework o meta-herramienta (para construir, no para usar). > ultraPRO ocupa la categoría arquitectónica **gateway empresarial completo** — Core simultáneo en eslabones 6-10 más extensión Plataforma en Acceso, bajo el patrón tripartito Cloud + Cliente + Local. > **Eslabón 11 · Entorno**: queda fuera de la matriz — es el territorio sobre el que actúan los eslabones 1-10 (los sistemas empresariales que el agente vuelve backend invisible), no un eslabón que un actor de IA ocupe a una profundidad. ### Cuatro arquetipos estratégicos - **Plataforma integral** — cobertura amplia (3+ eslabones); Core en su eslabón nativo, Plataforma en los adyacentes. - **Especialista vertical** — cobertura focal, profundidad Core. - **Infraestructura de dominio** — cobertura zonal, profundidad Core en varios eslabones. - **Proveedor de sustrato** — cobertura mínima, profundidad Infraestructura. ### Observabilidad (eslabón 8) · seis capacidades canónicas Una implementación completa de Observabilidad para sistemas agentivos cubre seis capacidades distintas: 1. **Tracing** — trazabilidad end-to-end de cada operación (eventos estructurados correlacionados por trace ID). 2. **Monitoreo de costos** — consumo de tokens/recursos en tiempo real por modelo/usuario/proyecto/tool; en sistemas maduros es predicción, no solo registro. 3. **Evaluación de calidad** — verificación sistemática de respuestas; dos sub-modos: automatizada (eval as service) y humana (revisión muestral). 4. **Métricas de rendimiento** — latencia (p50/p95/p99), throughput, disponibilidad, tasa de éxito (distinguida por Botlet/agente/sistema). 5. **Debugging y reproducibilidad** — replay de invocaciones; complejidad agregada por LLM probabilístico, estado persistente y regeneración de Botlets. 6. **Alertas y anomalías** — detección proactiva fuera de patrón; puede disparar circuit breakers, rollback o escalación. > Mercado fragmentado por diseño: una organización madura combina dos o tres productos ("stack de observabilidad"), no una solución monolítica. ### Mundo de carbono · MEO - **Mundo de carbono** — eslabón 11 extendido al mundo físico (IoT, procesos industriales). Patrones: edge computing, twin digital. - **Cuatro sub-categorías del Entorno** (madurez decreciente, regulación creciente): 1. **Sistemas empresariales tradicionales** — ERPs/CRMs/DBMS legacy; digitales pero institucionales; la más madura (integración: Zapier · Make · Workato · MuleSoft, aún mayormente agentic, no autónoma). 2. **Mundo físico industrial** — manufactura y energía (SCADA · MES · PLCs · sensores); mayor valor capturable y más conservadora (regulación de seguridad de planta). 3. **Mundo físico móvil** — transporte, logística, agricultura (flotas, drones, equipos agrícolas); agrega conectividad intermitente y coordinación geográfica; adopción más rápida. 4. **Mundo biológico** — genómica, monitoreo médico, EHR, farmacovigilancia; mayor impacto humano y máxima exigencia de Trust (HIPAA · GDPR salud). - **MEO — Model Engine Optimization** — prácticas para que modelos frontera referencien al actor. Equivalente del SEO en descubrimiento agentivo. --- ## 9 · Aplicación canónica — Conocimiento en tiempo real ``` ┌──────────────────────────────────────────────────────────────────┐ │ KIMBALL BARNIZADA = KIMBALL CLÁSICO + CAPA AGENTIVA │ │ │ │ SOURCE → ETL → PRESENTATION → BI APPS → AGENTE → HUMANO │ │ │ │ ───────────────────────────────────────────────────────── │ │ METADATA + CAPA SEMÁNTICA + TRUST SCORE + AI CERTIFICATION │ │ (transversal — activo estratégico) │ └──────────────────────────────────────────────────────────────────┘ ``` **Componentes esenciales** que distinguen Kimball Barnizada del Kimball clásico: - **Capa semántica explícita**. - **Trust Score por dato**. - **AI Certification**. - **Observabilidad de queries agentivos**. **Mapeo a los hyperscalers** — cada uno implementa Kimball base con su propia terminología; la equivalencia funcional es directa: | Proveedor | Warehouse / ETL | BI App | Gobernanza | Capa unificadora | |---|---|---|---|---| | **Azure** | Synapse Analytics | Power BI | Purview | Fabric | | **AWS** | Redshift | QuickSight | DataZone | Lake Formation | | **Google Cloud** | BigQuery | Looker | Dataplex | — | | **Databricks** | Lakehouse + Medallion | — | Unity Catalog | — | Medallion → Kimball: **Bronze** = Source (crudo) · **Silver** = ETL (limpio/conforme) · **Gold** = Presentation. Ningún hyperscaler tiene aún implementación completa de la **capa agentiva** del Kimball Barnizada. --- ## 10 · Operación ### CRUDLEX Modelo canónico de permisos granulares: **C**reate, **R**ead, **U**pdate, **D**elete, **L**ist, **E**xecute. Aplicable por usuario, agente y contexto. **Niveles preconfigurados** (nivel → CRUDLEX habilitado): | Nivel | CRUDLEX habilitado | |---|---| | **FULL** | `C R U D L E` | | **READ-WRITE** | `C R U D L` (no E) | | **READONLY** | `R L` | | **SAFE** | `R L E` (E limitado a operaciones reversibles) | | **NO-SEND** | `C R U L` (no E) | | **NO-DELETE** | `C R U L E` (no D) | ### Catálogo de políticas — cinco categorías Un sistema agentivo bien diseñado tiene políticas activas en las **cinco**: 1. **Políticas de tools** — qué tools puede invocar el agente, sobre qué recursos (granularidad por agente, tool y scope). 2. **Políticas de datos** — qué clases de datos puede consultar o emitir, según sensibilidad. 3. **Políticas de horarios y umbrales** — cuándo y con qué umbrales de magnitud/riesgo actúa. 4. **Políticas de identidad** — qué identidades operan en nombre del agente y cómo se autentican (identidad federada). 5. **Políticas de validación** — qué validaciones se aplican antes de ejecutar (conectan con el Pilar 3). **Composición jerárquica con monotonía descendente** (MUST): la política del agente hereda las restricciones de las superiores y solo puede **agregar** restricciones, nunca removerlas. Previene escalamientos accidentales de privilegios. ### Append-only log Registro inmutable, encadenado criptográficamente, de toda acción. Componente central de Auditoría. **Contenido mínimo de cada trace**: identidad del agente, capability invocada, tool ejecutado, **hash de parámetros y resultado** (no el contenido crudo — los datos sensibles viven en almacén separado con su propia política de retención), timestamp, contexto, y `previous_log_hash` que encadena con el registro anterior. Propiedad innegociable: el log guarda **hashes, no contenido**. ### Aprobación humana Detiene una operación y solicita autorización antes de ejecutar. Disparada por: **política explícita**, **umbral**, **incertidumbre del agente**. ### Validación canónica (Pilar 3) - Detección de alucinaciones · validación de respuestas estructuradas · prompt injection prevention · DLP · tokenización. ### Continuidad de negocio operacional vs garantía de fallback agéntico Dos mecanismos complementarios: | Mecanismo | Cuándo opera | Qué resuelve | Provisto por | |---|---|---|---| | **Garantía de fallback agéntico** | Botlet junior, en aprendizaje, o senior con variante nueva (cognición disponible) | Cambios de ambiente que el Botlet no anticipó | Spec agentiva (Capa 2 + Capa 3) | | **Continuidad de negocio operacional** | Botlet senior caído por causa exógena, sin cognición disponible | Continuidad cuando ningún componente computacional opera | Protocolo del cliente | La garantía de fallback agéntico **produce la madurez** del Botlet (sin ella, no madura); la continuidad operacional opera sobre Botlets senior caídos por causa exógena y no incide en la madurez. Reconocerlas separadas evita que el cliente atribuya a la arquitectura un fallo que corresponde a su protocolo. ### Modos de degradación del AgencyDomain Cuatro modos canónicos según el escenario de falla. La organización debe poder identificar en cada momento en qué modo opera cada sitio. | Modo | Condición | Quién sostiene la operación | |---|---|---| | **Normal** | Todos los componentes activos | Topología paralela completa | | **Cognición caída** | Capa 2 inalcanzable, edge OK | **Vía Autonomía** sostiene; cognición rescatará al volver | | **Edge offline** | Botler edge sin conexión a central; sitio aislado | **Botlets senior** contra BD local + Conectores edge-resident | | **Continuidad operacional total** | Cognición + edge caídos por causa exógena | **Protocolo manual del sitio** | **Transición automática hasta `Edge offline`** — la arquitectura degrada sola. **Transición a `Continuidad operacional total` es gobernada por el protocolo del sitio** — un humano la activa explícitamente. Diferencia clave: los primeros tres modos son responsabilidad de la arquitectura; el cuarto es responsabilidad del cliente. ### Trazabilidad de la transición — tags canónicos del log - `mode-change: continuity-operational` — cuando el sitio activa protocolo manual. - `provenance: manual-continuity` + `original-timestamp` — registros físicos ingresados retroactivamente. - `provenance: edge-queue-replay` — drenaje de cola edge tras volver la red. - `agentic-fallback` vs `operational-continuity` — distinción auditable entre cognición rescatando y humano sosteniendo. ### Propiedades exigidas (Pilar Resiliencia + Continuidad) | Propiedad | Nivel | |---|---| | Distinción explícita en documentación de producto | MUST | | Protocolo de continuidad operacional documentado por sitio | MUST | | Simulacros con frecuencia mínima trimestral | SHOULD | | Cuatro modos de degradación reconocibles por la organización | MUST | | Trazabilidad de transición a modo continuidad en append-only log | MUST | | Distinción auditable entre fallback agéntico y continuidad operacional | MUST | | Reconciliación retroactiva de registros físicos al sistema | MUST | --- ## 11 · Frontera de evolución Tres horizontes **técnicos** vivos: 1. **Cognición no-LLM** — la Capa 2 admite cognición simbólica, híbrida, multimodal. 2. **Federación (`A2A` entre AgencyDomains)** — protocolos abiertos en evolución. La coordinación intra-AgencyDomain (vía el protocolo `A2A`) ya es madura; la `A2A` *entre* AgencyDomains distintos es trabajo abierto. 3. **Mundo de carbono** — extensión de Capa 4 al mundo físico. El libro humano cuenta **cuatro fronteras vivas**: estos tres horizontes técnicos más una **cuarta frontera institucional** — soberanía y ciudadanía agentiva (**AgentNation**, abajo). ### Generaciones del Botlet — G1/G2/G3 Modelo evolutivo de cómo nace el código del Botlet conforme avanza el estado del arte de la cognición. **La arquitectura es la misma en las tres**; cambia el **alcance de la Ingeniería**. Una implementación puede operar en `G1` hoy y migrar hacia `G3` sin re-arquitectura. - **G1** — el agente configura proto-Botlets pre-forjados del catálogo (no escribe el cuerpo). Si ninguno sirve, especifica uno nuevo para forjar en la próxima Preparación. - **G2** — el agente co-escribe proto-Botlets con asistencia humana o de modelo. - **G3** — el agente genera el código completo del Botlet en tiempo de Ingeniería (escenario asintótico). **G1 admite configuración expresiva rica**: lo que define `G1` es que el agente no escribe el cuerpo del proto-Botlet; la configuración puede ser tan rica como un `DSL` composicional con expresiones formales evaluables. La distinción `G1`/`G3` es sobre **autoría del cuerpo**, no sobre expresividad de la config. **Filo `G1`/`G2`** (test: *"¿el código pertenece a la Capability invocada o al proto-Botlet mismo?"*): una expresión formal evaluable que es **parámetro de una Capability bien definida** (`SQL`→`execute-sql`, una especificación de gráfico→`render-chart`, filtro→`filter-stream`) es configuración → **`G1`**. Una expresión que **extiende/sobreescribe la lógica interna del proto-Botlet** (callbacks, lambdas que evalúa internamente) es código del agente → **`G2`**. **Reconciliación — dos ejes distintos, no la misma flecha**: | Eje | ¿Qué mide? | Dirección de "avance" | |---|---|---| | **Capacidad de autoría** | Cuánto puede forjar: configurar (`G1`) → co-escribir (`G2`) → generar (`G3`) | Hacia `G3`, con el estado del arte de la cognición | | **Madurez operativa** | Para una operación recurrente, cuánto se reutiliza pre-forjado vs se regenera (ciclo `95/4/1`) | Hacia la reutilización (`G1`), conforme el Botlet madura junior → senior | La capacidad `G3` **se gasta mejor produciendo reutilización `G1`**: el destino de `G3` es un catálogo `G1` más rico, no la regeneración en vivo de todo. Para un proto-Botlet **platafórmico**, `G1` es **terminal por diseño**, no estación de paso. El agente más avanzado **genera menos porque ha cristalizado más**, y reserva la generación para el borde (el 4%+1% del ciclo). Paralelo cerebral: corteza = Cognición (Capa 2); cerebelo + ganglios basales = Autonomía (Capa 3). La sofisticación es **estratificarse para que la cognición no tenga que hacerlo todo**. ### AgentNation AgencyDomain en régimen público que adopta el modelo de ciudadanía agentiva. Los agentes son **ciudadanos**, no productos. Distinción ontológica: marketplace lista productos; AgentNation reconoce ciudadanos. Trabajo arquitectónico abierto. --- ## 12 · Glosario canónico (alfabético) ### A - **A2A — Agent-to-Agent** — nombre reservado a la **relación entre AgencyDomains distintos** (agentes distintos; federación). La comunicación dentro de un mismo AgencyDomain **no es "A2A interna"**: es **coordinación intra-AgencyDomain**, y cuando usa ese transporte se dice **vía el protocolo `A2A`**. La interfaz Capa 2 → Capa 3 va por `MCP`, no por `A2A`. - **AgencyDomain** — ámbito computacional con identidad propia donde habitan agentes autónomos y Botlets, **donde se alojan y ejecutan las Capabilities**, y donde viven los recursos que los sostienen. Unidad mínima de despliegue. - **Agente** — término paraguas que cubre tres miembros: el **Asistente** (Capa 2, reactivo), el **Agente Autónomo** (Capa 3, proactivo, habitante) y el **Agentlet** (Capa 3, empaquetado, pieza de catálogo). La distinción no es jerárquica. - **Agentlet** — **octava primitiva canónica**. Unidad empaquetada de Capa 3, hermana del Botlet, cuyo cuerpo invoca **inferencia acotada** dentro de un charter declarado en el spec. Casa de la tarea recurrente en forma pero interpretativa en cada instancia. **El Agente tiene agenda; el Agentlet tiene charter.** Instancia de un proto-Agentlet; hospedado por el Botler (`cognition_call`); fallback a la Cognición plena. Peldaño económico intermedio entre Botlet y Cognición. - **Agente Autónomo** — proactivo, vida persistente, mantiene Botlets. Capa 3. - **Agéntico** — mundo de agentes complementarios. Evolución incremental. - **Agentivo (Mundo Agentivo)** — agentes como interfaz única. Transformación fundamental. - **AgentNation** — AgencyDomain público con modelo de ciudadanía agentiva. - **Agent First** — principio rector: experiencia del agente prima sobre la del humano. - **Append-only log** — registro inmutable, encadenado criptográficamente. - **Aprobación humana** — autorización antes de ejecutar operación crítica. - **Arquetipo estratégico** — patrón de posicionamiento en el espacio cobertura × profundidad de la cadena de valor. Cuatro canónicos: Plataforma integral (cobertura amplia; Core en su eslabón nativo y Plataforma en los adyacentes) · Especialista vertical (cobertura focal, profundidad Core) · Infraestructura de dominio (cobertura zonal, Core en varios eslabones) · Proveedor de sustrato (cobertura mínima, profundidad Infraestructura). - **Arquitectura Agentiva** — diseño técnico que materializa el Mundo Agentivo. Cuatro capas (Interacción, Cognición, Autonomía, Acceso), gobernadas por Trust Infrastructure transversal y ordenadas por el principio Agent First. - **Asistente** — agente reactivo, sin Botlets, sin vida persistente. Capa 2. - **Atención** — uno de los **tres tiempos del agente**. Tiempo en que el agente interactúa con usuarios o eventos en tiempo real. Capa 1 activa, camino crítico, prioritario. - **Auditoría** — Pilar 2 de Trust Infrastructure. Reconstruir después del hecho **qué hizo el agente, cuándo, por qué y sobre qué datos**. Mecanismo central: append-only log; lo completan trace, lineage e identity tagging. ### B - **BCA — Bounded Concerns Architecture** — arquitectura del estado pre-agentivo. - **Botlet** — unidad de automatización auto-evolutiva. Código no-LLM. Memoria muscular. Ciclo `95/4/1`. - **Botlet de fachada** — Botlet de Capa 3 que expone una superficie operativa con contrato estable en Capa 1, identidad humana propagada. - **Botlet de operación** — Botlet de **Capa 3** que ejecuta lógica de negocio invocada desde la Capa 1 (vistas y shells). Más reutilizable del catálogo. Ejemplos: cobrar mesa, imprimir comanda, cerrar turno. - **Botlet de superficie (shell)** — Botlet de **Capa 1** que actúa como contenedor: layout, navegación, sesión, estado compartido. Específico de cada producto. - **Botlet de vista** — Botlet de **Capa 1** que materializa una pantalla o panel dentro de un shell. Ensambla Facetas + lógica de orquestación. Reutilizable entre shells. - **Botlet emergente** — generado por Pattern Recognition cuando detecta patrón repetitivo no anticipado. - **Botlet en aprendizaje** — fase intermedia de madurez. Proporción `85/12/3`. - **Botlet junior** — fase inicial. Proporción `60/35/5`. Depende de cognición. - **Botlet seed** — generado por cognición a pedido del equipo de diseño, como parte del producto inicial. - **Botlet senior** — fase madura. Proporción `99+/<1/~0`. Fallos solo exógenos. Operable offline. - **Botler** — runtime **genérico** de Capa 3 (no entiende dominio) que ejecuta los **Lets** de la capa: Botlets y Agentlets. Tipo (constructo normado de la spec de Botlets), no nombre propio. Sin subtipos por dominio; valida orquestando (handle controlado con `capability_call` · `log` · `cognition_call`); expone servidor `MCP` a la Cognición. **1 Proceso = 1 Botler + N Lets**. - **Botler central** — Botler de orquestación, planificación, reportería en Capa 3 distribuida. - **Botler edge** — Botler de transacciones locales en Capa 3 distribuida. Uno por sitio físico. - **BYOModel** — Bring Your Own Model. Sustitución del proveedor default. SHOULD para mercados regulados. ### C - **Cadena de valor de IA** — modelo bidimensional 11 eslabones × 4 profundidades. - **Capa 1 — Interacción** — interfaz humano-IA con tres regímenes de GUI. - **Capa 2 — Cognición** — cerebro del agente. - **Capa 3 — Autonomía** — vida persistente. Admite distribución geográfica (Capa 3 distribuida). - **Capa 3 distribuida** — patrón canónico para presencia física múltiple. Botler central + N Botlers edge. - **Capa 4 — Acceso** — poder de ejecución con Trust Infrastructure. - **Capability** — saber-hacer **cognitivo** modular y composable, reservado a **Capa 2 · Cognición**. NO plugin, NO prompt, NO tool. **Es saber.** Expone **features**; es **portable** (corre en cualquier AgencyDomain conforme). - **Conector cloud-resident** — vive en servicio remoto. Típicamente online-only. - **Conector edge-resident** — vive en sitio físico, asociado a hardware. Típicamente offline-capable. - **Conector híbrido** — componente local + componente cloud. Offline-capable con encolamiento. - **Conector offline-capable** — ejecuta sin red. Encola si emite hacia afuera. - **Conector online-only** — requiere red. - **Capability regulada** — porta el saber normativo de una operación sujeta a certificación (DTE-SII, PCI-DSS, etc.). La certificación regulatoria reside en el **Conector certificado** que ejecuta la operación, no en la Capability ni en el Botlet. - **Capa semántica** — codifica significado de dimensiones, hechos, jerarquías. Esencial para Kimball Barnizada. - **Cadena de derivación** — relación estructural `casos de uso → Botlets necesarios → proto-Botlets del catálogo`. Todo Botlet conforme MUST poder trazarse en ella; el log registra el proto-Botlet de origen. - **Catálogo común** — los proto-Botlets se acumulan en catálogos compartidos con efectos de red. Modos: contrato privado · códice propietario · catálogo público abierto · acuerdo soberano. - **Cluster** — instancias del mismo AgencyDomain compartiendo carga. - **códice propietario** — catálogo privado de proto-Botlets, Capabilities y patrones que un implementador cura sobre la implementación de referencia pública, refinado por sus casos reales. Uno de los cuatro modos de pertenencia a una comunidad de catálogo. El runtime es común; el códice es propio (encapsula la ventaja competitiva). Instancia canónica: **ucodex** (Grupo Ultra). - **Conector** — saber **acceder a sistemas fuente** (conexión con poder de ejecución; NO saber cognitivo). **Capa 4 · Acceso.** La API legacy traída al Mundo Agentivo se convierte en Conector, no en Capability. - **Conformed dimensions** — concepto de Kimball: dimensiones compartidas entre data marts que garantizan consistencia inter-marts. - **Continuidad de negocio operacional** — protocolos manuales para Botlet senior caído por causa exógena con cognición no disponible. Distinta y complementaria del fallback agéntico. - **Contrato declarativo de calidad** — atributos de calidad de un Botlet declarados como propiedades estructuradas: Frescura · SLA · Política de degradación · Audiencia · Política de refresh. Trust Infrastructure los audita uniformemente. - **coordinación intra-AgencyDomain** — comunicación entre runtimes (Botlers) del **mismo** AgencyDomain. **NO es "A2A interna"**: son runtimes del mismo agente, no agentes distintos. Cuando usa ese transporte se dice **vía el protocolo `A2A`**. Contraconcepto de `A2A` (relación entre AgencyDomains distintos). - **CRUDLEX** — Create, Read, Update, Delete, List, Execute. - **Cuenta** — concepto comercial; puede poseer múltiples AgencyDomains. ### D - **DLP — Data Loss Prevention** — detección de PII no autorizada. - **Domain** — sinónimo comercial de AgencyDomain. - **Dominion** — Domain conseguido por agente en AgencyDomain público con modelo de AgentNation. ### E - **Edge computing** — distribución de Capa 3 cerca del proceso físico. - **Empresa en línea** — datos actualizados al día, depende de humanos para interpretar. - **Empresa en tiempo real** — detecta, interpreta, decide y actúa autónomamente. - **Eslabón** — capa funcional de la cadena de valor (1 a 11). ### F - **Faceta** — **sexta primitiva canónica**. Componente atómico reusable de Capa 1: pizarra, catálogo-selector, calendario, mapa, slider, drag-and-drop. Instrumento que la cognición invoca durante conversación o que los Botlets de presentación ensamblan. **NO es un Botlet** (Capa 1 vs Capa 3 · efímera vs persistente · sin fallback agéntico vs con). - **feature** — operación interna que una Capability expone (equivalente de *feature/operation/skill/method*). Test Capability vs feature: independencia operativa + identidad cognitiva + reusabilidad; si falla uno → es feature de la Capability contenedora. - **Federación** — comunicación entre AgencyDomains distintos. - **Firewall** — eslabón 7. Seguridad, governance, prompt injection prevention. ### G - **Garantía de fallback agéntico** — la cognición ejecuta cuando el Botlet falla. **El proceso nunca se detiene.** **Lo que produce la madurez del Botlet.** - **Generaciones del Botlet — G1/G2/G3** — modelo evolutivo del nacimiento del código del Botlet. **G1**: configura proto-Botlets pre-forjados (no escribe el cuerpo). **G2**: co-escribe el proto-Botlet. **G3**: genera el código completo (asintótico). Cambia el alcance de la Ingeniería, no la arquitectura. La capacidad G3 se gasta mejor produciendo reutilización G1; para un platafórmico, G1 es terminal por diseño. - **Gateway empresarial de IA** — Core en Runtime+Firewall+Observabilidad+Herramientas+Integraciones. - **Gobernanza** — Pilar 1 de Trust Infrastructure. - **GUI on-the-fly** — Régimen 2 de Capa 1. Superficie gráfica adaptada a la tarea, vive lo que dura la tarea. - **GUI persistente como Botlet de fachada** — Régimen 3 de Capa 1. Superficie estable de un Botlet de fachada (Capa 3, típicamente seed) para roles operativos repetitivos. ### H - **Hallucination (alucinación)** — afirmación factualmente incorrecta. Detección en Pilar Validación. - **Híbrido (régimen)** — AgencyDomain con core privado + exposición pública parcial. ### I - **Ingeniería** — uno de los **tres tiempos del agente**. Puente entre Preparación y Atención: convierte capacidad latente en capacidad ejecutable para un caso concreto. Configura Botlets seed, valida deploy. Mediano plazo (minutos a horas). - **Instrumento de información** — el **tipo** canónico de la familia de información (la clase: reporte / dashboard). Distinto del **Producto de Información**, que es su instancia manifestada. - **Interacción declarada acotada** — interacción que opera sobre el **snapshot ya materializado** de una pieza, en un espacio **declarado**, que **mantiene reproducibilidad** y es **`G1`** (configuración, no código). Vive en la pieza misma vía **Faceta embebida** (recómputo client-side, sin invocar Capabilities). Distinta de la **exploración libre** (query arbitraria al origen, excede `G1`). ### J - **JSR — Java Specification Request** — formato canónico de especificaciones de Java (Sun Microsystems / Oracle). **JavaSpaces (JSR-000148, 1999)** es el análogo conceptual de AgencyDomains. ### K - **Kimball / Kimball Barnizada** — modelado dimensional + capa agentiva. ### L - **LLM** — Large Language Model. - **Let (plural: Lets)** — **nombre propio del género** de las piezas empaquetadas que el Botler hospeda y ejecuta; vocabulario normado (como Botler), no primitiva. Descriptivamente: la unidad empaquetada de Capa 3. Dos especies: **Botlet** (código no-LLM) y **Agentlet** (inferencia acotada). El aparato compartido se predica del género; las garantías diferenciales, de cada especie. Invariante ES/EN. Relación canónica: **1 Proceso = 1 Botler + N Lets**. - **Línea Nadella** — umbral entre Mundo Agéntico y Mundo Agentivo. *¿El humano abre aplicaciones para hacer su trabajo?* (formulación canónica; *La Empresa en Tiempo Real* la conjuga en segunda persona y *AURA* en la voz del directivo — las tres son equivalentes oficiales). ### M - **manifestación** — actualización de la disposición latente del Botlet en el mundo, perceptible o no (potencia → acto). NO es "aparición". Género abstracto: información → deja un `PI`; actuación → efecto sobre el mundo; decisión → según su práctica. - **MCP — Model Context Protocol** — protocolo abierto canónico para tools de Capa 4 y para la interfaz interna Capa 2 → Capa 3 (Cognición cliente, Botler servidor). Anthropic, noviembre 2024. - **MEO — Model Engine Optimization** — equivalente del SEO en descubrimiento agentivo. - **Memoria muscular** — metáfora canónica del Botlet. - **Meta-Cognitive Platform** — categoría de plataforma que administra la **economía de la cognición** (G1 músculo pre-forjado vs fallback de cognición fresca, ciclo `95/4/1`, maduración junior→senior, cristalización). **Vergis** es la implementación de referencia. **NO se abrevia a "MCP"** (sigla tomada por Model Context Protocol). - **Mira** — nombre propio de un proto-Botlet **platafórmico** de operación informativa del catálogo de la implementación de referencia. - **Modos de degradación del AgencyDomain** — Normal · Cognición caída · Edge offline · Continuidad operacional total. Las primeras tres transiciones son automáticas; la cuarta requiere activación humana por protocolo. - **Mundo de carbono** — eslabón 11 extendido al mundo físico. ### O - **Observabilidad** — eslabón 8 de la cadena de valor: la capa que **observa, mide y retroalimenta** el sistema de IA en producción. Su pregunta: *¿cómo funciona?* Sin ella, los agentes son cajas negras. ### P - **Pattern Recognition** — detección de patrones repetitivos. Activa generación de Botlets emergentes. - **Patrón tripartito Cloud + Cliente + Local** — patrón canónico de despliegue de Trust Infrastructure enterprise. - **Plantilla** — confección específica del cliente sobre un **instrumento canónico** (reporte/dashboard) en un formato o regla propios. **Capa 1 · Interacción.** NO es Capability ni Conector. - **Portabilidad de la Capability** — una Capability conforme corre en cualquier AgencyDomain conforme; la vuelve propiedad real del cliente. Distinta de la portabilidad del AgencyDomain. - **Portabilidad del AgencyDomain** — propiedad estructural: AgencyDomain conforme migrable a otra plataforma conforme sin reescritura. Tres condiciones: Botlets contra primitivas canónicas, BD exportable, Trust Layer portable. - **Preparación** — uno de los **tres tiempos del agente**. *Mise en place* — el agente refina catálogo, mejora capacidades, fuera de ventana de servicio. Régimen batch / off-peak. - **Privado (régimen)** — AgencyDomain en perímetro controlado. Sin acceso público. - **Producto de Información (`PI`)** — instancia manifestada/entregada de la familia de información (la manifestación concreta de un Instrumento de información). Cada `PI` es su propio Botlet/servicio especializado de un motor compartido (proto-Botlet platafórmico). **NO es primitiva del canon** — vive en la práctica de información. - **Profundidad** — dimensión vertical: Wrapper / Plataforma / Core / Infraestructura. - **Prompt injection** — manipulación vía inputs maliciosos. - **proto-Agentlet** — pieza pre-forjada de capacidad interpretativa que el agente **configura** en su tiempo de Ingeniería para instanciar un Agentlet. Contiene el cuerpo (estructura del charter, esqueleto del prompt operativo, contratos de entrada/salida, umbrales de escalamiento); el Agentlet es la instancia configurada. Mismas clases (templado · platafórmico), misma cadena de derivación y mismos catálogos que el proto-Botlet. - **proto-Botlet** — **séptima primitiva canónica**. Pieza pre-forjada de capacidad operativa que el agente **configura** en su tiempo de Ingeniería para instanciar un Botlet. El proto-Botlet contiene el código; el Botlet es la instancia configurada. Dos clases: **templado** (código específico; parametrización acotada) · **platafórmico** (motor genérico; configuración composicional; cubre N funciones). Catálogos públicos (AgencyDomains.org) o privados (códices propietarios). - **Público (régimen)** — AgencyDomain accesible públicamente. ### R - **RAG — Retrieval-Augmented Generation**. - **Régimen** — modo de despliegue de AgencyDomain según frontera de acceso. **Estructura técnica equivalente; cambia el régimen, no la capacidad.** - **Resiliencia** — Pilar 4 de Trust Infrastructure. - **Runtime** — eslabón 6. Ambiente operativo del agente. Corresponde a Capa 3. ### S - **Salto Cuántico** — umbral habilitado por el colapso del costo de la pregunta analítica: cuando preguntarle a los datos deja de ser caro, lento o mediado por un humano, la organización cruza de **empresa en línea** a **empresa en tiempo real**. Cambio de régimen operativo, no mejora incremental de BI. - **Sandbox** — aislamiento de ejecución de Botlets. Cuatro estrategias: procesos+seccomp, contenedores, WASM, MicroVMs. - **Señalética** — dashboards pasivos sin requerir interacción. - **SME — subject-matter expert** — experto humano cuyo saber se transfiere al agente en la construcción de Capabilities. Workshop inicial y validación ALFA del Wingtraining. - **Space / WorkSpace** — habitat humano. Reservado para humanos. ### T - **temporalidad** — régimen de la manifestación del Botlet. Atributo declarado: **`discreta`** (pulsos: schedule/trigger/evento) y **`continua`** (vida persistente; obliga al runtime persistente de Capa 3). El "tiempo real" se elige dando temporalidad continua, no marcando un canal `push`. - **Tokenización** — reemplazo de datos sensibles por tokens antes de la cognición. - **Tool** — herramienta invocable. Eslabón 9. Protocolo canónico: MCP. **NO es Capability.** - **Topología paralela** — modelo canónico de las cuatro capas. Capas 2 y 3 son **vías paralelas** entre Capa 1 y Capa 4, no etapas en serie. - **Trace** — trazabilidad end-to-end. - **Transparencia** — Pilar 5 de Trust Infrastructure. Entender en tiempo real **qué está haciendo el agente y por qué**, con detalle para intervenir. Conecta los otros cuatro pilares. - **Tres tiempos del agente** — marco temporal canónico: **Preparación** (mise en place, batch / off-peak), **Atención** (camino crítico, tiempo real), **Ingeniería** (puente, mediano plazo). La topología paralela describe DÓNDE; los tres tiempos describen CUÁNDO. - **Trust Infrastructure** — cinco pilares: Gobernanza, Auditoría, Validación, Resiliencia, Transparencia. - **Twin digital** — gemelo digital. Patrón para mundo de carbono. ### U - **ucodex** — nombre propio del **códice propietario** del Grupo Ultra: su catálogo privado de proto-Botlets, Capabilities y patrones, curado por casos reales sobre la implementación de referencia (Vergis). Instancia que ejemplifica el modo *códice propietario*; mismo cajón de nombres propios que Soveria, Agentia, ultraPRO — no un tipo del canon. ### V - **Validación** — Pilar 3 de Trust Infrastructure. - **Vergis** — nombre propio de la implementación de referencia pública de AgencyDomains (la plataforma; el AgencyDomain hecho operativo). Categoría: **Meta-Cognitive Platform**. Distribuida **AGPL**, repo público, **AgencyDomains.org**. Nombre propio de instancia (como Soveria, Agentia, ultraPRO), no un tipo como Botler. - **Vía Autonomía** — una de las dos vías de la topología paralela. Rápida, barata, repetitiva. Para Botlets sobre patrones estables. - **Vía Cognición** — una de las dos vías de la topología paralela. Lenta, costosa, decisiva. Para conversación, decisiones nuevas, casos no anticipados. ### W - **Wingtraining** — esquema canónico de desarrollo de una Capability en cinco pasos: workshop con el SME · creación · personalización · ALFA · BETA. - **Wingworking** — práctica colaborativa humano-IA. Marco metodológico bajo el cual el libro fue producido. - **WorkSpace** — ver Space. - **Wrapper / Plataforma / Core / Infraestructura** — las cuatro profundidades canónicas. --- ## 13 · Implementaciones de referencia La arquitectura es **agnóstica a productos**. Admite múltiples implementaciones cooperantes. **Aclaración canónica**: las cuatro capas son radiografía del agente individual. **No son slots donde se asigne un producto a cada uno.** **Nota de alcance del canon**: este canon contiene la estructura y el vocabulario del Mundo Agentivo — definiciones, primitivas, propiedades exigidas, separaciones canónicas. **No contiene métodos para implementar ni catálogos operacionales**: esos viven en cuerpos complementarios. La implementación de referencia pública es **AgencyDomains.org**, materializada en **Vergis**. ### Vergis — implementación de referencia pública **Vergis** es la implementación de referencia pública de AgencyDomains — el AgencyDomain hecho operativo. Distribuida bajo **`AGPL`** (código) y **`GFDL`** (docs), repositorio público en **AgencyDomains.org**, diseñada para descargarse, leerse, ejecutarse y aprender cómo el canon se traduce en sistemas vivos. Su desarrollo completo es el **Capítulo 9** del libro. **Esquema de nombres — tipo vs nombre propio**: | Capa | Tipo / categoría | Nombre propio | |---|---|---| | Plataforma · *Meta-Cognitive Platform* | implementación de referencia de AgencyDomains | **Vergis** | | Runtime de Capa 3 | **Botler** (constructo normado de la spec de Botlets, genérico) | — (sin nombre propio) | | Componente del catálogo | proto-Botlet platafórmico de operación informativa | **Mira** | - **Botler** es un **tipo** (constructo normado de la spec de Botlets — no una de las ocho primitivas). Cualquier runtime de Capa 3 conforme *es un* Botler. - **Vergis** y **Mira** son **nombres propios** de instancias (mismo cajón que Soveria, Agentia, ultraPRO). - Categoría de Vergis: **Meta-Cognitive Platform** — administra la **economía de la cognición** (G1 músculo pre-forjado vs fallback de cognición fresca, ciclo `95/4/1`, maduración junior→senior, cristalización). **NO se abrevia a "MCP"** — esa sigla nombra el Model Context Protocol. El descriptor se usa deletreado. **Qué incluye**: contrato abstracto del **Botler** (genérico, con puntos de control `capability_call`/`log` y validación por delegación) · **Mira** (proto-Botlet platafórmico operando en `G1`) · conjunto starter de **Capabilities** y **Conectores** · plantillas de Trust Infrastructure (políticas, append-only log, contrato declarativo de calidad) · ejemplos ejecutables que recorren la cadena `caso de uso → Botlets → proto-Botlets`. **Production grade**: es el **mismo runtime** que opera los productos comerciales (Agentia · Soveria · ultraPRO). La diferencia con esos productos **no es la calidad del código sino el catálogo**: los productos consumen la referencia pública **más un códice propietario** (ucodex es un ejemplar) que cura proto-Botlets, Capabilities y patrones refinados por casos reales. **Modelo de adopción** (replicable sin permiso ni contrato central): (1) **consume** la referencia pública; (2) **cura** su propio códice; (3) **ofrece** sus productos sobre esa base. AgencyDomains.org no es propiedad de un actor: es base común. **Catálogo común y efectos de red**: los proto-Botlets se acumulan en catálogos compartidos; cada consumidor contribuye a la maduración y el implementador n+1 recibe versiones refinadas por los implementadores 1..n. Cuatro modos de pertenencia: **contrato privado** · **códice propietario** · **catálogo público abierto** (AgencyDomains.org) · **acuerdo soberano**. El runtime es común; la curaduría es de cada quien.