Del cuello de botella de la fundadora al delegado de la propietaria: cómo escalar una empresa nativa de IA más allá de la atención de su propietaria

15 Conceptos y dos rutas de laboratorio. El "medio día" en el título es la ruta simulada: alrededor de 2 a 3 horas de lectura conceptual más 2 a 3 horas de laboratorio simulado con endpoints mock. La ruta de implementación completa es un taller independiente de 1 día a 2 días: alrededor de 3 horas de lectura más de 6 a 10 horas de laboratorio práctico. La ruta completa no modifica el código base de Paperclip; registra tu Identic AI como agente de Paperclip, crea la capa de firma y verificación en tu propia skill de integración y ejercita el recorrido criptográfico completo de ida y vuelta contra rutas de aprobación reales de Paperclip. Elige la ruta antes de la Decisión 1; consulta la Parte 4 para obtener más detalles.

Un curso intensivo de continuación. Este es el Curso Ocho de nueve en la ruta de codificación agéntica y es la operacionalización profunda de Invariante 2 de la tesis de Agent Factory: cada humano necesita un delegado. Los Cursos Cinco, Seis y Siete te enseñaron a construir, gobernar y hacer crecer los Workers contratados de una empresa nativa de IA. Lo que esos tres cursos dejaron sin resolver es qué sucede cuando la fuerza laboral crece lo suficiente como para que la propietaria humana ya no pueda leer cada hilo de aprobación. El Curso Ocho nombra esto como el último cuello de botella de la arquitectura y enseña el patrón de delegación de confianza que lo elimina. El delegado de la propietaria (su Identic AI, término de Don Tapscott para una IA personal que lleva la identidad, las preferencias y la autoridad de la usuaria) toma el tráfico de gobernanza de rutina en su nombre, aplica su juicio y presenta solo las decisiones que realmente la necesitan.

La idea que hace que todo lo demás encaje: una empresa nativa de IA deja de escalar por la atención de la propietaria, no por la API de contratación; la Owner Identic AI es la primitiva que elimina a la propietaria como cuello de botella sin quitarle el control. Los cursos cinco a siete te permiten contratar mil Workers. Nada en esos cursos impide que la propietaria se ahogue en hilos de aprobación cuando lo hace. Cada Concepto del Curso Ocho amplía lo que el delegado decide de forma autónoma o afina el punto en que una decisión debe volver al ser humano. Ambos son la arquitectura.

Por qué esto es importante para Agent Factory: Invariante 2 en su totalidad

La tesis de Agent Factory menciona siete reglas estructurales que debe obedecer una empresa nativa de IA. La invariante 2 dice que cada humano necesita un agente personal de IA, un "delegado", que mantenga su contexto, su juicio y su autoridad en su nombre. Aquí está la frase marco del arquitecto, en torno a la cual se construye todo este curso:

"Una fundadora puede contratar diez Workers y leer cada aprobación; una fundadora no puede contratar mil Workers y leer cada aprobación. Sin una Identic AI que actúe en nombre de la propietaria, aplicando el juicio conocido de la propietaria a las decisiones rutinarias y presentando a la propietaria solo las que no son rutinarias, cada invariante anterior de la empresa nativa de IA queda limitado por la atención de la propietaria. La Identic AI de la propietaria no es una herramienta de productividad. Es la única respuesta arquitectónica a la pregunta de cómo una empresa nativa de IA escala más allá de su fundadora."

La tesis especifica OpenClaw como el delegado que envía. Este curso enseña cómo configurar OpenClaw para un uso específico del delegado: como delegado de gobernanza de la propietaria de la empresa, el agente que posee la envolvente de autoridad de la propietaria y gestiona el tráfico de aprobación en su nombre. El curso amplía la tesis sin contradecirla: la tesis define al delegado; el curso enseña lo que el delegado tiene que hacer, criptográfica y operativamente, para absorber de forma segura el tráfico de aprobación de una fuerza laboral.

Los cursos tres a siete operacionalizaron otras invariantes en profundidad:

• El Curso Tres cubrió el Invariante 4 (elección del motor, el tiempo de ejecución en el que se ejecuta cada agente)
• El Curso Cuatro cubrió el Invariante 5 (sistema de registro vía MCP)
• El Curso Cinco cubrió el Invariante 7 (el sistema nervioso con Inngest)
• El Curso Seis cubrió el Invariante 3 (la capa de gestión con Paperclip)
• El Curso Siete cubrió el Invariante 6 (contratación como capacidad exigible). El Curso Ocho completa el Invariante 2 con la misma profundidad. Luego, el Curso Nueve agrega la disciplina transversal, el desarrollo impulsado por la evaluación, que convierte a cada Worker, cada contratación y cada decisión delegada en algo medible y digno de confianza en la producción.

Sobre la elección de plataforma

Los cursos cinco a siete te enseñaron a usar Paperclip como capa de administración, Inngest como envolvente operativa y Claude Managed Agents como tiempo de ejecución de ejemplo trabajado para Workers contratados. El Curso Ocho presenta OpenClaw (openclaw.ai, github.com/openclaw/openclaw, docs.openclaw.ai) como tiempo de ejecución para el delegado de la propietaria, el mismo OpenClaw que la tesis de Agent Factory nombra en el Invariante 2.

OpenClaw es un asistente personal de inteligencia artificial de código abierto que se ejecuta en la máquina local del usuario (Mac, Windows o Linux), al que se puede acceder a través de apps de mensajería que el usuario ya usa y se basa en la memoria persistente, la soberanía de los datos del usuario y la extensibilidad de habilidades. Expone más de 50 integraciones, incluidos más de 15 canales de chat (WhatsApp, Telegram, Discord, Slack, Signal, iMessage y más). El concepto 4 explica qué es realmente OpenClaw, por qué la tesis lo incluye como delegado y qué alternativas serían si quisiera cambiar el tiempo de ejecución.

La primitiva de gobernanza delegada que enseña el Curso Ocho, es decir, cómo la Identic AI de una propietaria firma solicitudes a la fuerza laboral de Paperclip de la empresa, no es una integración incluida entre OpenClaw y Paperclip. Es un patrón arquitectónico. El Curso Ocho te enseña a ensamblarlo con el sistema de skills de OpenClaw y las primitivas de identidad verificada de Paperclip. Ambos productos envían los bloques básicos; el curso los conecta.

Asperezas conocidas en mayo de 2026 (no te sorprendas cuando las encuentre)

• OpenClaw se mueve rápidamente. El proyecto es de código abierto bajo una licencia MIT, lo que es una verdadera garantía de continuidad, pero sigue agregando habilidades, integraciones y primitivos semanalmente y su posición institucional ha cambiado más de una vez en sus primeros seis meses. El curso se imparte en la superficie estable de openclaw.ai y docs.openclaw.ai a partir de mayo de 2026; las fechas específicas, los números de versión y los recuentos de integración deben verificarse con el sitio oficial antes de ser considerados autorizados. Trata todo lo que no esté en esas URL como si estuviera en movimiento.
• El ciclo de juicio-aprendizaje de la propietaria, cómo la Identic AI aprende los valores de la propietaria a partir de sus decisiones de aprobación pasadas, está en la frontera de lo que se ofrece hoy. El Curso Ocho enseña los compromisos arquitectónicos y los patrones prácticos que funcionan en mayo de 2026 y nombra explícitamente qué partes siguen abiertas a la investigación (Conceptos 13 a 15).

TL;DR (lee esto primero si tienes 60 segundos)

Las cuatro afirmaciones en orden:

1. Una empresa nativa de IA deja de escalar por la atención de la propietaria, no ante la API de contratación. Los cursos cinco a siete te permiten contratar mil Workers; nada en esos cursos impide que la propietaria se ahogue en hilos de aprobación cuando lo hace.
2. La respuesta arquitectónica es darle a la propietaria una Identic AI, una IA delegada personal que viva en el hardware de la propietaria, conozca sus patrones de juicio y actúe en su nombre en las decisiones rutinarias mientras presenta las más importantes.
3. OpenClaw es el tiempo de ejecución creíble enviado para esto en mayo de 2026. Es de código abierto, propiedad del usuario, accesible a través de las apps de mensajería existentes de la propietaria y construido alrededor de la memoria persistente del usuario. El curso enseña cómo configurarlo como delegado de gobierno, no como asistente de propósito general.
4. La primitiva de delegación de confianza, el patrón arquitectónico que permite que la propietaria humana y la Identic AI de la propietaria actúen con autoridad sin dejar de ser distinguibles en el registro de auditoría, es el movimiento técnico central que enseña el Curso Ocho. Es lo que hace que la gobernanza delegada sea segura y no imprudente.

La versión en lenguaje sencillo, si algo de esto te perdió

En el Curso Siete, construimos una pequeña empresa de inteligencia artificial que podía contratar a un cuarto Worker de inteligencia artificial (el especialista legal) con la aprobación de la propietaria humana. Eso funciona cuando la empresa tiene cuatro Workers. Cuando la empresa tiene cuatrocientos Workers, la propietaria humana ya no puede leer todas las aprobaciones; estaría leyendo aprobaciones todo el día. Este curso le enseña a la propietaria cómo tener su propio asistente personal de IA, utilizando una herramienta de código abierto llamada OpenClaw que se ejecuta en su portátil. Ese asistente lee las aprobaciones en su nombre, toma decisiones fáciles usando patrones que ha aprendido de sus decisiones pasadas y solo la despierta cuando algo realmente necesita su juicio. El curso también enseña al sistema de gestión de la empresa cómo distinguir entre la propia propietaria haciendo clic en "aprobar" y la IA personal de la propietaria haciendo clic en "aprobar" en su nombre, porque ambas están autorizadas, pero el registro de auditoría debe distinguirlas.

La recompensa arquitectónica: la atención de la propietaria ahora se dedica solo a decisiones que realmente se benefician del juicio humano.

Resumen de los cursos cinco a siete: dónde quedaron las cosas (haz clic para ampliar)

Si acabas de terminar el Curso Siete, léelo y continúa. Si estás entendiendo esto en frío o ha pasado un tiempo, las cuatro piezas de contexto a continuación son fundamentales para el resto del Curso Ocho.

Del Curso Cinco (la envolvente operativa): los Workers de la empresa se ejecutan dentro del contenedor de ejecución duradera de Inngest, que les proporciona ejecuciones seguras, reintentos en caso de error, registro estructurado en dos tablas específicas (activity_log y cost_events) y la primitiva de pausa duradera step.wait_for_event. Esa primitiva Inngest permite a un Worker hacer una pausa durante horas o días sin consumir cómputo durante la espera. Las aprobaciones de Paperclip, introducidas en el Curso Seis, son un mecanismo separado: una aprobación es un registro de decisión, no un Worker en pausa. Aprobar uno no reanuda nada automáticamente; continuar el trabajo es el siguiente paso explícito. Lo que cambia el Curso Ocho es la decisión de gobernanza: la aprobación de rutina que solía esperar la atención de la propietaria ahora la atiende primero la Identic AI de la propietaria y solo las importantes llegan a la propia propietaria.

Del Curso Seis (el plano de gestión): la empresa se ejecuta en Paperclip, una capa de gestión de código abierto (docs.paperclip.ing). Proporciona a la fuerza laboral un organigrama, envolventes de autoridad (reglas que delimitan lo que cada Worker puede hacer), puertas de aprobación (los reembolsos superiores a $500 requieren aprobación humana) y un sistema de registro compartido. Los Workers en el ejemplo trabajado son Soporte de Nivel 1, Especialista de Nivel 2 y Gerente-Agente. El Curso Ocho amplía Paperclip una vez más, agregando la ruta de reconocimiento de aprobación delegada.

Del Curso Siete (la API de contratación): Paperclip expone la contratación como una capacidad invocable. El Gerente-Agente puede detectar una brecha de capacidad y proponer una nueva contratación, que pasa por la misma puerta de aprobación. El Curso Siete también presenta el registro de talento (un flujo de auditoría consultable mediante SQL de cada contratación, evaluación y retiro) y la primitiva política de aprobación automática, que aprueba automáticamente las contrataciones rutinarias que cumplen con los umbrales de envolvente, presupuesto y paquete de evaluación. La empresa contrató a un cuarto Worker, el Especialista Legal, que se ejecuta en Claude Managed Agents a través del adaptador http de Paperclip.

Lo que queda en el teclado de la propietaria humana después del Curso Siete: cada aprobación que no cumple con los umbrales de aprobación automática. Cada contratación con ampliación de envolvente. Cada reembolso que supere el límite máximo de aprobación automática. Cada terminación. Cada migración de CMA. Cada edición de política permanente. Este es el cuello de botella que elimina el Curso Ocho. Tres términos se repiten a lo largo del curso: Worker (un agente de IA que la empresa contrató), envolvente (los límites de lo que un Worker puede hacer) y Claude Managed Agents / CMA (el runtime de agente alojado que usó el Curso Siete para el ejemplo trabajado).

Si alguno de los cuatro se siente inestable, los documentos vinculados de los Cursos Cinco, Seis y Siete se remontan a los primeros principios.

Dónde encaja esto: hoja de trucos

Los 15 conceptos y las 7 decisiones del Curso Ocho, de un vistazo:

#	Concepto	Parte	Descripción de una línea
1	Una empresa nativa de IA deja de escalar por la atención de la propietaria	Por qué	Los cálculos del Curso Siete: alrededor de 5 a 10 aprobaciones por día en 10 Workers; cientos a 1.000. La propietaria se convierte en el cuello de botella a menos que algo actúe en su nombre.
2	Lo que significa Identic AI: el marco de Tapscott hecho concreto	Por qué	Cinco propiedades: memoria personalizada, que refleja valores, extensión del yo, autosoberanía y memoria persistente. Distingue la Identic AI de cualquier otro "asistente de IA".
3	Por qué la propietaria específicamente: no la fuerza laboral, no el cliente	Por qué	Existen otros casos de uso de Identic AI (del lado del cliente, del lado de los empleados), pero el caso estructural para la empresa nativa de IA es el de la propietaria. El curso enseña a uno bien, no a tres mal.
4	OpenClaw: qué es realmente	Arquitectura	Verificado de openclaw.ai. Tiempo de ejecución de la máquina local, accesibilidad a la app de mensajería, memoria persistente, código abierto, datos propiedad del usuario.
5	Memoria persistente y contexto local de la propietaria	Arquitectura	Donde el juicio acumulado de la propietaria vive en el sistema de archivos de Maya. La primitiva session de docs.openclaw.ai. Lo que persiste, lo que no.
6	Aplicaciones de chat como capa de interfaz	Arquitectura	Por qué OpenClaw llega a la propietaria a través de WhatsApp, Telegram y Discord en lugar de una aplicación web. La propietaria ya está en el chat; la Identic AI vive donde está la propietaria.
7	El problema de la delegación de confianza	Gobernanza	Dos principales autorizados (la propietaria humana y la Identic AI de la propietaria). El Gestor-Agente tiene que verificar quién actúa y qué autoridad tiene.
8	Delegación firmada de credenciales locales	Gobernanza	Con qué OpenClaw puede firmar localmente. Lo que verifica la capa de gestión Paperclip. Claves de acceso, claves respaldadas por hardware y modos de falla cuando se roba la máquina de la propietaria.
9	La intersección de dos envolventes	Gobernanza	La envolvente de autoridad de la propietaria ("Puedo aprobar cualquier cosa") se cruza con la envolvente delegada de la Identic AI ("Puedo aprobar decisiones rutinarias hasta estos límites"). Su intersección es lo que se ejecuta.
Parte 4	Las 7 decisiones de laboratorio	Laboratorio	Instala OpenClaw, incorpórala al contexto de la propietaria, desarrolla una skill de integración de Paperclip, conecta aprobaciones delegadas, demuestra el flujo de extremo a extremo, maneja el caso de anulación de la propietaria, prueba el cambio de dispositivo y los casos de portátiles robados.
10	Lo que la Identic AI aprende en seis meses	Auditoría	Los patrones de decisión acumulados de la propietaria. El ciclo del juicio-aprendizaje. Cómo almacena esto el sistema session de OpenClaw. Lo que hace que un patrón sea enseñable versus lo que permanece al nivel de la propietaria.
11	El registro de gobernanza: el flujo de auditoría de la Identic AI	Auditoría	Un registro de auditoría paralelo de lo que la Identic AI decidió en nombre de la propietaria. La propietaria lo lee semanalmente de la misma manera que el tablero lee el registro de talento del Curso Siete.
12	Cuando el juicio de la Identic AI y el de la propietaria divergen	Auditoría	¿Qué sucede cuando la Identic AI aprueba automáticamente algo que la propietaria habría rechazado? El circuito de recalibración. Por qué esta es una señal saludable, no un fracaso.
13	Memoria soberana: donde el juicio acumulado vive a largo plazo	Abierto	Tres opciones arquitectónicas. Lo que existe en mayo de 2026. Lo que Tapscott llama "reinventar la pila de IA". Honesto sobre lo que aún no está resuelto.
14	Alineación de valores más allá de la coincidencia de patrones	Abierto	La frontera: cómo una Identic AI aprende los valores de la propietaria (las reglas bajo los patrones), no solo los patrones en sí. Vista previa de la investigación, no lista para el plan de estudios.
15	Qué sigue: la economía de Identic AI y la disciplina de evaluación	Adelante	La finalización arquitectónica al final del Curso Ocho; el Curso Nueve agrega la disciplina de evaluación que hace que la arquitectura sea medible y confiable.

¿Estás listo para este curso?

Lista de verificación de requisitos previos

Lista de verificación de cinco elementos. Si alguno se siente inestable, los repasos vinculados a continuación lo llevarán allí.

1. Completaste los cursos cinco a siete o has creado el equivalente: un Worker empaquetado en Inngest, una capa de administración de Paperclip con la primitiva de aprobación y una API de contratación funcional. El Curso Ocho supone que existe la arquitectura del lado de la empresa. Si no es así, constrúyela primero.
2. Puedes leer TypeScript y scripts de shell, incluso si no puedes escribirlos con fluidez. El laboratorio utiliza TypeScript para la skill de integración de Paperclip y shell para la configuración de OpenClaw. Tu asistente de IA (Claude Code u OpenCode) escribe ambos; tú informas, revisas y apruebas. El patrón de información de los cursos tres a siete continúa sin cambios.
3. Tienes una máquina Mac, Linux o Windows en la que puedes instalar OpenClaw. El instalador de una sola línea de OpenClaw (curl -fsSL https://openclaw.ai/install.sh | bash) necesita derechos de administrador en la primera ejecución de Homebrew en macOS. El laboratorio depende de tener una instancia real de OpenClaw en ejecución; No existe un atajo solo en la nube para el Curso Ocho.
4. Tienes al menos una app de mensajería que puedes usar para el laboratorio: WhatsApp, Telegram, Discord, Slack, Signal o iMessage. El curso predeterminado es Telegram en los ejemplos porque los documentos de OpenClaw lo hacen, pero la elección es tuya.
5. Te sientes cómodo con la idea de que una IA tome decisiones en tu nombre, incluso si eres escéptico sobre hasta dónde debería llegar. El movimiento técnico central del curso es la autoridad delegada; si no puedes pasar "la IA está aprobando cosas en mi nombre", el laboratorio no aterrizará. El Concepto 12 aborda directamente los casos de falla; léelo antes de decidir.

Si alguno de los cinco se siente inestable, empieza con los repasos vinculados antes de continuar. El campo es denso; los requisitos previos lo hacen sentir ligero.

¿Nuevo aquí? El Curso Ocho es la octava de nueve: aquí está la rampa de acceso

El Curso Ocho cierra el lado arquitectónico de la ruta Agent Factory; el Curso Nueve agrega la disciplina del desarrollo impulsado por evaluaciones que convierte la arquitectura en un comportamiento de producción medible y confiable. Si los cinco requisitos previos anteriores no te resultan familiares, trabaja hacia atrás: Curso Siete: de fuerza laboral fija a dinámica es el requisito previo directo (la API de contratación y el plano de gestión del Curso Ocho se extienden). Antes de eso, repasa estos:

• Curso Seis: De Un Worker a una Fuerza Laboral (Clip más el plano de gestión)
• Curso Cinco: De FTE digital a Worker de producción (Inngest más la dotación operativa)
• Curso Tres: crear agentes de IA (el bucle del agente)
• el capítulo PRIMM-AI+ si eres nuevo en la codificación asistida por IA. El Curso Ocho hace referencia a los conceptos del Curso Seis y Siete en cada página o dos; Llegar en frío es más difícil que completar la rampa de acceso.

Si no puedes hacer la rampa de acceso ahora pero quieres seguir los conceptos, puedes simular los requisitos previos con menos de la pila completa:

• Lee el Inicio rápido de Paperclip y la Página de aprobaciones
• Lee Introducción a OpenClaw
• Lee PRIMM-AI+ Lección 1 para conocer el ritmo de predicción y ejecución que utiliza el curso en cada Concepto. Con esos sustitutos, puedes seguir las Partes 1 a 3 y las Partes 5 a 6 conceptualmente. La práctica de laboratorio de la Parte 4 requiere una instalación funcional de Paperclip (del Curso Siete) y una instalación funcional de OpenClaw (de este curso); no hay atajos.

Glosario: 26 términos a los que un principiante puede hacer referencia (haz clic para ampliar)

El Curso Ocho utiliza vocabulario de todo el recorrido de Agent Factory además de varios términos nuevos específicos de la arquitectura Identic AI. Términos agrupados por lo que describen.

Personas y roles

• Propietaria/Fundadora/CEO: la principal humana que posee la empresa nativa de IA. Los cursos sexto y séptimo llamaron a esto "la junta" cuando la decisión era a nivel de gobernanza; el Curso Ocho usa "propietaria" para enfatizar que estamos hablando de un ser humano individual con una Identic AI, no de una junta de varias personas.
• Identic AI: término de Don Tapscott (HBR IdeaCast Ep. 1066, 17 de febrero de 2026 y su libro You to the Power of Two) para una IA personalizada que refleja los valores de sus usuarios, persiste en su contexto y actúa como una extensión de ellos. Cinco propiedades: memoria personalizada, que refleja valores, extensión del yo, autosoberanía y memoria persistente.
• Maya: propietaria del ejemplo trabajado del Curso Ocho. Fundadora y directora ejecutiva de la empresa de atención al cliente creada a lo largo de los cursos cinco a siete. El curso la sigue a través del laboratorio.

Primitivas de OpenClaw

• OpenClaw: asistente personal de IA de código abierto (openclaw.ai). Se ejecuta en la máquina local del usuario; accesible a través de apps de mensajería; memoria persistente; acceso completo al sistema; skills y plugins. Tiempo de ejecución de ejemplo trabajado del Curso Ocho para la Identic AI de Maya.
• Habilidad: primitiva de extensibilidad de OpenClaw. Una habilidad es una unidad de capacidad (leer Gmail, controlar Spotify, hablar con Paperclip). Las habilidades pueden ser escritas por el usuario, aportadas por la comunidad (ClawHub) o escritas por el propio OpenClaw. Nota: la misma palabra que la primitiva skill de Paperclip pero es un concepto distinto; las habilidades de Paperclip se instalan en Workers, las skills de OpenClaw se instalan en el OpenClaw local del usuario.
• Sesión: primitiva de memoria persistente de OpenClaw (docs.openclaw.ai/concepts/session). La unidad de contexto acumulado para un usuario a lo largo del tiempo, de todos los dispositivos y de las apps de mensajería. Lo que hace que OpenClaw sea una Identic AI en lugar de un asistente sin estado.
• Integrado: proceso de configuración de OpenClaw. openclaw onboard guía al usuario a través de la configuración de la persona, la selección del modelo, la integración de la app de mensajería y la instalación inicial de habilidades.
• Aplicación complementaria: aplicación de barra de menú de macOS de OpenClaw (beta a partir de mayo de 2026). Una alternativa a la interacción chat-aplicación; útil cuando la propietaria está en su escritorio en lugar de en su teléfono.

Conceptos arquitectónicos del Curso Ocho

• Owner Identic AI: la configuración específica de una Identic AI que actúa como delegada de gobernanza para la propietaria de una empresa nativa de IA. Es el artefacto técnico central del curso. El OpenClaw de Maya, configurado según el patrón del Curso Ocho, es su Owner Identic AI.
• Gobernanza delegada: la primitiva de carga del Curso Ocho. El patrón mediante el cual la Owner Identic AI de Maya recibe solicitudes de aprobación de la capa de administración de Paperclip, aplica el juicio conocido de Maya a las rutinarias y presenta solo las importantes a la propia Maya.
• Delegación de confianza: el mecanismo de verificación que permite a la capa de administración de Paperclip distinguir entre Maya-the-human y Maya's-Identic-AI cuando llega un clic de aprobación. Ambas están autorizadas; el registro de auditoría indica cuál actuó.
• Envolvente de autoridad de la propietaria: envolvente de autoridad personal de Maya (análoga al concepto de envolvente de autoridad del Curso Seis). Lo que la propia Maya puede aprobar. Distinta de la envolvente delegada de la Identic AI.
• Envolvente delegada de la Identic AI: el subconjunto de la autoridad de Maya que su Identic AI puede ejercer en su nombre. Establecido por Maya, registrado en el registro de gobernanza, más limitado que la autoridad total de Maya por diseño.
• Registro de gobernanza: el Curso Ocho es paralelo al registro de talento del Curso Siete. El flujo de auditoría de solo anexo de cada decisión que la Identic AI de Maya tomó en su nombre. Maya lo lee semanalmente.
• Bucle de juicio-aprendizaje: cómo la Identic AI de Maya acumula un modelo de sus decisiones a lo largo del tiempo. El concepto 10 cubre la mecánica; el concepto 14 cubre la frontera del alineamiento de valores (el problema de investigación abierto de pasar de patrones a valores).
• Recalibración: el ciclo mediante el cual Maya corrige su Identic AI cuando su juicio difiere del de ella. El concepto 12 cubre esto. Los propios eventos de recalibración se registran en el registro de gobernanza.

De los cursos tres al siete (referenciados, definidos más detalladamente allí)

• Worker: un único agente de IA que trabaja para la empresa. El Curso Seis definió esto; el Curso Ocho lo utiliza en todo momento.
• Gerente-Agente: el Worker que orquesta a otros Workers. Protagonista del Curso Seis y Siete; interlocutor del Curso Ocho para la Identic AI de Maya.
• Paperclip: se introdujo la capa de gestión del Curso Seis y se amplió el Curso Siete. El Curso Ocho lo amplía una vez más, agregando la ruta de reconocimiento de aprobación delegada.
• Envolvente de autoridad: mecanismo del Curso Seis para limitar lo que un Worker puede hacer. El análogo del Curso Ocho es la división envolvente de autoridad de la propietaria más envolvente delegada.
• Registro de actividad: el flujo de auditoría de solo anexar de cada acción de la fuerza laboral. Distinto del registro de gobernanza del Curso Ocho (que es el flujo de auditoría de la Identic AI).
• Aprobación: puerta de gobierno del Curso Seis y Siete. En Paperclip, una aprobación es un registro de decisión, no un proceso en pausa: un miembro de la junta o un agente registrado registra una decisión en él. (step.wait_for_event es la primitiva de pausa duradera de Inngest del Curso Cinco, un mecanismo separado; las aprobaciones de Paperclip no están conectadas a él). El Curso Ocho cambia quién hace las rutinarias: la Identic AI de Maya antes que la propia Maya.

Nivel de tesis

• Empresa nativa de IA: término de nivel de tesis de los cursos seis y siete para una empresa cuyo trabajo lo hacen principalmente Workers de IA bajo gobierno humano. El Curso Ocho sostiene que la parte de gobernanza humana de esta definición es incoherente a escala sin una Owner Identic AI.
• Invariante 2 / el delegado: Invariante 2 de la tesis de Agent Factory: todo humano necesita un delegado. Un agente personal que mantiene la identidad, el contexto y la autoridad del usuario y gestiona todo el trabajo posterior en nombre del usuario. La tesis nombra a OpenClaw como delegado; el Curso Ocho enseña cómo configurar ese delegado como delegado de gobernanza para la propietaria de una empresa nativa de IA.
• Autosoberano: el compromiso de Tapscott de que una Identic AI debe ser propiedad del usuario, no de una plataforma. El Curso Ocho hereda este compromiso; OpenClaw es el producto enviado que lo pone en funcionamiento.

---

Parte 1: Por qué la propietaria es el cuello de botella

La tesis de los cursos cinco a siete era que una empresa nativa de IA puede ampliar su fuerza laboral de forma indefinida. La API de contratación se puede llamar. La primitiva de aprobación es reutilizable. El registro de talento es consultable. Nada en la arquitectura impide que la empresa contrate a su décimo Worker, a su centésimo, a su milésimo.

Pero algo limita la arquitectura y el Curso Siete lo dejó implícito. Cada decisión importante aún llama la atención de la propietaria humana. Una empresa que puede contratar 1000 Workers pero espera que un humano lea los hilos de aprobación de 1000 Workers no está escalando. Está trasladando el cuello de botella del "reclutamiento" a la "atención de la propietaria". La parte 1 concreta este argumento y luego presenta la respuesta arquitectónica: la Identic AI de la propietaria. Tres conceptos.

Concepto 1: una empresa nativa de IA deja de escalar por la atención de la propietaria, no ante la API de contratación

Este es el concepto más pesado del curso porque todo lo demás depende de él. Si el argumento aquí no funciona, el resto del Curso Ocho se leerá como una especulación prospectiva sobre la IA personal. Si el argumento funciona, el resto del Curso Ocho se leerá como resolver un problema concreto que crearon los tres cursos anteriores.

El argumento es estructural, pero la forma más fácil de verlo es poniéndole números. Usaremos el ejemplo real del Curso Siete: la empresa de atención al cliente creada en los Cursos Cinco al Siete, que al final del Curso Siete tiene cuatro Workers (Soporte de Nivel 1, Especialista de Nivel 2, Gerente-Agente y el Especialista Legal recién contratado en la Decisión 4 del Curso Siete). Maya, la fundadora y directora ejecutiva de la empresa, es la propietaria humana. Al final del Curso Siete, cada aprobación consiguiente todavía suena en el teléfono de Maya.

Las matemáticas de cuatro Workers. Contemos lo que llega al teléfono de Maya en una semana típica con la fuerza laboral del Curso Siete, usando tasas realistas de los ejemplos operativos en los Cursos Seis y Siete.

Fuente de aprobación	Por Worker por semana	A los 4 Workers
Reembolso > techo del sobre (refund_max=$500 del Curso Seis)	~2	~8
Alquiler de extensión de sobre (Concepto 8 del Curso Siete: la aprobación automática no se puede eludir)	~0,1	~0,4
Decisión de rescisión	~0,05	~0,2
Anulación del presupuesto (el Worker alcanzó su techo mensual)	~0,25	~1
Migración de CMA o cambio de sustrato	~0,05	~0,2
Edición de política permanente (nueva regla de aprobación automática)	~0,5	~2
Total por semana		~12

Doce eventos de aprobación por semana. Aproximadamente dos por día hábil. Maya puede manejar esto en su teléfono entre reuniones. El costo de la atención de la propietaria es real pero manejable. Este es el régimen para el que se diseñó la arquitectura del Curso Siete. Las matemáticas son cuarenta Workers. Ahora supongamos que la empresa de Maya ha crecido en seis meses. El Gerente-Agente detectó ocho brechas de capacidad más y contrató Workers para cada una: un especialista en facturación, un analista de reembolsos, un Worker de incorporación, un Worker de riesgo de abandono, tres especialistas de nivel 2 más para diferentes líneas de productos y un revisor legal senior. La política de aprobación automática del Concepto 9 del Curso Siete cubre la mayoría de las contrataciones ráfagas de Nivel 1. Hasta ahora, todo bien. Pero cada Worker genera su propio flujo de aprobaciones consiguientes.

A los 40 Workers	Por semana
Reembolsos > techo de sobres	~80
Alquiler de extensiones de sobres	~4
Decisiones de rescisión	~2
Anulaciones presupuestarias	~10
Migraciones CMA / cambios de sustrato	~2
Ediciones de políticas permanentes	~20
Total por semana	~118

Alrededor de 17 por día hábil. Maya ahora pasa de tres a cuatro horas diarias leyendo hilos de aprobación. Este es el régimen en el que Maya comienza a preguntar si debería contratar a un jefe de personal humano para clasificar la cola. Eso es un indicio. La arquitectura está empezando a fallar en la tesis original: se le pide a Maya que agregue humanos para escalar la fuerza laboral.

Las matemáticas son cuatrocientos Workers. Supongamos que Maya sigue creciendo. En el mes 18, la empresa cuenta con 400 Workers, una cifra todavía pequeña para una empresa nativa de IA, pero muy superior al tamaño en el que se probó la arquitectura de los cursos 5 a 7.

A 400 Workers	Por semana
Reembolsos > techo de sobres	~800
Alquiler de extensiones de sobres	~40
Decisiones de rescisión	~20
Anulaciones presupuestarias	~100
Migraciones CMA / cambios de sustrato	~20
Ediciones de políticas permanentes	~200
Total por semana	~1180

Aproximadamente 170 eventos de aprobación por día hábil. Maya no puede leer 170 hilos de aprobación por día, sin importar qué tan rápido se desplace. La arquitectura ha dejado de funcionar. El ciclo de contratación ahora genera más tráfico de aprobación del que la propietaria puede procesar. Maya ha llegado al cuello de botella en la atención de la propietaria.

Las matemáticas de escala dan un número al cuello de botella: una empresa nativa de IA alcanza su límite de atención a la propietaria entre 10 y 40 Workers, mucho antes de que se imponga cualquier otra restricción de escala.

¿Cuáles son las respuestas arquitectónicas disponibles para ella? Hay exactamente tres y el curso necesita que internalices que dos de ellos están equivocados antes de que el tercero (la Identic AI) se lea como la respuesta y no como una novedad.

Respuesta incorrecta A: aprobación automática más agresiva. Maya podría ampliar la política de aprobación automática del Concepto 9 del Curso Siete para cubrir más categorías. De hecho, la política aprueba automáticamente las contrataciones ráfaga de Nivel 1 con una envolvente de $250 al mes; podría elevar el límite a $1,000/mes o incluir decisiones de reembolso de hasta $2,000. Esto reduciría la cola. También abandonaría la propiedad de seguridad sobre la que se basa toda la tesis de las siete invariantes. La razón por la que el Curso Siete mantuvo el control de extensión de envolvente fuera de la superficie de aprobación automática (Concepto 8) es que cualquier autoridad que tenga un Worker y que ningún Worker haya tenido antes es una decisión que el ser humano debe tomar conscientemente. La aprobación automática de manera más agresiva revierte ese compromiso. Dice: no podemos molestarnos en gobernar a escala, por lo que declararemos que la escala no necesita gobernanza. Ese es el equivalente nativo de IA de una cultura de pull requests sin revisión. Funciona hasta que deja de funcionar.

Respuesta incorrecta B: agregar humanos al grupo de aprobación. Maya podría contratar a un jefe de personal humano para clasificar las aprobaciones o nombrar a dos cofundadoras como aprobadoras adicionales. Esto reduciría la cola por persona. También reintroduciría la jerarquía de organigramas que se suponía que las empresas nativas de IA debían aplanar. Todo el argumento arquitectónico del Curso Seis era que el Gerente-Agente absorbe la capa de coordinación de la gerencia media; si Maya ahora agrega una capa de gestión humana encima del Gerente-Agente para manejar las aprobaciones, ha reconstruido la forma de la empresa. Los cursos 5 a 7 tardaron tres cursos en eliminar esa capa. Peor aún: cada humano que agrega tiene el mismo techo de escala que ella. Dos cofundadoras procesan alrededor de 30 aprobaciones por día hábil en lugar de 17. Tres manejan alrededor de 50. La arquitectura todavía tiene un límite de aproximadamente 10 veces la fuerza laboral por ser humano; simplemente llega a un número ligeramente mayor. No se puede escalar una empresa nativa de IA agregando humanos a su circuito de gobernanza. Si pudiera, no sería nativa de IA. Respuesta correcta: la Identic AI de la propietaria. Un delegado de IA personal, que se ejecuta en el hardware de Maya, que ha aprendido los patrones de aprobación de Maya a partir de sus últimas 200 decisiones. Cuando llega una nueva solicitud de aprobación, la Identic AI la resuelve de forma autónoma (cuando el propio patrón de Maya es claro y la solicitud es rutinaria) o se la presenta a Maya (cuando la solicitud es novedosa, importante o está fuera de los patrones que la Identic AI ha aprendido con confianza). La atención de Maya ahora se centra únicamente en las decisiones que realmente se benefician del juicio humano y la fuerza laboral puede crecer sin volver a crear el cuello de botella.

Observa lo que esta respuesta no hace. No se aprueba automáticamente según una política que Maya escribió una vez y que olvidó. Aplica el juicio de Maya, que la Identic AI ha acumulado al verla decidir. No delega la autoridad: Maya sigue siendo la principal; la Identic AI actúa en su nombre, con su consentimiento explícito, y cada acción se registra en un flujo de auditoría que Maya revisa. La propietaria permanece informada; la atención de la propietaria no se centra en el tráfico rutinario. Esta es la primitiva arquitectónica que la tesis nombra como Invariante 2: el delegado. La tesis lo dice de manera abstracta ("cada ser humano necesita un delegado que mantenga su contexto, represente su juicio, lleve su envolvente de autoridad y negocie todo el trabajo posterior en su nombre"). El Curso Ocho lo pone en práctica de forma concreta para la propietaria de una empresa nativa de IA. Sin él, las seis invariantes operativas anteriores (motores, sistema de registro, sistema nervioso, capa de gestión, API de contratación) tienen como límite una fuerza laboral de unas pocas docenas. Con él, la arquitectura escala al tamaño de la fuerza laboral, no al tamaño del calendario de la propietaria.

PRIMM: Predecir

Eres Maya. Su empresa tiene 80 Workers en el mes nueve. La política de aprobación automática del Concepto 9 del Curso Siete cubre contrataciones en ráfagas de Nivel 1. Las señales de detección de brechas del Gerente-Agente desencadenan un nuevo patrón: un volumen inesperado de preguntas de clientes en español durante tres semanas. El Gerente-Agente redacta una propuesta de contratación de un Especialista de Nivel 2 de habla hispana. El sobre de autoridad propuesto es idéntico al Nivel 2 existente en inglés (no es necesario verificar la extensión del sobre). El presupuesto propuesto es de $800 al mes, muy dentro del límite de aprobación automática del Curso Siete. El paquete de evaluación pasa.

Dos predicciones, escritas por separado en papel antes de seguir leyendo:

1. Según la política de aprobación automática del Curso Siete (Concepto 9 del Curso Siete, que solo verifica los umbrales de sobre, presupuesto y paquete de evaluación): ¿esta contratación se aprueba automáticamente sin involucrar a Maya? Predice sí o no.
2. Bajo lo que enseñará el Curso Ocho (la Identic AI de la propietaria aplica el juicio acumulado de Maya): ¿la Identic AI de Maya aprueba esto automáticamente o se lo muestra a Maya? Predice si se muestra a Maya o se aprueba automáticamente.

Si sus dos predicciones son iguales, aún no ha visto la distinción en la que se basa el Curso Ocho. Si son diferentes, lo has visto. Cualquiera de los dos está bien; sigue leyendo.

Respuestas:

1. Sí, se activa la política de aprobación automática del Curso Siete. La contratación se ajusta a los criterios establecidos en la política: sobre conocido, pases de paquete de evaluación, dentro del límite presupuestario. La póliza no tiene forma de saber que esta contratación es diferente de una contratación rutinaria de capacidad máxima.
2. La Identic AI de la propietaria se lo presenta a Maya, no porque la política del Curso Siete sea incorrecta, sino porque la Identic AI codifica una clase de juicio que la política del Curso Siete no puede. El soporte en español es una expansión estratégica del mercado de Maya, no solo capacidad adicional. Maya podría querer pensar si la empresa está lista para comprometerse contractualmente con el soporte bilingüe, si la política de privacidad y los términos de servicio necesitan traducciones al español o si esta contratación indica una dirección más amplia del producto.

La distinción es regla versus juicio. Una regla puede codificarse una vez y aplicarse de manera uniforme. Un juicio se aprende de las decisiones pasadas de la propietaria y se aplica según la situación. La política del Curso Siete es una regla; la Identic AI de la propietaria aplica juicio. Ambas son valiosas: la regla maneja el 90% de los casos de rutina sin costo alguno para la atención de la propietaria; el juicio maneja el 10% restante que realmente se beneficia de un patrón entrenado por humanos. Esto es lo que el curso te enseñará a construir.

Conclusión: Las matemáticas del Concepto 1 dan un número al cuello de botella entre fuerza laboral y atención. La empresa nativa de IA alcanza su límite de atención a la propietaria entre 10 y 40 Workers, mucho antes que cualquier otra restricción de escala. La primitiva que el Invariante 2 nombra como delegado elimina ese límite, no reduciendo el número de decisiones, sino enrutando las rutinarias a través del juicio conocido de la propietaria en lugar de la atención real de la propietaria. Dos respuestas arquitectónicas son incorrectas (aprobar automáticamente de manera más agresiva; agregar humanos al bucle) y solo una es correcta (el delegado). Las matemáticas explican por qué.

Concepto 2: Qué significa Identic AI: el marco de Tapscott hecho concreto

La primitiva arquitectónica que resuelve el cuello de botella es Identic AI, como la define Don Tapscott en su entrevista HBR IdeaCast (Episodio 1066, 17 de febrero de 2026) y su libro You to the Power of Two: Redefining Human Potential in the Age of Identic AI. El Curso Ocho hereda el vocabulario de Tapscott porque es el marco más limpio disponible para lo que estamos construyendo y porque su adopción vincula el curso a una conversación actual sobre el discurso gerencial en lugar de acuñar otro término más.

Definición de Tapscott, textualmente de la transcripción:

"el surgimiento de compañeros inteligentes que realmente aprenden quiénes somos, reflejan nuestros valores y, en última instancia, operan como extensiones de nosotros mismos... un subconjunto de IA agente, los llamamos Identic AI"

Nombra cinco propiedades, cada una de las cuales volverá al Curso Ocho:

1. Personalizado: agente de una sola persona, no agente de la fuerza laboral. La Identic AI de Maya es la de Maya. No hay una instancia compartida, ni una cuenta de equipo, ni un nivel organizativo. La unidad es un humano, una Identic AI.
2. Refleja los valores y el juicio del usuario: capacitado en los documentos, decisiones, comunicaciones y contexto acumulado del usuario. Identic AI no es un asistente de IA genérico configurado con el nombre del usuario; es una IA que ha aprendido al usuario con el tiempo.
3. Extensión de uno mismo: pretende sentirse como una cognición extendida, no como una herramienta que el usuario invoca. En el marco de Tapscott: "se está convirtiendo en parte de la experiencia humana". En el caso de Maya: ella no "inicia sesión en tu Identic AI" de la misma manera que inicia sesión en Paperclip. Se puede acceder a la Identic AI en sus apps de mensajería, en su teléfono, en su barra de menú; actúa cuando ella actúa; sabe en qué está trabajando.
4. Autosoberano: propiedad del usuario, no de la plataforma. El énfasis de Tapscott a lo largo de la transcripción: "La Identic AI necesita ser autosoberana. Necesitamos ser propietarias de nuestra propia superinteligencia". El contexto acumulado, los patrones aprendidos, el modelo de juicio: estos pertenecen al usuario. No son rehenes de una plataforma. Sobreviven al cambio de dispositivo, de empleador y de preferencias de la app de mensajería.
5. Memoria persistente: acumula conocimiento del usuario de forma continua. Ejemplo de Tapscott de la transcripción: "Para Don digital, por ejemplo, cargué alrededor de 500 documentos, todo lo que pude encontrar que había escrito: mis discursos, mis PowerPoints, mis libros, artículos, entrevistas y todo tipo de cosas así. Y está aprendiendo sobre mí, cómo veo las cosas y cómo pienso sobre ellas."

Las cinco propiedades deben estar presentes juntas; la quinta, autosoberanía, es la que se abandona más fácilmente y la que determina la elección del tiempo de ejecución en el Concepto 4.

Estas cinco propiedades son la definición discriminatoria. Distinguen la Identic AI de:

• Asistentes de IA de uso general (que carecen de memoria persistente y no reflejan el criterio específico del usuario)
• Agentes de la fuerza laboral (que son propiedad de una empresa, no de un individuo; los Workers del curso 5-7 son agentes de la fuerza laboral)
• Agentes de IA del lado del cliente (que atienden a un usuario, pero normalmente son propiedad de la plataforma y están alojados en ella; no cumplen con la propiedad soberana)
• Asistentes personales sin aprendizaje (un bot de app de mensajería que programa reuniones es útil pero no acumula el juicio del usuario con el tiempo)

El discriminador que la mayoría de los lectores subestiman es la autosoberanía. Tapscott vuelve a mencionarlo repetidamente porque, en su opinión, la trayectoria predeterminada de la industria de la IA es hacia una Identic AI propiedad de la plataforma y contra una Identic AI propiedad de los usuarios. De la transcripción: "La pregunta más importante para mí es ¿quién será la propietaria de Adi digital? ¿Mark Zuckerberg? ¿Google? Esta es una extensión tuya y de tu inteligencia. Y si lo poseen, es un gran problema". Si la Identic AI de Maya está alojada en una plataforma que puede leer sus patrones de juicio, modificarlos, disminuirlos o revocar su acceso a ellos, entonces la Identic AI de Maya en realidad no está actuando en nombre de Maya. Está actuando en nombre de la plataforma con los datos de Maya. El Curso Ocho se compromete con la propiedad soberana como una propiedad arquitectónica no negociable. Ese compromiso es lo que determina la elección del tiempo de ejecución en el Concepto 4 (OpenClaw, porque se ejecuta en el hardware de Maya y almacena su contexto en el sistema de archivos de Maya, no como una opción de participación, como la arquitectura predeterminada).

Cómo se relaciona Identic AI con el caso de uso específico del Curso Ocho. El Curso Ocho no enseña Identic AI de propósito general. Está enseñando una configuración específica: Owner Identic AI, una Identic AI configurada para actuar como delegada de gobierno para la propietaria de una empresa nativa de IA. Existen otras configuraciones válidas de Identic AI (una Identic AI personal que dirige su hogar, administra tu calendario, redacta tu correo electrónico; el ejemplo del "Don digital" de Tapscott se ajusta a esto) y el Curso Ocho volverá a ellas brevemente en el Concepto 15 como la economía de Identic AI más amplia que permite la arquitectura. Pero el ejemplo más importante del curso es la Identic AI de Maya en su calidad de delegada de gobernanza. Esa capacidad es lo que pone en funcionamiento Invariante 2 para la empresa nativa de IA y esa es la capacidad que enseña el Curso Ocho.

Las cuatro propiedades con números más bajos (personalizada, que refleja valores, extensión del yo, memoria persistente) son requisitos operativos; el quinto (autosoberano) es un compromiso arquitectónico. Sin el quinto, los otros cuatro todavía funcionan, pero trabajan en contra de la propietaria y no a favor de ella. El Curso Ocho enseña los cinco y trata el quinto como el que es estructural.

En pocas palabras: la Identic AI, en el marco de Don Tapscott, es una IA personalizada que refleja los valores de sus usuarios, persiste su contexto a través del tiempo, actúa como una extensión de ellos y sigue siendo propiedad del usuario, no de una plataforma. Cinco propiedades; la quinta (autosoberanía) es la que se abandona más fácilmente y en la que el curso se niega a ceder. Owner Identic AI es la configuración específica que enseña el Curso Ocho: una Identic AI configurada para actuar como delegada de gobernanza de la propietaria de una empresa nativa de IA.

Concepto 3: Por qué la propietaria específicamente: no la fuerza laboral, no el cliente

Un lector razonable en este punto puede preguntar: _si la Identic AI es tan importante, ¿por qué el curso solo enseña la de la propietaria? ¿Por qué no enseñar Identic AI del lado del cliente o Identic AI del lado de los empleados o interacciones de Identic AIs entre pares o la economía de la Identic AI en términos más generales? La respuesta: el Curso Ocho toma una decisión deliberada sobre el alcance y el razonamiento importa.

Hay al menos cuatro categorías de casos de uso de Identic AI relevantes para una empresa nativa de IA:

Caso de uso	Cuya Identic AI	Qué hace	Vencimiento en mayo de 2026
Propietaria/delegado de gobernanza	La propietaria de una empresa nativa de IA	Prefiltra el tráfico de aprobación, aplica el criterio de la propietaria y presenta decisiones importantes	Enviado (OpenClaw más el patrón que enseña el Curso Ocho)
IA personal del lado del cliente	Un cliente individual	Interactúa con empresas en nombre del cliente, mantiene el contexto del cliente, hace compras	Parcialmente enviado (OpenClaw existe; las empresas aún no aceptan solicitudes firmadas de Identic AI del cliente como canal de interacción normal)
Delegado del lado de los empleados	Un empleado de una empresa nativa de IA	Redacta correos electrónicos, prepara reuniones, gestiona el trabajo propio del empleado delegado por la plantilla	Parcialmente enviado (OpenClaw puede hacer esto; la integración con los flujos de trabajo de la empresa varía)
Economía peer-to-peer/Identic AI	Identic AIs de dos individuos que interactúan directamente	Negociar acuerdos, programar y coordinar sin humanos en el circuito	Especulativo; el estado final del "número infinito de vicepresidentes" de Tapscott

El Curso Ocho enseña el primero (el de la propietaria) y no enseña los demás. Tres razones:

Primero, el argumento de caso estructural del Concepto 1 se refiere específicamente a la propietaria. La matemática de la imposibilidad de escalar no se aplica a los clientes o empleados de la misma manera. Un cliente sin una Identic AI sufre un ligero inconveniente; la fuerza laboral de la empresa aún puede atenderlos a través de canales tradicionales. Un empleado sin una Identic AI trabaja de la misma manera que siempre lo han hecho los empleados; la productividad es menor de lo que podría ser si la empresa funciona. Solo el cuello de botella de la propietaria impide que la empresa crezca. La afirmación del curso, de que la Identic AI de la propietaria es lo que hace operativo el Invariante 2 para una empresa nativa de IA, es cierta específicamente porque el caso de la propietaria es el que hace que la arquitectura sea incoherente sin él. Los demás casos son valiosos pero no son estructurales.

En segundo lugar, el caso de uso de Identic AI del lado del cliente aún no está completamente implementado y la arquitectura tiene brechas abiertas que el Curso Ocho no puede cerrar honestamente. La transcripción de Tapscott apunta al caso de uso del lado del cliente ("un médico que ha estado en todas las escuelas de medicina del mundo, su tutor que es literalmente un sabelotodo"). Pero la delegación de confianza entre la Identic AI de un extraño y la fuerza laboral de una empresa es un problema abierto más difícil que el caso de la propietaria. Con Maya, tanto la envolvente de autoridad de la propietaria como la envolvente delegada de la Identic AI son configuradas por la propia Maya; el modelo de confianza es unipartidista. Con un cliente arbitrario, la empresa tiene que verificar la identidad, la autoridad y la autorización a través de un límite que no es de confianza; el modelo de confianza es multipartito sin raíz compartida. Los cursos 5 a 7 tampoco enseñaron ese nivel de confianza entre partes; enseñarlo en el Curso Ocho requeriría introducir primitivas de las que el resto de la ruta no depende. Pedagogía honesta: enseñar bien el caso estructural; señalar el caso más amplio como frontera abierta. En tercer lugar, un curso que intenta enseñar los cuatro casos no enseña ninguno de ellos bien. El patrón de la ruta en los cursos 3 a 7 es enseñar una cosa profundamente, con un ejemplo completo y resuelto y señalar los casos adyacentes en las barras laterales y en la sección de avance. El Curso Seis enseñó a la fuerza laboral, no a la organización nativa de IA en general. El Curso Siete enseñó la API de contratación, no el ciclo de vida completo, incluida la transferencia a un abogado externo. El Curso Ocho enseña a la propietaria una Identic AI, no la economía más amplia de la Identic AI. El Concepto 15 regresa al panorama más amplio como la mirada final hacia el futuro, nombrando los casos del lado del cliente y del lado del empleado y de igual a igual como las próximas fronteras arquitectónicas. Pero el laboratorio, el ejemplo trabajado, los 15 Conceptos de la enseñanza: todo sobre el caso de Maya.

Una prueba útil para determinar si el Curso Ocho tomó la decisión correcta sobre el alcance: si un lector termina el Curso Ocho y configura con éxito la Owner Identic AI de Maya en su propia empresa nativa de IA, la arquitectura funciona a escala. La atención de la propietaria ya no es el cuello de botella. Los siete invariantes de los cursos 3-7 ya están completos. Si el mismo lector desea extender los patrones de Identic AI de la propietaria a otros casos de uso (una Identic AI del lado del cliente en su producto, un delegado del lado del empleado para su equipo), tiene las herramientas arquitectónicas para hacerlo. El Curso Ocho nombra qué extensiones ya existen y cuáles siguen abiertas. El curso aborda completamente el caso estructural y nombra el resto honestamente. Ese es el compromiso pedagógico.

PRIMM: Predecir

El Curso Ocho enseña la Owner Identic AI y no los otros tres casos de uso. Cada opción a continuación es un argumento real que alguien podría presentar para esa elección de alcance. Predice cuál es el razonamiento real del curso antes de seguir leyendo. El punto de la predicción es que más de uno de ellos es defendible; debes elegir el que coincida específicamente con el argumento central del curso.

(a) El caso de la propietaria es el único lo suficientemente maduro para enviarse: la Identic AI del lado del cliente y de igual a igual necesita primitivas de confianza entre partes que no existen en mayo de 2026, por lo que el curso enseña lo que se puede construir hoy. (b) El caso de la propietaria es el que es estructural: las matemáticas de escala del Concepto 1 muestran que sin la Identic AI de la propietaria, la arquitectura de los cursos 5 a 7 en sí es incoherente más allá de unas pocas docenas de Workers. Los demás casos son valiosos pero la empresa sigue funcionando sin ellos. (c) El caso de la propietaria es el pedagógicamente más simple: es un modelo de confianza unipartidista (Maya configura ambos sobres ella misma), por lo que es el lugar más limpio para enseñar la primitiva de delegación de confianza antes de los casos más difíciles. (d) El caso de la propietaria tiene la demanda comercial más clara: las propietarias de empresas nativas de IA son las compradoras que pagarán primero por un delegado de gobernanza, por lo que el curso enseña al mercado. Respuesta: (b). Los cuatro contienen algo verdadero, por lo que se trata de una predicción real y no de una verificación de lectura. (a) es cierto (el Concepto 3 dice exactamente esto sobre la madurez del lado del cliente) pero es una consecuencia de la elección del alcance, no la razón de la misma. (c) es cierto (el Concepto 3 menciona el modelo de confianza unipartidista como una ventaja didáctica), pero nuevamente es un beneficio, no la razón de peso. (d) bien puede ser cierto, pero el curso no presenta ningún argumento de demanda comercial. El razonamiento real del curso es (b): el cuello de botella de la propietaria es aquel cuya ausencia rompe la arquitectura. Las matemáticas del concepto 1 son el caso. Los casos del lado del cliente, del lado del empleado y de igual a igual son configuraciones de Identic AIs válidas, pero la empresa funciona sin ellas; solo el caso de la propietaria hace que los cursos 5 a 7 sean incoherentes a escala. El Curso Ocho enseña completamente el caso estructural; el concepto 15 nombra a los demás como frontera abierta.

En pocas palabras: el Curso Ocho enseña una configuración de Identic AI específica, la Owner Identic AI, porque ese es el caso de uso cuya ausencia hace que la arquitectura de los cursos 5 a 7 sea incoherente a escala. Otros casos idénticos de IA (del lado del cliente, del lado de los empleados, de igual a igual) son valiosos pero no soportan el argumento de escalamiento de la empresa nativa de IA. El curso presenta completamente el caso estructural y nombra el resto honestamente en el Concepto 15.

---

Parte 2: El tiempo de ejecución de OpenClaw

La parte 1 nombró el problema y se comprometió con un alcance. La parte 2 presenta el tiempo de ejecución, OpenClaw y explica qué es realmente, dónde vive y cómo Maya le habla. Tres Conceptos: qué es OpenClaw, verificado desde la fuente oficial (Concepto 4); dónde vive el contexto acumulado de Maya en el sistema de archivos de Maya (Concepto 5); y por qué OpenClaw eligió apps de mensajería en lugar de una aplicación web como capa de interfaz (Concepto 6).

Concepto 4: OpenClaw, lo que realmente es

OpenClaw es el tiempo de ejecución contra el que se enseña el Curso Ocho. Antes de que cualquiera de los patrones arquitectónicos de los Conceptos 7 a 15 tenga sentido, necesita un modelo mental limpio de lo que realmente es OpenClaw, verificado de openclaw.ai y docs.openclaw.ai, no de la comparación de patrones con productos anteriores de IA personal.

Los hechos verificados, extraídos directamente del sitio y los documentos oficiales:

• Se ejecuta en la máquina local del usuario. Mac, Windows o Linux. El instalador es curl -fsSL https://openclaw.ai/install.sh | bash o npm i -g openclaw. Después de la instalación, openclaw onboard recorre la instalación.
• Código abierto. github.com/openclaw/openclaw. Con licencia MIT. El usuario puede leer, bifurcar, modificar y autohospedarse.
• Accesible a través de apps de mensajería que el usuario ya usa. OpenClaw enumera más de 50 integraciones, incluidos más de 15 canales de chat (WhatsApp, Telegram, Discord, Slack, Signal, iMessage y más) en openclaw.ai/integrations. El usuario no instala una nueva aplicación; envían mensajes a OpenClaw en tu app de mensajería existente.
• Memoria persistente. La frase titular del sitio: "Te recuerda y se vuelve exclusivamente tuyo. Tus preferencias, tu contexto, tu IA". La primitiva session (docs.openclaw.ai/concepts/session) es la unidad de contexto acumulado.
• Acceso completo al sistema en la máquina del usuario. Leer y escribir archivos, ejecutar comandos de shell, ejecutar scripts (docs.openclaw.ai/bash). Acceso completo o sandbox: a elección del usuario.
• Control del navegador. Puede navegar por la web, completar formularios, extraer datos de cualquier sitio (docs.openclaw.ai/browser).
• Habilidades y plugins. Ampliable con habilidades comunitarias (clawhub.ai) o creadas por el usuario (docs.openclaw.ai/skills). OpenClaw puede incluso escribir el suyo propio.
• Independiente del modelo. Modelos antrópicos, OpenAI o locales. El usuario elige durante la incorporación.
• Aplicación complementaria. Una aplicación de barra de menú de macOS (beta en mayo de 2026) para acceso al escritorio junto con la interfaz de la app de mensajería.

Señales institucionales dignas de mención. La señal más importante de OpenClaw es estructural más que reputacional: el proyecto es de código abierto bajo una licencia MIT. Esa licencia es una garantía de continuidad, porque cualquier persona puede bifurcar y alojar el código base en github.com/openclaw/openclaw, independientemente de lo que les suceda a los administradores del proyecto. Más allá de la licencia, el proyecto tiene un gran número de seguidores en GitHub (cientos de miles de estrellas) y cuenta con el patrocinio de importantes proveedores. En mayo de 2026, la lista de patrocinadores incluye OpenAI, GitHub, NVIDIA, Vercel y Convex. Una lista de patrocinadores es el tipo de hecho que cambia, así que trátelo como un ejemplo de mayo de 2026 en lugar de un reclamo de carga. El fundadora, Peter Steinberger, se unió a OpenAI a principios de 2026 mientras el proyecto continúa como un esfuerzo de código abierto. Los recuentos específicos y los detalles del patrocinador deben verificarse en openclaw.ai y en el GitHub del proyecto antes de ser citado con autoridad. Por qué estas señales son importantes para el Curso Ocho. El compromiso arquitectónico central del Curso Ocho es la autosoberanía: el juicio acumulado de Maya es suyo, no de una plataforma. El riesgo de cualquier proyecto de IA personal de código abierto es que se cierre, se convierta en un producto de código cerrado o cambia su modelo de propiedad de datos. La señal que más lucha contra ese riesgo es la propia licencia MIT. El respaldo institucional (la lista de patrocinadores principales, la contratación de la fundadora por parte de OpenAI) indica que el proyecto tiene recursos y una participación de la industria, pero tanto el patrocinio como la contratación pueden cambiar.El código abierto es la garantía de durabilidad que sobrevive a un cambio de administradores: incluso si la dirección del proyecto cambia, el código base puede bifurcarse y autohospedarse y el tiempo de ejecución de Maya puede continuar. Ninguna de estas señales es prueba de durabilidad a largo plazo. Juntos, con la licencia MIT como ancla, hacen de OpenClaw el tiempo de ejecución de Identic AI y autónomo más creíble para construir un plan de estudios en mayo de 2026. El modelo mental: en qué se diferencia OpenClaw de un chatbot. Un lector que llega a OpenClaw desde ChatGPT o Claude.ai tiene un modelo mental de "una IA en una ventana de chat que abro cuando quiero preguntar algo". Ese modelo es incorrecto para una Identic AI en tres formas específicas:

Modelo mental	Chatbot	Propietaria de Identic AI (OpenClaw)
¿Cuándo actúa la IA?	Solo cuando el usuario abre explícitamente la aplicación y escribe	Continuamente, en segundo plano; de forma proactiva cuando el usuario tenga instrucciones permanentes; mediante controles de latidos del corazón
¿Dónde vive la IA?	En una pestaña el usuario abre	Ya en las apps de mensajería del usuario (WhatsApp, Telegram) y en el sistema de archivos del usuario
¿Qué recuerda la IA?	Contexto dentro de la conversación que se descarta entre sesiones	Sesión persistente en todas las interacciones, todos los dispositivos, en todo momento
¿Quién inicia?	El usuario, cada vez	Cualquiera de las partes: el usuario puede preguntar y la IA también puede sacar a la luz las cosas de forma proactiva

La cuarta fila es la más importante y la más fácil de pasar por alto. En un chatbot, el usuario siempre es el iniciador. En una Identic AI, la IA también es un iniciador. Claudia puede enviarle a Maya un mensaje de Telegram en cualquier momento ("acaba de llegar una solicitud de reembolso de un cliente; según nuestros patrones, esta es una que aprobaría automáticamente. ¿Está bien continuar?"). Esta iniciación bidireccional es lo que hace que una Identic AI sea útil para la delegación de gobernanza. Un chatbot Maya tiene que abrirse y consultarse, no puede filtrar previamente los hilos de aprobación; una Identic AI que envía mensajes a Maya cuando es necesario.

Concretamente, cómo se ve una primera sesión. Un usuario que ejecuta curl -fsSL https://openclaw.ai/install.sh | bash y luego openclaw onboard recorre aproximadamente esta secuencia (según los documentos en docs.openclaw.ai/getting-started):

1. Elige un modelo. Anthropic Claude, OpenAI GPT o un modelo local. (Para el Curso Ocho, usaremos Claude opus-4-7 como valor predeterminado).
2. Ponle un nombre a tu OpenClaw. Los usuarios nombran tu Identic AI, "Claudia", "Jarvis", "Brosef" y eligen un tono personal. El nombre hace que Identic AI se sienta como una entidad en lugar de un servicio: una vez que tiene un nombre, los usuarios tienden a referirse a su OpenClaw por su nombre en la conversación.
3. Elige una app de mensajería principal. Telegram (la configuración de bot más común y sencilla), WhatsApp, Discord, Signal, iMessage o Slack. El usuario crea un bot en tu app de mensajería (por ejemplo, a través de @BotFather en Telegram) y pega el token en OpenClaw.
4. Instalación inicial de habilidades. OpenClaw pregunta al usuario en qué quiere que tu Identic AI sea buena: gestión de calendario, correo electrónico, código, gobernanza, todo lo anterior. Instalación de habilidades seleccionadas desde clawhub.ai (el mercado de habilidades de la comunidad). Para los propósitos del Curso Ocho, ninguna de las habilidades predeterminadas maneja la integración de Paperclip; lo escribiremos en la Decisión 3.
5. Una primera conversación. El usuario abre tu app de mensajería, encuentra su bot OpenClaw y escribe "hola". OpenClaw responde en la persona elegida y, a partir de ese momento, se puede acceder a la Identic AI en el flujo de comunicación normal del usuario. No hay ninguna aplicación separada para abrir. Todo el recorrido a bordo dura de 5 a 10 minutos. Los compromisos arquitectónicos de los que depende el Curso Ocho (almacenamiento del sistema de archivos local, sesión persistente, accesibilidad de la app de mensajería) están integrados en la instalación en lugar de configurarse por usuario.

Por qué OpenClaw es el tiempo de ejecución de Maya, no una alternativa:

Alternativa	¿Por qué no en el Curso Ocho?
Claude Agent SDK + Identic AI personalizada	Puedes crearlo, pero debe reunir persistencia, integración de apps de mensajería, gestión de habilidades e incorporación por tu cuenta. OpenClaw envía todos esos.
SDK de agentes OpenAI + Identic AI personalizada	El mismo problema, además la arquitectura está más cerca de la forma de la fuerza laboral en la nube que de la forma de la IA personal.
Una IA personal SaaS alojada (por ejemplo, un hipotético "Claude for Personal")	Falla la propiedad soberana. El juicio acumulado de Maya vive en una plataforma que puedes leerlo, modificarlo o revocarlo. Se viola el compromiso central de Tapscott.
Roll-your-self usando Inngest + una interfaz personalizada	Es posible, pero pasas el curso enseñando cableado de integración en lugar de enseñar Identic AI. El valor del curso está en los patrones arquitectónicos, no en la mecánica del tiempo de ejecución.

OpenClaw se ajusta a los requisitos en cada eje: se entrega, es de código abierto, almacena el contexto del usuario en el sistema de archivos del usuario de forma predeterminada y llega al usuario a través de las apps de mensajería en las que ya se encuentra. Para el ejemplo trabajado del Curso Ocho, es el tiempo de ejecución el nombre de la tesis. Para su implementación real, los patrones arquitectónicos se transfieren a otros tiempos de ejecución; OpenClaw es el ejemplo, no el requisito.

Si no puedes usar OpenClaw: guía de transferencia. Las restricciones de cumplimiento, las restricciones del proveedor de modelos o las preferencias de construcción versus compra pueden poner a OpenClaw fuera de tu alcance. Los patrones arquitectónicos del Curso Ocho todavía se aplican; simplemente los pondrás en funcionamiento en un tiempo de ejecución diferente. Así es como las primitivas de OpenClaw que son estructurales se asignan a lo que construirías por tu cuenta:

Primitiva OpenClaw	Qué necesitas proporcionar	Sustrato sugerido
El bucle del agente (Concepto 4)	Un bucle de llamada de modelo con ejecución de herramientas	Claude Agent SDK u OpenAI Agents SDK con un proceso demonio de larga duración
Tiempo de ejecución de la máquina local (Concepto 4)	Un proceso que sobrevive a los reinicios y permanece ejecutándose en el hardware de la propietaria	systemd en Linux, launchd en macOS, un servicio de Windows o un pequeño contenedor Docker que la propietaria ejecuta localmente
La primitiva session (Concepto 5)	Almacenamiento de contexto persistente en el sistema de archivos de la propietaria	Un directorio que el demonio lee y escribe; JSON o SQLite estructurado es suficiente; cualquier esquema que eliges es tuyo
Accesibilidad de la app de mensajería (Concepto 6)	Una forma para que la propietaria envíe mensajes al agente y obtenga respuestas	Un único bot de app de mensajería (los bots de Telegram son los más simples; el flujo de BotFather tarda unos 5 minutos). Las más de 50 integraciones son el valor agregado de OpenClaw, no un requisito de la arquitectura
Sistema de habilidades y plugins	Un mecanismo de extensión para capacidades como "hablar con Paperclip"	Funciones escritas a mano de Python o TypeScript registradas como herramientas en su SDK de agente
La clave de firma (Concepto 8)	Un par de claves ed25519 almacenado en el sistema de archivos de la propietaria	Código de biblioteca estándar: crypto.subtle en el navegador, crypto en Node, cryptography en Python

Qué cambia en comparación con el Curso Ocho tal como está escrito: escribes más código adhesivo (manifiestos de habilidades, supervisión de demonios, integración de apps de mensajería). Lo que permanece igual: la primitiva de delegación de confianza (Conceptos 7 a 9), el esquema del registro de gobernanza (Concepto 11), la intersección de dos sobres, el ciclo de recalibración. Esfuerzo para ensamblar un equivalente del Curso Ocho en el SDK de Claude Agent: aproximadamente un fin de semana para un ingeniero experimentado. La disciplina está en los patrones, no en el tiempo de ejecución.

Conclusión: OpenClaw es el tiempo de ejecución de IA personal de código abierto y propiedad del usuario contra el que se enseña el Curso Ocho. Se ejecuta en la máquina local de la propietaria, almacena el contexto en el sistema de archivos de la propietaria y se puede acceder a él a través de las apps de mensajería que la propietaria ya utiliza. A partir de mayo de 2026, es la puesta en funcionamiento creíble del compromiso soberano de Identic AI de Tapscott: código abierto bajo una licencia MIT, con un gran seguimiento de GitHub y el patrocinio de los principales proveedores. Los patrones del curso se transfieren a otros tiempos de ejecución, pero OpenClaw es el ejemplo trabajado.

Concepto 5: memoria persistente y contexto local de la propietaria

La única propiedad que convierte a OpenClaw de "otro chatbot de IA" a "la Identic AI de Maya" es la memoria persistente. Sin él, Maya tendría que volver a explicar su criterio a OpenClaw en cada interacción; el valor de una Identic AI es precisamente que no olvida. El concepto 5 explica cómo funciona la memoria persistente de OpenClaw, dónde vive realmente el contexto acumulado de Maya y qué implica la arquitectura para el caso de uso central del Curso Ocho.

La primitiva session. OpenClaw organiza el contexto persistente en torno a lo que sus documentos llaman la sesión: la unidad de contexto acumulado para un usuario a través del tiempo, a través de dispositivos, a través de apps de mensajería. Tres cosas que debes saber sobre el modelo de sesión:

1. El almacenamiento es local. La sesión de Maya reside en el hardware de Maya, en el sistema de archivos de Maya, en su directorio de inicio bajo la ruta de configuración de OpenClaw. No está sincronizado con una cuenta en la nube de forma predeterminada. No existe una "Nube OpenClaw" que almacene el contexto de Maya. (Maya puede optar por la sincronización para uso en múltiples dispositivos; el Concepto 13 analiza las ventajas y desventajas).
2. El almacenamiento es legible por humanos. La sesión son datos estructurados en el disco de Maya que ella puede inspeccionar, editar, versionar con git, cifrar, hacer copias de seguridad o destruir a su discreción. El compromiso de autosoberanía de Tapscott se pone en práctica aquí como una propiedad del sistema de archivos: Maya es propietaria de los archivos; Los archivos son el contexto de Maya.
3. El almacenamiento se acumula. Cada interacción se suma a la sesión. Maya envía un mensaje a OpenClaw en Telegram sobre una decisión de reembolso; esa decisión se une a la sesión. Ella aprueba una contratación tomando un café a través de la aplicación de la barra de menú; esa aprobación se une a la sesión. Seis meses después, la sesión contiene cientos de decisiones, preferencias, patrones de comunicación e instrucciones explícitas de Maya grabadas.

Lo que persiste, concretamente. La sesión de OpenClaw captura algo más que la transcripción del chat. De los documentos:

Persistente	Qué es	Por qué es importante para la Owner Identic AI
Historial de conversaciones	El intercambio literal de mensajes entre Maya y OpenClaw a través de apps de mensajería	El disco crudo. Maya puede volver a leer lo que dijo y lo que hizo OpenClaw.
Preferencias de usuario	Declaraciones explícitas que hace Maya ("Prefiero las reuniones matutinas"; "No apruebes nada que supere los 5.000 dólares sin mí")	Instrucciones permanentes que la misma IA aplica a partir de entonces
Habilidades instaladas y configuradas	Qué skills de OpenClaw ha instalado Maya; sus configuraciones	La capacidad de la Identic AI emerge, incluida la skill de integración de Paperclip que se construye en el Curso Ocho
Persona	La identidad nombrada de Maya para OpenClaw (por ejemplo, "Maya's Lobster" o "Claudia") y la persona que OpenClaw proyecta hacia atrás	Continuidad de la identidad entre chats y dispositivos
Registro de actividad	Qué hizo OpenClaw y cuándo: cada invocación de habilidad, cada llamada API externa, cada decisión	El registro de auditoría que se convierte en el registro de gobernanza del Curso Ocho (Concepto 11)
Patrones derivados	El modelo acumulado de juicio de Maya de la Identic AI, aprendido con el tiempo	El ciclo de juicio-aprendizaje del que trata el curso

Qué no persiste de forma predeterminada: estado ambiental efímero (qué app de mensajería usó Maya para un mensaje determinado, la marca de tiempo precisa con una resolución de milisegundos y similares). Estos se registran pero no se muestran como parte de la sesión relevante para la identidad. La distinción es importante porque la pregunta del Concepto 13, qué viaja con Maya a través de dispositivos y empleadores, es exactamente la pregunta de qué subconjunto de la sesión es relevante para la identidad.

Por qué el almacenamiento local del sistema de archivos es el compromiso arquitectónico que es estructural. Esta es la parte de la arquitectura OpenClaw que más fácilmente se pasa por alto. Muchos productos de IA anuncian "memoria persistente" mientras en voz baja significan "almacenamos su memoria en nuestra nube y tú nos la confía". La elección de OpenClaw, el sistema de archivos predeterminado de Maya, es cualitativamente diferente. Significa:

• Maya puede leer su propio contexto con cat ~/.openclaw/session/*.json (o cualquiera que sea la ruta al momento de escribir; consulta docs.openclaw.ai/concepts/session para el diseño canónico).
• Maya puede hacer una copia de seguridad de su contexto con las mismas herramientas que usa para cualquier otro archivo (Time Machine, rsync, Git, unidades externas cifradas).
• Maya puede mover su contexto a un nuevo dispositivo moviendo los archivos.
• Maya puede destruir su contexto eliminando los archivos. No existe una "solicitud de eliminación" que presentar ante un proveedor.
• Maya puede cifrar su contexto en reposo con sus herramientas de cifrado de disco existentes.
• El contexto de Maya no es rehén de ninguna plataforma. Si el proyecto OpenClaw se cerrara mañana, el contexto acumulado de Maya todavía existiría en su disco; podría leerlo, analizarlo y cargarlo en un tiempo de ejecución diferente.

Ésta es la propiedad que satisface el compromiso de autosoberanía de Tapscott. También es la propiedad que hace que la Identic AI de Maya sobreviva cambiando tu app de mensajería, su proveedor de modelo e incluso (con esfuerzo) su tiempo de ejecución. La sesión es de Maya; el tiempo de ejecución es configurable.

PRIMM: Predecir

Maya ha estado usando OpenClaw durante seis meses. Su directorio de sesiones en su Mac tiene aproximadamente 240 MB. Cambia de empleador: vende su actual empresa basada en IA y comienza una nueva. ¿Cuál de las siguientes partes de su sesión debería esperar trasladar a su nueva empresa y cuáles no?

Artículos:

• (a) su estilo de comunicación y preferencias de tono
• (b) sus decisiones anteriores de aprobación de los Workers de la antigua empresa
• (c) la configuración de la skill de integración de Paperclip que apunta al endpoint API de la antigua empresa
• (d) su instrucción permanente "siempre intensificar las contrataciones de extensión de sobre"
• (e) el registro de actividad de cada acción que OpenClaw realizó en la antigua empresa

Predice para cada uno: viaja con Maya / se queda con la antigua compañía / es complicado. Entonces sigue leyendo.

---

Respuesta: (a) viajes. El estilo de comunicación es un patrón personal, no propiedad de la empresa. (b) es complicado. Los patrones derivados de esas decisiones ("Maya tiende a aprobar contrataciones con extensiones de sobre cuando X pero no Y" viajan); las decisiones en sí(que se referían a Workers específicos y cuestiones específicas en la antigua empresa) permanecen, por una cuestión de confidencialidad. (c) permanece. La configuración de esa habilidad apunta al endpoint de la antigua empresa; la nueva empresa tiene diferentes endpoints, posiblemente una autenticación diferente. (La habilidad en sí puede viajar como una receta y reconfigurarse). (d) viaja. Esa es una instrucción personal permanente; se aplica en cualquier lugar. (e) permanece. El registro de actividad registra las acciones tomadas en la antigua empresa contra los sistemas de la antigua empresa; son datos de auditoría a los que la antigua empresa tiene derechos, no datos que posee Maya.

Esta es la costura de Harper Carroll del Concepto 13 del Curso Siete, aplicada a la sesión de Maya: los patrones viajan, los registros específicos no. El diseño del sistema de archivos de la sesión de OpenClaw hace que esta distinción sea aplicable. Maya puede empaquetar y migrar el subconjunto de patrones personales y dejar atrás el subconjunto de registros de la empresa.

En pocas palabras: La Identic AI de Maya es la sesión de Maya, un almacén local estructurado del historial de conversaciones, preferencias, habilidades, personalidad, registro de actividad y patrones derivados. Vive en el sistema de archivos de Maya, en archivos de su propiedad legibles por humanos. Esto es lo que hace que la arquitectura sea autosoberana y lo que hace que el juicio acumulado de Maya sobreviva a cada cambio de dispositivo, empleador o app de mensajería. La sesión es de Maya; todo lo demás es configuración.

Concepto 6: apps de mensajería como capa de interfaz

La elección arquitectónica no obvia que hace OpenClaw es que no tiene tu propia interfaz de usuario para la conversación entre el usuario y la IA. No existe una aplicación web OpenClaw ni una aplicación móvil OpenClaw para chatear. El usuario habla con OpenClaw a través de apps de mensajería que ya utiliza: WhatsApp, Telegram, Discord, Slack, Signal, iMessage. El Concepto 6 explica por qué esta es la elección arquitectónica correcta para una Identic AI y lo que implica para el ejemplo práctico del Curso Ocho.

¿Por qué no una aplicación dedicada? La medida predeterminada para un producto de IA es incluir una interfaz de usuario de chat propia: una aplicación web, una aplicación móvil, ambas. OpenClaw deliberadamente no lo hace. El razonamiento, extraído de las elecciones de diseño del proyecto, es que Una Identic AI debería vivir donde el usuario ya vive, no donde el producto quiere que viva el usuario. El usuario ya está todo el día en sus apps de mensajería: hilos grupales con tu equipo, DM con su familia, WhatsApp con su pareja. Poner la Identic AI en esas aplicaciones significa:

• El usuario no cambia de contexto para hablar con él.
• El usuario puede incluir la Identic AI en chats grupales con otros humanos (Maya puede agregar su OpenClaw a un canal de discusión en el foro de Slack; la Identic AI participa como par).
• El sistema de notificación existente del usuario maneja el enrutamiento de la atención (el teléfono de Maya suena para OpenClaw de la misma manera que suena para los mensajes de tu equipo).
• El usuario no tiene ninguna aplicación separada que recordar abrir.
• Identic AI hereda todas las comodidades de las apps de mensajería: mensajes de voz, archivos adjuntos, hilos de grupo, historial de búsqueda.

Las integraciones de canales de chat son un compromiso arquitectónico, no una lista de funciones. OpenClaw enumera más de 50 integraciones, incluidos más de 15 canales de chat (WhatsApp, Telegram, Discord, Slack, Signal, iMessage y más) en openclaw.ai/integrations. El conjunto de canales de chat es la parte que importa aquí. El usuario elige su aplicación o apps de mensajería preferidas durante openclaw onboard; OpenClaw se integra con ellos; el usuario comienza a enviar mensajes. No existe una curva de aprendizaje para la interfaz de chat porque el usuario ya sabe cómo funciona tu app de mensajería.

Qué significa esto para Maya. En el ejemplo práctico del Curso Ocho, Maya configura OpenClaw para que sea accesible a través de Telegram. (Elegimos Telegram porque los documentos de OpenClaw lo usan como ejemplo predeterminado y porque Telegram tiene una semántica de bot limpia. Maya podría usar igualmente WhatsApp o Signal). Maya nombra su OpenClaw "Claudia" durante la incorporación. A partir de entonces:

• Cuando Maya quiere enviarle un mensaje a tu Identic AI, abre Telegram, busca el chat con Claudia y escribe. El mismo gesto que enviar un mensaje a un compañero de equipo.
• Cuando tu Identic AI quiere revelarle algo (una aprobación que necesita su criterio, un resumen semanal del registro de gobernanza), le envía un mensaje de Telegram. Mismo flujo de notificación que cualquier otro mensaje.
• Cuando Maya está en su escritorio, puede usar la aplicación de barra de menú macOS de OpenClaw en lugar de cambiar a Telegram. La sesión es compartida.
• Cuando Maya viaja y usa su teléfono, la misma Claudia está ahí. La sesión se sincroniza entre sus dispositivos (con las advertencias arquitectónicas del Concepto 13 sobre cómo funciona esa sincronización).

La implicación para el problema de la delegación de confianza. Esto es sutil y vale la pena señalarlo antes de que la Parte 3 entre en ello. Debido a que OpenClaw reside en apps de mensajería en las que el usuario ya confía, la confianza usuario a OpenClaw se hereda de la propia autenticación de la app de mensajería. Maya ya ha iniciado sesión en Telegram como Maya; ya es destinataria de los mensajes enviados a su cuenta de Telegram; OpenClaw no necesita volver a autenticarla en el límite entre usuario e IA. El problema de delegación de confianza en el Curso Ocho, por lo tanto, no es "cómo sabe OpenClaw que es Maya", que se resuelve con la propia autenticación de Telegram. Es "cómo sabe la_capa de administración de Paperclip_ que una solicitud de aprobación que se origina en OpenClaw de Maya está genuinamente autorizada por Maya". Ese es el problema del Concepto 7.

Pruebe con IA

Pega esto en tu asistente de codificación AI:

"OpenClaw llega al usuario a través de apps de mensajería como interfaz principal: WhatsApp, Telegram, Discord, Slack, Signal, iMessage y más. El compromiso arquitectónico es que la Identic AI vive donde el usuario ya vive, no en una aplicación separada. Desde la perspectiva del usuario, esto es una clara victoria: cambio de contexto cero, notificaciones existentes, chats grupales. Desde una perspectiva de seguridad, enumera tres cosas que el usuario debe verificar sobre la app de mensajería elegida antes de tratar su conversación de OpenClaw como confiable para la gobernanza. Por ejemplo: ¿el chat está cifrado de extremo a extremo? ¿Qué sucede si el proveedor de la app de mensajería se ve obligado a entregar mensajes? ¿Cuál es la historia de recuperación si la cuenta de la app de mensajería se ve comprometida? Lo que estás aprendiendo: la interfaz de la app de mensajería hereda la confianza de la app de mensajería y esa confianza tiene propiedades reales que Maya debería verificar. El cifrado de extremo a extremo de Telegram es opcional (solo para "Chats secretos"); WhatsApp es de extremo a extremo por defecto; iMessage es de extremo a extremo dentro del ecosistema de Apple. Cada elección tiene implicaciones sobre si la integración de Paperclip está tratando los mensajes de la app de mensajería como evidencia criptográfica de la intención de Maya (no debería) o como un canal de conveniencia (debería). La primitiva de delegación firmada del Concepto 8 es lo que hace que las decisiones de gobernanza se basen criptográficamente, independientemente de qué app de mensajería las enrute.

_En pocas palabras: la arquitectura de interfaz de app de mensajería de OpenClaw es una elección deliberada: la Identic AI vive donde ya vive la propietaria, no en una aplicación separada. Para Maya, esto significa que Telegram (o WhatsApp o cualquiera de los canales de chat admitidos) se convierte en su interfaz para su Owner Identic AI. La implicación arquitectónica para la delegación de confianza es que la autenticación de usuario a OpenClaw se hereda de la app de mensajería; el problema de la confianza que es estructural está en el límite de OpenClaw a Paperclip, que aborda el Concepto 7.

---

Parte 3: Delegación y gobernanza de la confianza

Las partes 1 y 2 nombraron el problema (Maya no puede leer las aprobaciones a escala), la primitiva arquitectónica que lo resuelve (Identic AI) y el tiempo de ejecución que lo pone en funcionamiento (OpenClaw). La Parte 3 retoma el movimiento técnico de carga del Curso Ocho: cómo la capa de gestión Paperclip de la empresa puede aceptar de forma segura decisiones de aprobación de la Identic AI de Maya sin abandonar la propiedad de seguridad de la que depende toda la tesis de las siete invariantes. Tres conceptos.

Concepto 7: El problema de la delegación de confianza

Cuando Maya inicia sesión en Paperclip y hace clic en "aprobar" en una propuesta de contratación, el Gerente-Agente registra que la propietaria humana aprobó. Cuando la Identic AI de Maya ("Claudia") hace clic en "aprobar" en una propuesta de contratación de rutina a las 3 a.m. mientras Maya duerme, el Gerente-Agente registra que algo aprobó. La pregunta que aborda el Concepto 7 es qué debería ser diferente en estos dos casos y qué debería ser igual. Las dos respuestas ingenuas están equivocadas:

Respuesta ingenua A: trátalos igual. "Claudia está autorizada; su clic es el clic de Maya; regístralo como aprobado por Maya". Esto colapsa la distinción y produce un registro de auditoría que miente. Seis meses después, cuando Maya está revisando cómo se tomó una decisión en particular, no puede saber en el registro de actividad si la tomó ella misma o si la Identic AI de Maya la tomó en su nombre. La información necesaria para la recalibración (Concepto 12), es decir, "¿mi Identic AI manejó esto bien o necesito corregirlo?", desaparece. Una auditoría veraz requiere distinguir los dos principales. Respuesta ingenua B: siempre requiere al ser humano. "Claudia no puede aprobar nada; solo puede enviarle un mensaje a Maya con las solicitudes de aprobación y Maya hace clic en 'aprobar' ella misma". Esta es la arquitectura sin una Identic AI; no hemos avanzado. El objetivo del argumento de la Parte 1 es que Maya no puede estar al tanto de cada aprobación de rutina. Una Identic AI que solo puede transmitir mensajes no resuelve el problema de escala. La respuesta correcta es estructuralmente un movimiento de tres partes:

1. La Identic AI tiene su propia identidad en el sistema. OpenClaw de Maya, configurada como Claudia, tiene una identidad distinta que Paperclip reconoce: Claudia está registrada como agente de Paperclip, con su propia clave. Claudia no es una cuenta de usuario; es una agente delegada de Maya. Este es un nuevo tipo de principal que los cursos anteriores no necesitaban.
2. La autoridad de la Identic AI es un subconjunto de la autoridad de Maya, establecida por Maya, con límites claros. Maya puede aprobar cualquier cosa en la envolvente de autoridad de la propietaria; Claudia puede aprobar un subconjunto configurado (el Concepto 9 recorre la intersección). El subconjunto está registrado: Maya sabe lo que Claudia puede hacer; Claudia lo sabe; Paperclip lo almacena.
3. El registro de auditoría registra qué principal actuó y debes ser honesto acerca de dónde se encuentra ese registro. Esta es la parte en la que es fácil equivocarse, por lo que el curso lo establece claramente desde el principio. Contra el Paperclip 2026.513.0 real, las rutas de aprobación tienen alcance de tablero: una llamada de aprobación, rechazo o solicitud de revisión se registra como una acción del tablero, por lo que el propio activity_log de Paperclip escribe actor_type='user' tanto si Maya hizo clic como si Claudia manejó la decisión. Paperclip no distingue de forma nativa propietaria humana de propietaria-Identic-AI en una aprobación. Entonces, la distinción de dos principales reside en la propia tabla governance_ledger del curso: cada decisión que toma Claudia escribe una fila governance_ledger que contiene principal='owner_identic_ai', su certificación y su razonamiento. Una aprobación resuelta por Maya no tiene esa fila. Une las dos tablas sobre el ID de aprobación y la distinción será totalmente recuperable. (El mock de la ruta simulada toma un atajo: implementa la atribución nativa actor: owner_identic_ai directamente, simplemente como una simplificación didáctica. El Paperclip real no lo hace y la ruta de implementación completa es honesta al respecto a lo largo de la Parte 4.)

Este movimiento de tres partes es lo que hace que la gobernanza delegada sea más segura que imprudente. El principio se cumple en ambos sentidos: dos principales, una verdad de auditoría distinta y legible para humanos. Lo que difiere es el mecanismo: atribución nativa en el mock, el governance_ledger frente al Paperclip real. Maya delega, pero no desaparece: el registro de auditoría la hace siempre recuperable.

Dos principales, un ser humano: frente al Paperclip real, la distinción reside en el propio registro de gobernanza del curso, unido al registro de actividad de Paperclip en el ID de aprobación, por lo que cada decisión delegada sigue siendo recuperable. El mock lo implementa de forma nativa como una simplificación de la enseñanza.

Donde esto es realmente difícil. Las respuestas ingenuas fallan de manera obvia. Pero la respuesta correcta tiene una pregunta de implementación genuinamente difícil enterrada: ¿cómo verifica la capa de administración de Paperclip que una solicitud que dice ser de "Identic AI de Maya" proviene de hecho de la Identic AI de Maya y no de algún otro proceso que pretende serlo? Si alguien puede publicar actor: owner_identic_ai, principal: maya en la API de aprobación y aceptarla, toda la arquitectura está rota. El mecanismo de verificación, delegación firmada de credenciales locales, es lo que aborda el Concepto 8.

En pocas palabras: el problema de la delegación de confianza es el movimiento técnico de carga del Curso Ocho. Se autorizan dos principales, la propietaria humana y la Identic AI de la propietaria, y la arquitectura tiene que distinguirlos en la verdad de auditoría, vincular la autoridad de la Identic AI como un subconjunto de la de la propietaria y verificar criptográficamente la identidad de la Identic AI. Ni "tratarlos igual" ni "exigir siempre lo humano" funciona. El movimiento de tres partes es identidad distinta, autoridad limitada y auditoría veraz. El detalle honesto: contra el Paperclip real, las rutas de aprobación tienen alcance de tablero, por lo que la distinción de dos principales no la lleva activity_log de Paperclip; vive en el governance_ledger del curso. El mock de la ruta simulada implementa la atribución nativa como una simplificación de la enseñanza. El principio es idéntico en ambas vías; el mecanismo es diferente.

Concepto 8: Delegación firmada de credenciales locales

Manual para lectores nuevos en criptografía de clave pública

Los siguientes dos Conceptos y Decisiones 4-5 utilizan primitivas de delegación con signo. Si "ed25519" y "verificación de firma" aún no están en tu caja de herramientas, aquí está la versión de 90 segundos. Un par de claves ed25519 es un par de archivos relacionados: una clave privada(un secreto que guarda tu máquina, aproximadamente 32 bytes) y una_clave pública_(una clave no secreta derivada de ella, también de aproximadamente 32 bytes). Cuando tu máquina_firma_una carga útil, produce una cadena corta (la firma). Cualquiera que tenga tu clave pública puede_verificar_ esa firma matemáticamente, demostrando que la carga útil proviene de quien posee la clave privada, sin revelar la clave privada. ed25519 es el valor predeterminado moderno: claves pequeñas, operaciones rápidas, lo suficientemente seguro como para que toda la infraestructura TLS de la web se traslade a él. La codificación JSON canónica es importante porque la operación de firmar y verificar se hace sobre bytes exactos, no sobre "los mismos datos": si el firmante y el verificador serializan el JSON de manera diferente (por ejemplo, ordenando las claves), la firma no se verificará aunque los datos sean lógicamente idénticos. La práctica estándar es ordenar las claves y eliminar los espacios en blanco adicionales antes de firmar. Las tres primitivas, ed25519, verificación de firma y JSON canónico, se envían en bibliotecas estándar de Node y navegador. Claude Code u OpenCode maneja los detalles de implementación en las Decisiones 4-5; Este manual es para que los informes se lean como ingeniería, no como magia.

El mecanismo de verificación utiliza primitivas que se enviarán en mayo de 2026: claves de firma almacenadas en el sistema de archivos, opcionalmente respaldadas por hardware a través de almacenes de claves de plataforma (macOS Keychain, Windows Credential Manager, Linux libsecret), combinadas con claves de acceso/desafíos criptográficos estilo WebAuthn en el lado de Paperclip. Esta es una de las partes del Curso Ocho que conecta los bloques básicos de ambos productos enviados en lugar de utilizar una única integración enviada; los bloques de construcción son estables, el cableado es lo que el curso te enseña a ensamblar. La clave de firma en la máquina de Maya. Durante la práctica de laboratorio del Curso Ocho (Decisión 1), OpenClaw de Maya se configura con un par de claves criptográficas nuevas. La clave privada se encuentra en el directorio de inicio de Maya (u, opcionalmente, en el almacén de claves de su plataforma). La clave pública se registra en la capa de gestión de Paperclip como perteneciente a la "Identic AI de Maya". A partir de entonces:

• Cuando OpenClaw de Maya hace una solicitud a la API de aprobación de Paperclip en nombre de Maya, OpenClaw firma la carga útil de decisión con la clave privada.
• La capa de delegación propia del curso (Decisión 5) verifica la firma con la clave pública registrada. (Paperclip en sí no tiene un campo de firma en las rutas de aprobación; la certificación ed25519 es la propia capa del curso, no algo que PaperPaperclip verifica. La firma aún hace un trabajo real: prueba que la decisión provino de la clave de Claudia y no fue manipulada antes de que la capa de delegación impulse la ruta real de Paperclip).
• Si la firma es válida, la capa de delegación sabe que la solicitud proviene genuinamente de la Identic AI registrada de Maya.
• La solicitud se procesa a través del control de autoridad acotada (Concepto 9); la capa de delegación luego llama a la ruta de aprobación real dentro del ámbito del tablero y escribe una fila governance_ledger que registra principal: owner_identic_ai. (El propio activity_log de Paperclip registra la aprobación como una acción de la junta, actor_type='user'; la distinción entre propietaria humana y propietaria-Identic-AI está en governance_ledger. El Concepto 7 y la Parte 4 cubren esto en su totalidad).

Por qué el sistema de archivos (o el almacén de claves de la plataforma) y no "la nube". La clave de firma es de Maya; debería vivir donde Maya pueda controlarlo. El almacenamiento del sistema de archivos significa que Maya puede hacer una copia de seguridad, copiarlo a un nuevo dispositivo o destruirlo de la misma manera que controla el resto de su sesión de OpenClaw. El almacenamiento del almacén de claves de la plataforma (macOS Keychain y similares) agrega respaldo de hardware: la clave no se puede exportar sin la autenticación del sistema operativo Maya, lo que eleva el listón para un atacante que obtiene acceso al sistema de archivos pero no a la sesión del usuario. Ambos son locales por defecto; ninguno de los dos filtra la identidad de Maya a un tercero.

El modo de falla de el portátil robado. ¿Qué sucede si le roban la Mac a Maya? Tres escenarios de falla, ordenados por gravedad:

1. Portátil robado, Maya no ha iniciado sesión, FileVault cifrado. El atacante tiene el dispositivo pero no puede leer el sistema de archivos. La clave privada es ilegible. Sin superficie de ataque; Maya reemplaza el portátil y la vuelve a incorporar en uno nuevo.
2. Portátil robado, Maya inició sesión pero la pantalla está bloqueada. El atacante tiene el dispositivo, el disco está descifrado, pero no puede desbloquear la pantalla. La clave privada está en el disco, pero el atacante no puede activar OpenClaw para que la use. Cierto riesgo si el atacante tiene acceso a nivel del sistema de archivos (por ejemplo, arrancando desde una unidad externa); el enfoque del almacén de claves de plataforma eleva este listón.
3. Portátil robado, el atacante tiene la sesión de Maya activa. El atacante puede hablar con OpenClaw de Maya, puede firmar solicitudes como la Identic AI de Maya, puede aprobar cosas en Paperclip hasta la autoridad delegada de Claudia. Este es el peor de los casos. La mitigación es la revocación en el lado de Paperclip: Maya, desde un dispositivo diferente, registra una nueva clave pública y revoca la robada. El laboratorio del curso (Decisión 7) sigue este flujo de revocación.

La historia de la recuperación es el detalle que es estructural. Una arquitectura de delegación firmada que no tiene una ruta de recuperación para un dispositivo robado es frágil. El curso enseña el flujo de revocación como parte de la Decisión 7 porque ahí es donde el compromiso arquitectónico se vuelve operativo. Maya siempre puede, desde cualquier dispositivo que todavía controle, iniciar sesión en Paperclip (con sus propias credenciales de propietaria humana, no con las credenciales de tu Identic AI) y revocar cualquier clave de Identic AI que haya sido comprometida. La relación con las claves de acceso. Las credenciales de propietaria humana de Maya en Paperclip están protegidas por claves de acceso/WebAuthn, la misma primitiva hacia la que se está moviendo la web en general en 2026. Maya inicia sesión en Paperclip con su clave de acceso (que está vinculada a un dispositivo que ella controla, respaldada por hardware siempre que sea posible). La clave de firma de Identic AI es una credencial separada: representa a Claudia, no a Maya y Maya puede revocarla desde su sesión autenticada con clave de acceso. Dos credenciales, dos principales, un ser humano; la arquitectura los distingue limpiamente.

PRIMM: Predecir

La empresa de Maya tiene una API publicada en https://maya-co.com/api. Alguien ajeno a la empresa intenta enviar una solicitud de aprobación-aceptación afirmando ser la Identic AI de Maya. La solicitud incluye un campo signature. Sin la clave pública registrada en los archivos, la solicitud sería imposible de verificar. Predice: en el orden en que se ejecuta la lógica de verificación de tu capa de delegación (las tres puertas de la Decisión 5), ¿qué verificación falla primero? (a) validez criptográfica de la firma, (b) la clave-del-firmante-está-registrada, (c) verificación-de-autoridad-limitada (Concepto 9), (d) escritura del registro de gobernanza. Entonces sigue leyendo.

---

Respuesta: (b). Lo primero que verifica tu capa de delegación es si la clave pública con la que se hizo la firma es una clave de Identic AI registrada para una propietaria conocida. Si la clave del firmante no está archivada, la capa rechaza la solicitud antes de hacer cualquier verificación criptográfica. (Puede verificar la firma criptográficamente, pero si está firmada con una clave desconocida, el resultado de la verificación no ayuda: una firma válida de una clave desconocida sigue siendo un principal desconocido). La primera puerta es el registro de identidad; la validez criptográfica es la segunda puerta. Este orden es importante porque evita que los atacantes gasten CPU en la verificación de firmas para solicitudes entrantes arbitrarias; Sólo las solicitudes de principales registrados llegan tan lejos. (Ten en cuenta que esta verificación es la capa de delegación del curso, no Paperclip: Paperclip no tiene campo de firma en las rutas de aprobación. El Concepto 7 y la Decisión 5 explican el motivo).

Conclusión: la delegación firmada permite que la Identic AI de Maya actúe en su nombre en Paperclip sin ambigüedad sobre qué director actuó. La clave de firma se encuentra en la máquina de Maya (sistema de archivos o almacén de claves de plataforma); la clave pública se registra para que la propia capa de delegación del curso pueda verificar las certificaciones de Claudia; esa capa escribe el principal delegado en governance_ledger. El caso del portátil robado se maneja mediante revocación: Maya siempre puede invalidar las credenciales de tu Identic AI desde cualquier dispositivo que todavía controle. La arquitectura es robusta en el modo de falla que importa.

Concepto 9: La intersección de dos sobres

El sobre de autoridad de Maya, en el modelo de Paperclip, es lo que ella puede aprobar: cualquier cosa en la superficie de autoridad de la empresa, hasta e incluyendo contrataciones con extensión de sobre, despidos y reembolsos ilimitados. Ese no es el sobre correcto para Claudia. El sobre delegado de Claudia es un subconjunto deliberadamente más estrecho del de Maya, establecido por Maya y registrado en Paperclip como parte de los metadatos registrados de Identic AI. El concepto 9 sigue la lógica de la intersección: lo que se ejecuta cuando Claudia actúa no es aquello para lo que Claudia afirma tener autoridad y_no_ lo que Maya podría hacer; es la intersección de los dos.

Los dos sobres, concretamente. Para la empresa de atención al cliente del Curso Siete, los sobres de Maya se parecen a esto:

Sobre de autoridad propietaria de Maya (lo que la propia Maya puede aprobar)	Sobre delegado de Claudia (lo que la Identic AI de Maya puede aprobar en su nombre)
Reembolsos: ilimitados	Reembolsos: hasta $2,000
Contrataciones dentro de la dotación existente: sí	Contrataciones dentro de la dotación existente: sí
Contrataciones ampliando dotación empresarial: sí	Contrataciones ampliando la dotación de la empresa: no, superficie a Maya
Terminaciones: si	Terminaciones: no, superficie a Maya
Anulaciones de presupuesto: ilimitadas	Anulaciones de presupuesto: hasta un 20 % sobre el límite mensual
Ediciones de políticas permanentes: sí	Ediciones de la política permanente: no, superficie a Maya
Migraciones CMA: sí	Migraciones de CMA: hasta una por trimestre, solo para Workers con un presupuesto inferior a $1000/mes

El patrón: Claudia puede actuar de forma autónoma en decisiones rutinarias y limitadas; ella cede a Maya las decisiones estratégicas, irreversibles o de cambio de categoría. Maya establece estos umbrales durante el laboratorio del Curso Ocho (Decisión 4) y los revisa trimestralmente.

Una acción se ejecuta sólo cuando se encuentra dentro de ambos sobres a la vez: la intersección estricta, nunca la unión.

La lógica de la intersección. Cuando Claudia intenta actuar, Paperclip calcula:

1. ¿Está esta acción en el sobre de autoridad de la propietaria? (Es decir, ¿se le permitiría a Maya aprobarla?) Sí para todo en este ejemplo, porque Maya es propietaria de la empresa; no, por ejemplo, para una solicitud que exceda el límite presupuestario general de la empresa, que Maya tampoco puede aprobar unilateralmente.
2. ¿Está esta acción en el sobre delegado de la Identic AI? (Es decir, ¿se le permite a Claudia actuar en consecuencia?) Sí, para reembolsos de hasta $2000; no para contrataciones de extensión de sobres.
3. La acción continúa solo si ambos son sí. Si solo (1) es sí y (2) es no, la acción se le presenta a Maya como una solicitud de aprobación que ella misma maneja.

Por qué la intersección es el modelo correcto, no la unión. La autoridad de Maya es un techo, no un paquete transferible. Claudia no puede exceder la autoridad de Maya; si Maya puede aprobar hasta $X, Claudia no puede aprobar más. Pero Claudia también está limitada_por debajo_ del techo de Maya por la elección deliberada de Maya: Maya podría decir "Confío en Claudia con hasta $2,000 en reembolsos, pero reembolsos de $5,000 los quiero ver yo misma". La arquitectura tiene que codificar ambos límites y la intersección es la única lógica que lo hace.

La superficie de instrucciones de pie. Maya puede extender o contraer el sobre delegado de Claudia dándole instrucciones de pie a Claudia. Ejemplos que Maya podría dar durante seis meses:

• "Aprobar cualquier reembolso hasta $2,000 si la cuenta del cliente tiene más de dos años y no tiene reembolsos previos."
• "Siempre mencione las contrataciones de extensión de sobre, incluso si la nueva autoridad es algo que le hemos otorgado antes."
• "Durante el próximo mes, mientras probamos la nueva línea de productos, muéstrame cualquier contratación para esa línea de productos."
• "Si el exceso del presupuesto de un Worker está correlacionado con un incidente conocido en el registro de actividad, puede aprobar la anulación hasta un 50%, pero marcarlo en el resumen semanal del registro de gobernanza."

Estas instrucciones se acumulan en la sesión de Maya como parte de la memoria persistente (Concepto 5). La Identic AI los aplica junto con el límite máximo de sobre delegada. El resultado es que la política de Maya se aprende y actualiza en lenguaje sencillo, no se codifica una vez en un archivo de configuración estático. Esta es la distinción del Concepto 1 entre una_regla_ y un_juicio_, operacionalizada.

_En pocas palabras: la acción que ejecuta Claudia es la intersección de la sobre de autoridad propietaria de Maya (el techo) y la sobre delegado de Claudia (el subconjunto elegido por Maya). La intersección es la única lógica que limita correctamente la autoridad de una Identic AI: no puede exceder la de la propietaria y no puede exceder lo que la propietaria ha decidido delegar. Maya extiende y contrae el sobre delegado a través de instrucciones permanentes que le da a Claudia en lenguaje sencillo, haciendo de la política un juicio que Maya actualiza con el tiempo, no una regla codificada una vez.---

Parte 4: El ejemplo resuelto: cableado de la Identic AI de Maya

Las partes 1-3 explicaron la arquitectura. La parte 4 explica cómo ensamblarla de manera concreta. Siete decisiones, cada una como brief para tu sesión de Claude Code u OpenCode, nunca escritas ni editadas a mano. Al final de la Parte 4, tu Owner Identic AI estará instalada en una Mac, accesible por Telegram y configurada con una envolvente delegada. Lo que significa "manejar de forma demostrable las aprobaciones rutinarias" depende de tu ruta: en la ruta de implementación completa, la Identic AI de Maya está conectada a su implementación real de Paperclip del Curso Siete y ejercita el recorrido criptográfico completo contra las rutas de aprobación en vivo. En la ruta simulada, ejercitas los mismos patrones arquitectónicos contra una simulación local de Paperclip: terminas con una demostración funcional y un modelo mental sólido, pero el cableado de producción a un Paperclip real no forma parte del laboratorio simulado. Ambas rutas terminan con una Identic AI que maneja una avalancha de aprobaciones rutinarias y presenta las importantes; se diferencian en si Paperclip del otro lado es real.

Elige tu ruta antes de la Decisión 1: la elección cambia cada brief

El laboratorio del Curso Ocho funciona de dos maneras. Elige antes de la Decisión 1: la elección afecta cómo lees cada brief, cuánto tiempo dedicas y con qué terminas. No cambies a mitad del laboratorio; el cableado no será consistente.

1. Implementación completa (para propietarias de una empresa nativa de IA que ejecuta Paperclip). No modificas el código base de Paperclip. Crea una clave API de tablero de Paperclip real (de board_api_keys) y se la entregas a tu Identic AI: esa credencial de tablero autentica sus llamadas a las rutas de aprobación reales (POST /api/approvals/{id}/approve y similares). También la registras como un agente real de Paperclip con una entrada agent_api_keys, lo que le otorga una identidad de Paperclip y una superficie de revocación (no es lo que autentica la llamada de aprobación). Construyes tu propia capa de firma, verificación de firma y envolvente delegada dentro de la skill de integración de OpenClaw, además de tu propia tabla aditiva governance_ledger, y ejercitas el recorrido criptográfico completo contra una implementación de Paperclip en vivo. Tiempo: 6 a 10 horas de laboratorio además de 3 horas de lectura; de manera realista, un sprint de 1 o 2 días con espacio para pensar. Resultado: una Owner Identic AI de grado de producción para tu empresa real.
2. Simulado (para todos los demás: estudiantes, personas sin un Paperclip implementado). Ejecutas un endpoint simulado de Paperclip que acepta una forma de API simplificada, devuelve respuestas predeterminadas y escribe en un governance_ledger.json local. Se ejercitan los patrones arquitectónicos; el cableado de producción, no. Tiempo: 2 a 3 horas de laboratorio además de 2 horas de lectura; medio día cómodo. Resultado: comprensión práctica de Owner Identic AI más una demostración local.

La mayoría de las Decisiones funcionan para ambas rutas con el mismo brief. Las decisiones 3, 5, 6 y 7 son las que realmente divergen: llevan un bloque etiquetado Ruta simulada y un bloque Ruta de implementación completa. El mock de la ruta simulada mantiene rutas simplificadas (incluida una única ruta /resolve); la ruta completa utiliza la superficie real de Paperclip.

Lo único que cambia conceptualmente con la elección de ruta: dónde reside la distinción entre los dos principales. Los conceptos 7 a 9 ya enseñaron esto, así que es una referencia cruzada, no material nuevo. Contra el Paperclip 2026.513.0 real, las rutas de aprobación tienen alcance de tablero: cada fila de activity_log que escriben es actor_type='user', por lo que Paperclip no puede distinguir una aprobación resuelta por Claudia de una resuelta por Maya. La distinción reside en el propio governance_ledger del curso. El mock de la ruta simulada implementa la atribución nativa owner_identic_ai directamente, como simplificación didáctica. La ruta de implementación completa que sigue es honesta al respecto de principio a fin.

Configuración del laboratorio: antes de la Decisión 1

Las siguientes decisiones están escritas para ejecutarse a través de Claude Code o OpenCode (tu herramienta de codificación agéntica; consulta el Curso intensivo de codificación agéntica si no estás familiarizado con alguna de ellas). No escribes ni editas código manualmente en ninguna parte de esta práctica de laboratorio. Cada decisión se informa a tu herramienta de codificación agéntica, que produce un plan, revisas y apruebas el plan y luego la herramienta lo implementa. Esta es la misma disciplina que utilizaron los Cursos Tres a Siete. Si omites esta configuración e intentas conducir el laboratorio con una IA de chat genérica, tres modos de falla específicos te afectarán:

1. la IA del chat no puede leer ni editar tu sistema de archivos, por lo que cada artefacto de código debe copiarse y pegarse dentro y fuera del chat, lo que duplica el tiempo de laboratorio;
2. no existe un modo de planificación equivalente, por lo que la IA comenzará a escribir código antes de que hayas revisado el enfoque y pasarás horas deshaciendo instrucciones incorrectas;
3. no hay un archivo de reglas de proyecto que la IA lea en cada sesión, por lo que cada sesión vuelve a aprender las restricciones (no toque el registro de gobernanza de producción; siempre ejecuta pruebas antes de confirmar; nunca edite course-seven-export/ ya que es de solo lectura) y se repetirá constantemente.

La configuración consta de dos pasos: instala tu agente de codificación y luego descargue el proyecto inicial. Unos 10 minutos en total.

1. Instala Claude Code u OpenCode

Elige uno. Ambos funcionan para todo el laboratorio; elige según su preferencia de modelo y cuánto control de configuración desea. (Si ya tiene uno instalado, vaya al paso 2, pero ejecuta el comando de actualización para asegurarse de tener la última versión).

# macOS / Linux / WSL: recommended (auto-updates)
curl -fsSL https://claude.ai/install.sh | bash

# Or via Homebrew (no auto-update)
brew install --cask claude-code

# Verify and update
claude update
claude --version

Referencia de instalación completa: docs.claude.com/claude-code.

2. Descarga el proyecto inicial

Todo lo demás que necesita el laboratorio está precableado en un proyecto inicial. Descárgalo, descomprímelo y tendrás una carpeta real git init-able course-eight-lab/ con el archivo de reglas del proyecto, los permisos y las barreras de seguridad, los comandos de verificación reutilizables, el mock de la ruta simulada y el historial de aprobación de solo lectura de Maya ya implementado.

Descargar: identic-ai-crash-course.zip

En el borrador anterior de este curso, tenía que escribir a mano aproximadamente 350 líneas de configuración en seis pasos de configuración. Esa configuración ahora se envía en el zip, por lo que la lees y la ejecutas en lugar de transcribirla. Aquí está el diseño y por qué es importante cada pieza:

identic-ai-crash-course/
├── README.md                      # human entry: what this is, pick a track, next step
├── CLAUDE.md                      # the project rules file (Claude Code)
├── AGENTS.md                      # the project rules file (OpenCode)
├── opencode.json                  # OpenCode: instruction files + permissions + plugin wiring
├── .claude/
│   ├── settings.json              # permissions allow/deny + 3 PreToolUse guardrail hooks
│   └── commands/                  # /verify-audit-trail and /verify-envelope slash commands
├── .opencode/
│   ├── plugins/course-eight-guardrails.js   # the same 3 guardrails as an OpenCode plugin
│   └── commands/                  # the two slash commands for OpenCode
├── mocks/
│   └── paperclip-mock.ts          # the simulated-track Paperclip stand-in
├── course-seven-export/
│   ├── README.md                  # read-only input, do not edit
│   └── approvals.json             # a sample of Maya's past approval decisions
└── docs/
    ├── course-eight-architecture.md      # architectural background the rules file @-references
    ├── governance-ledger-schema.sql      # the schema Decisions 5 and 11 build against
    └── openclaw-skills-reference.md      # OpenClaw skills system pointer notes

Para qué sirve cada pieza:

• CLAUDE.md / AGENTS.md (el archivo de reglas del proyecto). Este es un contexto de carga: tu agente de codificación lo lee al inicio de cada sesión, por lo que conoce la pila, las dos rutas de laboratorio, las reglas críticas (nunca edites course-seven-export/, nunca imprimas la clave de firma, ejecuta npm test después de cambios del lado de Paperclip, el paso de detención del demonio en la Decisión 7 es obligatorio) y dónde se encuentran los documentos de referencia bajo demanda. Cada Decisión a continuación asume que estas reglas están vigentes. opencode.json lleva el mismo cableado de archivo de instrucciones para OpenCode.
• El bloque de permisos (.claude/settings.json permitir/denegar, opencode.json permiso) más los ganchos/plugin. Juntos, estos son la capa de seguridad de denegar y rechazar. El bloque de permisos dice "pregunta antes de hacer cosas peligrosas". Los ganchos (.claude/settings.json PreToolUse) y el plugin OpenCode (.opencode/plugins/course-eight-guardrails.js) dicen "en realidad, simplemente rechaza estas cosas, ni siquiera preguntes". Tres barreras de seguridad son deterministas en lugar de juicios del agente: negarse a confirmar un governance_ledger.json que lleva un puntero de base de datos de producción, rechazar las ediciones del course-seven-export/ de solo lectura y negarse a confirmar una clave de firma privada .pem. La combinación es la propiedad de seguridad adecuada: el error más catastrófico posible (filtrar la clave de firma privada de Maya a un repositorio público) está bloqueado estructuralmente.
• Los comandos de barra diagonal (.claude/commands/, .opencode/commands/). /verify-audit-trail y /verify-envelope son flujos de trabajo de verificación reutilizables que se guardan una vez para que no tengas que volver a escribir las instrucciones. Ejecutarás la verificación de seguimiento de auditoría después de la Decisión 6 y nuevamente después de la Decisión 7; ejecutarás la verificación del sobre siempre que quieras confirmar que el sobre local aún coincide con lo que Paperclip ha registrado.
• mocks/paperclip-mock.ts. El sustituto de Paperclip de ruta simulada. Se entrega con el lado de lectura funcionando: una verificación de estado, la cola de aprobación pendiente, una ruta básica de resolución humana, un asistente de prueba que inyecta una carga de trabajo y el escritor governance_ledger.json. La puerta de delegación firmada y los endpoints de registro de identidad se dejan deliberadamente como resguardos marcados, porque construirlos es las Decisiones 4 y 5. No los rellenes previamente; el laboratorio te guiará a través de él.
• course-seven-export/approvals.json. Decisiones de aprobación pasadas de Maya: la entrada de juicio de solo lectura de la Decisión 2 se importa, por lo que Claudia comienza con un modelo del juicio de Maya en lugar de aprender desde cero. Las barreras de seguridad rechazan activamente las ediciones aquí; modificarlo significaría que los patrones sembrados de Claudia ya no reflejan una historia real.
• docs/. Antecedentes del archivo de reglas @-referencias a pedido: el contexto de la arquitectura, el esquema del registro de gobernanza en base al cual se construyen las Decisiones 5 y 11 y notas de orientación sobre el sistema de skills OpenClaw. El agente los carga sólo cuando una Decisión los necesita, no de forma preventiva. Tu trabajo: descomprime el proyecto, luego en una terminal:

cd identic-ai-crash-course
git init

El git init no es negociable para los usuarios de OpenCode (su característica /undo requiere git). También se recomienda encarecidamente para los usuarios de Claude Code: las confirmaciones son la forma de guardar el progreso entre Decisiones y la solución daemon-stop en la Decisión 7 supone que el laboratorio tiene un seguimiento de git.

Luego abra la carpeta con tu agente de codificación:

• Claude Code: claude
• OpenCode: opencode

Verificando la configuración

Antes de comenzar la Decisión 1, ejecuta una verificación rápida de cordura dentro de Claude Code o OpenCode para confirmar las reglas cargadas.

En el mensaje de Claude Code, escribe:

What rules are you following for this session? List any instructions
from my project's CLAUDE.md file, and confirm the hooks block in
.claude/settings.json loaded.

Deberías ver Claude Code enumerar las reglas de laboratorio de CLAUDE.md y confirmar que los tres enlaces PreToolUse están activos. Si dice que no tiene instrucciones especiales o que los enlaces no están cargados, vuelve a verificar que abrió claude desde dentro del directorio identic-ai-crash-course/.

La disciplina de planificar y luego ejecutar

Cada decisión a continuación tiene dos fases: Planificar (investigación de solo lectura; producir un plan escrito; tú revisas) y Ejecutar (la herramienta se implementa después de que apruebas el plan). Esto no es negociable por tres razones:

1. Un plan que revisas tarda 30 segundos; revertir una implementación incorrecta lleva mucho más tiempo.
2. Los planes guardados en docs/plans/decision-N.md sobreviven a /clear y se pueden reanudar entre sesiones.
3. La división planificar-luego-ejecutar te permite ahorrar tokens (y dinero) planificando en un modelo de frontera y ejecutando uno barato (consulta el patrón de composición Planificar/Ejecutar del curso intensivo de codificación agéntica).

Para cada decisión: presiona Shift+Tab dos veces para entrar en el modo Plan (solo lectura). Resume los requisitos. Revisa el plan que produce Claude Code. Solicita que el plan se guarde en docs/plans/decision-N.md. Luego presiona Shift+Tab para salir del modo Plan y autorizar la ejecución.

Las Decisiones a continuación describen el resumen que le brinda a la herramienta: qué planificar y ejecutar. No repiten el flujo de trabajo Planificar y luego ejecutar cada vez; ese es ahora el procedimiento operativo permanente para el laboratorio.

---

Decisión 1: Instalar OpenClaw en la Mac de Maya

En una línea: instala OpenClaw en una Mac limpia, ejecuta openclaw onboard, recorra la configuración de persona/modelo/app de mensajería y verifica que la instalación funcione enviando un mensaje de "hola" a Claudia a través de Telegram.

Todo lo posterior depende de una instalación limpia de OpenClaw. Los fallos de laboratorio en las Decisiones 2 a 7 se remontan a una Decisión 1 parcialmente completada aproximadamente el 80% de las veces. El nombre de persona que elige aquí es el nombre que Claudia usará para siempre en su registro de gobernanza; el modelo que eliges afecta la calidad del razonamiento de Claudia en casos nuevos; la integración de la app de mensajería es su única interfaz para ella. Trata esto como una decisión fundamental, no como un paso preparatorio. El resumen. En tu herramienta de codificación agéntica, cambia al modo de plan, pega el resumen a continuación, solicita a la herramienta que produzca un plan escrito y lo guarde en docs/plans/decision-1.md, revísalo y luego sal del modo de plan para ejecutarlo.

Necesito instalar OpenClaw en una Mac nueva y seguir el flujo de incorporación. Según el sitio oficial en openclaw.ai y documentos en docs.openclaw.ai/getting-started. Requisitos:

1. Instala OpenClaw. Ejecuta curl -fsSL https://openclaw.ai/install.sh | bash (instala automáticamente Node.js y sus dependencias) o npm i -g openclaw si Node.js ya está configurado.
2. Ejecuta openclaw onboard --install-daemon y sigue las indicaciones. El indicador --install-daemon registra la puerta de enlace como un servicio en segundo plano administrado, por lo que los controles openclaw gateway stop y openclaw gateway start utilizados en la Decisión 7 en realidad tienen un servicio sobre el cual actuar.
3. Configuración de persona: nombre OpenClaw Claudia.
4. Selección de modelo: elige claude-opus-4-7 como modelo.
5. Integración de la app de mensajería: configura Telegram como la app de mensajería principal. Esto requiere crear un bot de Telegram a través de @BotFather y pegar el token del bot en el flujo integrado.
6. Verificación ida y vuelta: envía a Claudia un mensaje hello en Telegram y confirma que responde con el saludo personal configurado.
7. Informa: la ruta al directorio de configuración de OpenClaw (normalmente ~/.openclaw/), el nombre de usuario del bot de Telegram y cualquier mensaje integrado que solicita opciones más allá de lo especificado anteriormente (para saber qué valores predeterminados se eligieron). Qué esperar. Tu asistente produce el flujo de instalación + integración, verifica el viaje de ida y vuelta de Telegram e informa el estado de configuración. El resultado debe incluir:

• La ruta al directorio de configuración de OpenClaw en Mac de Maya (normalmente ~/.openclaw/)
• El nombre de usuario del bot que Maya usará para comunicarse con Claudia en Telegram.
• El modelo y la configuración de la persona confirmados.
• Un viaje de ida y vuelta exitoso: Maya envía un mensaje de "hola", Claudia responde personalmente

Solución de problemas:

• Homebrew solicita la contraseña de administrador en la primera ejecución. Esperado: requerido para las dependencias del sistema. Aprobar y continuar.
• La configuración de Telegram BotFather falla. Causa más común: Maya no tiene una cuenta de Telegram. Crea una primero (configuración gratuita de 2 minutos) y luego vuelve a ejecutar openclaw onboard.
• Claudia responde pero la persona es incorrecta. La configuración de persona del flujo integrado no se guardó. Vuelve a ejecutar la incorporación con el alcance de configuración restablecido: openclaw onboard --reset --reset-scope config.
• La instalación se bloquea al "descargar dependencias". Problema de red o DNS. Verifica con curl -fsSL https://openclaw.ai/health y verifica la instalación de Node.js por separado si eso falla.

Conclusión de la Decisión 1. Una instalación funcional de OpenClaw donde Maya puede enviar mensajes a Claudia en Telegram y obtener una respuesta personalizada. El directorio de configuración existe en el disco; el bot está registrado en Telegram; el modelo está fijado. Todo lo que se encuentra aguas abajo se conecta a esta base.

Si algo falla en las Decisiones 2 a 7, verifica estas tres cosas primero

En este orden; representan aproximadamente el 80% de las fallas de laboratorio durante la integración de OpenClaw + Paperclip.

1. OpenClaw no se instaló correctamente o la incorporación no se completó. Ejecuta openclaw status para verificar; Vuelve a ejecutar openclaw onboard si algo parece extraño. La causa más común de fallas misteriosas en las Decisiones 2 a 7 es una incorporación parcialmente completada de la Decisión 1.
2. Paperclip no se ejecuta o no se puede acceder a él desde la máquina de Maya. OpenClaw que se ejecuta en la Mac de Maya tiene que poder alcanzar el endpoint API de Paperclip. Si Paperclip está en una máquina diferente o en una red privada, verifica la conectividad con curl $PAPERCLIP_API_URL/api/health antes de asumir que la capacidad de integración no funciona.
3. La clave API del tablero de Identic AI no está en su lugar o la capa de delegación está incompleta. En la ruta completa, Claudia impulsa las rutas de aprobación reales con una clave API del tablero de Paperclip (Decisión 4): las rutas de aprobación llaman a assertBoard(), por lo que lo que aceptan es una credencial a nivel de tablero. Si esa clave del tablero falta o es incorrecta, Paperclip rechaza sus llamadas antes de que se ejecuta la capa de delegación. Por otra parte, también está registrada como agente de Paperclip con una entrada agent_api_keys, lo que le da una identidad y una superficie de revocación, pero no es lo que autentica la llamada de aprobación. Su propia capa de verificación (Decisión 5) verifica la certificación ed25519 y el sobre delegado; si esa capa está incompleta, las decisiones de Claudia nunca llegan a POST /api/approvals/{id}/approve.

Si ninguno de los tres explica la falla, consulta la etiqueta de GitHub del curso-ocho-números.

Decisión 2: incorporar la personalidad de Maya e importar su contexto de juicio

En una línea: configura a Claudia con la personalidad de Maya, el contexto del rol (ella es la directora ejecutiva de una empresa de atención al cliente nativa de IA) e importe cualquier historial disponible de sus decisiones de aprobación pasadas para que Claudia tenga un modelo inicial del juicio de Maya.

El concepto 10 nombra tres capas de contexto que Claudia acumula a lo largo del tiempo: instrucciones permanentes, retroalimentación por decisión y patrones derivados. La decisión 2 semillas las tres capas del registro histórico. Sin esta semilla, Claudia comienza desde cero y Maya tiene que pasar su primer mes enseñándole a Claudia desde cero mediante anulaciones. Con esta semilla, Claudia comienza el primer mes con aproximadamente 200 decisiones importadas de coincidencia de patrones; las anulaciones del primer mes de Maya refinan un modelo inicial que ya es creíble.

PRIMM: Predecir

Supongamos que Maya no tiene una exportación JSON limpia de tus aprobaciones anteriores: ha estado ejecutando Paperclip durante nueve meses pero nunca ha extraído el historial de decisiones. Tres opciones para sembrar a Claudia: (a) omitir la importación; deje que Claudia aprenda desde cero durante los próximos 30 días, (b) exporte un historial parcial (los últimos 30 días, fácil de compilar desde el registro de actividad de Paperclip) o (c) pase un sábado escribiendo el script de exportación completo. Predice qué opción recomienda el Curso Ocho y luego lee el informe.---

Respuesta: (b), historial parcial de los últimos 30 días. La opción (a) desperdicia el primer mes; Maya hace el trabajo de enseñar a Claudia sin el beneficio de tener a Claudia. La opción (c) es la respuesta correcta si Maya tiene tiempo, pero en realidad la mayoría de los propietarias no lo tendrán. La opción (b) es el punto medio pragmático: 30 días de historia importada le dan a Claudia un modelo inicial defendible en los tipos de decisiones de alto volumen (reembolsos, anulaciones de presupuesto) mientras que deja decisiones de bajo volumen (contrataciones de extensión de sobre, despidos) explícitas según las instrucciones permanentes en la Decisión 4. La sesión informativa del curso supone que (c) es alcanzable; si no es así, recurra a (b).

El resumen. En tu herramienta de codificación agéntica, cambia al modo de plan, pega el resumen a continuación, solicita a la herramienta que produzca un plan escrito y lo guarde en docs/plans/decision-2.md, revísalo y luego sal del modo de plan para ejecutarlo.

Claudia está instalada; ahora configúrala para el rol específico de Maya. Maya es la fundadora y directora ejecutiva de una empresa de atención al cliente nativa de IA creada a lo largo de los cursos cinco a siete. La empresa cuenta con cuatro Workers: soporte de nivel 1, especialista de nivel 2, gerente-agente y especialista legal, administrados a través de Paperclip. Requisitos:

1. Crea un documento personal en el espacio de trabajo del agente de OpenClaw (~/.openclaw/workspace/). OpenClaw lee USER.md en el espacio de trabajo como contexto duradero sobre la usuaria, así que escribe la persona de Maya en ~/.openclaw/workspace/USER.md (o un archivo context/ al que se haga referencia desde él), capturando:

• Función de Maya (fundadora/CEO de una empresa de atención al cliente nativa de IA)
• La nómina de Workers actual de la empresa y lo que hace cada Worker
• Estilo de comunicación de Maya (conciso, directo, intercalado por comas)
• Umbrales de política conocidos de Maya de los cursos cinco a siete (límite de reembolso $500, límite de presupuesto mensual predeterminado $1,000, política de aprobación automática del concepto 9 del Curso Siete activa)

2. Importar el historial de aprobación anterior de Maya. Hay una exportación JSON en ./course-seven-export/approvals.json que contiene decisiones de aprobación históricas. La memoria persistente de OpenClaw es el espacio de trabajo, no un almacén de importación separado, así que coloque el archivo en el espacio de trabajo (por ejemplo ~/.openclaw/workspace/context/approvals.json) y haga referencia a él desde USER.md o MEMORY.md para que OpenClaw lo indexe como contexto duradero. Consulta docs.openclaw.ai/concepts/session.
3. Verificación de ida y vuelta: a través de Telegram, pregunta a Claudia "¿qué sabes sobre cómo apruebo reembolsos?" y confirma que ella devuelve una respuesta plausible extraída del historial importado (no un patrón genérico del asistente de IA; la respuesta debe hacer referencia a patrones específicos de las decisiones importadas).
4. Informa: el nombre de la habilidad de importación, la ubicación en el disco de los datos de la sesión cargados y una transcripción del viaje de ida y vuelta de verificación.

Qué esperar. Tu asistente produce:

• La personalidad de Maya escrita en ~/.openclaw/workspace/USER.md (legible por humanos; Maya puede revisar y editar)
• approvals.json colocado en el espacio de trabajo como un archivo de contexto duradero, al que se hace referencia desde USER.md o MEMORY.md para que Claudia se base en él.
• Un viaje de verificación de ida y vuelta: mensajes de Maya "¿qué sabes sobre cómo apruebo reembolsos?" y Claudia responde con un resumen como "Basado en sus decisiones pasadas, apruebas alrededor del 94% de los reembolsos por debajo de $500 sin comentarios, alrededor del 70% en el rango de $500 a $1,500 con apariciones ocasionales y casi todos los reembolsos por encima de $1,500..." La redacción exacta varía; lo que importa es que Claudia se base en los datos importados, no en el patrón genérico del asistente de IA.

Solución de problemas:

• _No approvals.json exportación disponible._Utiliza el respaldo previsto por PRIMM (b): escribe un script más pequeño para extraer los últimos 30 días de la tabla activity_log de Paperclip, filtrando por actor_type = 'user' y action en (approval.approved, approval.rejected, approval.revision_requested); el detalle por decisión se encuentra en la columna details jsonb.
• La respuesta de verificación de Claudia es genérica ("Aún no conozco el historial de aprobación"). El archivo de contexto no está en el espacio de trabajo o no se hace referencia a él desde USER.md/MEMORY.md. Confirma que approvals.json esté bajo ~/.openclaw/workspace/, que un archivo de espacio de trabajo apunte a él y que el JSON haya sido analizado (un error común es un campo de marca de tiempo con formato incorrecto). Reinicie la puerta de enlace o inicie una nueva sesión para que OpenClaw vuelva a indexar el espacio de trabajo.
• El archivo de persona tiene algún error. Edite maya.md directamente. Claudia lo relee en la siguiente interacción. Conclusión de la Decisión 2. Claudia sabe quién es Maya, cómo es la empresa y tiene un modelo inicial de las decisiones de aprobación anteriores de Maya. La Capa 1 (instrucciones permanentes) se establecerá en la Decisión 4; la capa 2 (retroalimentación) se acumula a medida que Maya opera; la capa 3 (patrones derivados) se acumula desde la semilla histórica en adelante.

Decisión 3: Desarrollar la skill de integración de Paperclip

En una línea: escribe una habilidad de OpenClaw que permita a Claudia leer la cola de aprobación de Paperclip, firmar decisiones de aprobación con la clave de Identic AI de Maya y publicarlas nuevamente en la API de Paperclip.

Esta es la habilidad de caso estructural: la que convierte a Claudia de "una IA personal con la que Maya puede chatear" en "la Identic AI de Maya configurada para la gobernanza". La habilidad es el puente entre la arquitectura de sesión y habilidad de OpenClaw (Conceptos 5-6) y la API de aprobación de Paperclip (Curso Seis). También es la habilidad que contiene la mayor parte de su propio código de integración, tanto la habilidad de OpenClaw como la capa de firma y verificación que envuelve la API de Paperclip. Dedique tiempo a hacerlo bien; las decisiones 4 a 7 se basan en esto.

Las tres responsabilidades de la habilidad, claramente separadas:

1. Encuesta para aprobaciones pendientes. Ya sea cada 60 segundos (estilo cron) o a pedido cuando Maya le envía un mensaje a Claudia. La cadencia de las encuestas es una compensación: más rápido significa menor latencia en las aprobaciones de rutina; más lento significa una menor carga de API en Paperclip. 60 segundos es un valor predeterminado defendible.
2. Razón de cada aprobación. Para cada elemento pendiente, Claudia usa su personalidad (Decisión 2) más instrucciones permanentes (Decisión 4) más patrones acumulados (a lo largo del tiempo, Concepto 10) para decidir: aprobar, solicitar revisión o mostrarle a Maya.
3. Firma y publica la decisión. Cuando Claudia decide aprobar, la skill firma el payload de la decisión con la clave de firma de Identic AI de Maya (generada en la Decisión 4). Adónde va luego la decisión es la única parte que diverge según la ruta; consulta la división a continuación.

Ruta simulada

Responsabilidad de 3 publicaciones en la ruta única de resolución del mock. El mock en mocks/paperclip-mock.ts mantiene una forma simplificada: una ruta POST .../approvals/{id}/resolve representa todo el flujo de decisiones. Eso está bien para un sustituto; la lógica de ruta real se construye solo en la ruta completa.

Ruta de implementación completa

Responsabilidad 3 puestos a la ruta real Paperclip. Paperclip 2026.513.0 no tiene el verbo resolve: los verbos de decisión son approve, reject y request-revision, cada uno con tu propia subruta POST. Cuando Claudia decide aprobar, la habilidad llama a POST /api/approvals/{approvalId}/approve (con un decisionNote opcional). Estas rutas llaman a assertBoard(): aceptan una clave API de tablero de Paperclip, no una clave de agente. Entonces, la credencial con la que publica la habilidad es la clave API del tablero que Maya acuñó para Claudia en la Decisión 4. (Una clave de agente obtiene un 403 "Se requiere acceso al tablero" en estas rutas; es por eso que la credencial de delegación tiene un alcance de tablero). La firma ed25519 es tu propia capa de certificación, no algo que PaperPaperclip verifica. Su capa de verificación (Decisión 5) lo verifica y verifica el sobre delegado_antes_ de que la habilidad llama a la ruta real.

El resumen. En tu herramienta de codificación agéntica, cambia al modo de plan, pega el resumen a continuación, solicita a la herramienta que produzca un plan escrito y lo guarde en docs/plans/decision-3.md, revísalo y luego sal del modo de plan para ejecutarlo.

Desarrolla la skill estructural que le permite a Claudia hablar con Paperclip. Instalable a través del sistema de skills de OpenClaw según docs.openclaw.ai/skills. Tres responsabilidades, claramente separadas. Requisitos:

1. Sondeo de aprobaciones pendientes. Accede a la cola de aprobaciones pendientes cada 60 segundos (configurable) o permite invocarla a pedido cuando Maya le envía un mensaje a Claudia. Ruta completa: GET /api/companies/{companyId}/approvals?status=pending. Ruta simulada: ruta de cola equivalente del mock.
2. Razón sobre cada aprobación pendiente. Para cada elemento, pregúntale a Claudia (usando la interfaz de razonamiento de OpenClaw) si quiere aprobar, solicitar revisión o mostrarle a Maya. Usa el contexto personal de Claudia, las instrucciones permanentes que Maya le ha dado (Capa 1) y los patrones de retroalimentación por decisión (Capa 2) de su sesión.
3. Firma y publica la decisión. Cuando Claudia decida aprobar, firma el payload de la decisión con la clave de firma de Identic AI de Maya (ruta de marcador de posición por ahora; la clave real se genera en la Decisión 4). Luego publica: en la ruta completa, POST /api/approvals/{approvalId}/approve con un decisionNote opcional (la llamada se autentica mediante la clave API de tablero de Paperclip de Claudia, acuñada en la Decisión 4; las rutas de aprobación requieren acceso al tablero, no una clave de agente); en la ruta simulada, la ruta única POST .../approvals/{id}/resolve del mock. La firma es tu propia capa de atestación; la verificación completa llega en la Decisión 5.
4. Metadatos de habilidades. Nombra la habilidad paperclip-governance-delegate. El archivo de configuración debe exponer estos parámetros:

• PAPERCLIP_API_URL
• PAPERCLIP_COMPANY_ID
• polling_interval_seconds (predeterminado 60)
• signing_key_path (predeterminado ~/.openclaw/keys/identic-ai.pem)

5. Instalación: una skill creada localmente se encuentra en el directorio de skills del espacio de trabajo, en ~/.openclaw/workspace/skills/paperclip-governance-delegate/SKILL.md (el frontmatter YAML más un cuerpo en Markdown; el nombre de la carpeta debe coincidir con la habilidad name). OpenClaw lo descubre en la siguiente sesión nueva o después de openclaw gateway restart. (openclaw skills install es para extraer habilidades de ClawHub por nombre, no para habilidades locales). Confirma con openclaw skills list.
6. Modo de ejecución en seco (crítico). Incluya una marca --dry-run que sondee y razone en función de la cola de aprobación real de Paperclip, pero solo registre lo que Claudia haría, sin publicar realmente las decisiones. Maya usa esto durante la primera semana como un período de creación de confianza antes de comenzar a funcionar.
7. Informa: la estructura del directorio de habilidades, la ruta del manifiesto, la confirmación de que openclaw skills list muestra la habilidad y un registro de prueba de muestra. Qué esperar. Tu asistente produce:

• Un directorio de habilidades ./paperclip-governance-delegate/ que contiene el manifiesto de habilidades, el ciclo de sondeo, la plantilla de mensaje de razonamiento por aprobación y la lógica de firma y publicación (con un marcador de posición donde se conectará la clave real de la Decisión 4)
• Un archivo de configuración (por ejemplo, config.yaml) con los parámetros expuestos
• El modo --dry-run que inicia sesión en stdout/file pero no publica: crítico para el período de confianza de la primera semana
• La habilidad instalada localmente y visible en openclaw skills list

Solución de problemas:

• La habilidad se instala pero no se ejecuta. Las skills de OpenClaw requieren un manifiesto SKILL.md (frontmatter YAML más cuerpo en Markdown) en la raíz de la habilidad; verifica ~/.openclaw/workspace/skills/paperclip-governance-delegate/SKILL.md, confirma que name en el frontmatter coincida con el nombre de la carpeta y reinicia la puerta de enlace para que OpenClaw vuelva a indexar el espacio de trabajo.
• La encuesta se hace correctamente pero no arroja aprobaciones cuando debería haber otras pendientes. Verifica que PAPERCLIP_COMPANY_ID coincida con la empresa que configuró en el Curso Siete; verifica que se pueda acceder a la URL de la API desde la máquina de Claudia.
• El mensaje de razonamiento de Claudia produce resultados inconsistentes en aprobaciones similares. La plantilla de razonamiento necesita más estructura; agregar controles explícitos para las instrucciones vigentes antes de invocar el juicio basado en la persona.

Conclusión de la Decisión 3. La habilidad está instalada, configurada y operativa en modo de prueba. Claudia puedes leer la cola de aprobación y tomar decisiones razonadas para cada elemento; todavía no puede publicarlos porque la clave de firma aún no existe. La decisión 4 hace que la publicación sea real.

Decisión 4: Generar la clave de firma de Identic AI de Maya y configurar el sobre delegado

En una línea: genera el par de claves criptográficas para Claudia, acuña la clave API del tablero Paperclip con la que impulsará las rutas de aprobación, regístrala como agente de Paperclip para identidad y revocación y configura el sobre delegado de Claudia (los umbrales sobre los que se le permite actuar de forma autónoma frente a lo que debe mostrar a Maya).

En esta Decisión se incluyen dos primitivas arquitectónicas: la identidad criptográfica (Concepto 8) y el sobre delegado (Concepto 9). Ambos se configuran una vez y se revisan periódicamente; ambos dan forma a cada decisión posterior que toma Claudia. El sobre delegado es especialmente sensible: demasiado ancho y Claudia toma acciones que Maya hubiera querido ver; demasiado estrecho y la propiedad de escala del octavo invariante no se activa.

PRIMM: Predecir

Maya está configurando el sobre delegado de Claudia por primera vez. El instinto de Maya es empezar de manera conservadora: techo de reembolso bajo, superficie de casi todo. Un colega (su cofundadora) sostiene lo contrario: empiece de manera amplia y deje que las anulaciones de Maya reduzcan a Claudia con el tiempo. Prediga qué enfoque recomienda el Curso Ocho y cuál será la consecuencia operativa durante el primer mes.

---

Respuesta: El Curso Ocho recomienda comenzar de manera conservadora, pero con un plan de ampliación deliberado. Razones: (a) las anulaciones son caras para Maya: cada anulación es un cambio de contexto y un mensaje de retroalimentación; si el sobre de Claudia es demasiado amplio, el primer mes será una avalancha de anulaciones que frustrarán el propósito. (b) Los comienzos conservadores permiten que Maya observe el razonamiento de Claudia antes de confiarle más decisiones. (c) Ampliar es más fácil que ajustar operativamente: Maya agrega una instrucción de Capa 1 "ahora puedes aprobar automáticamente reembolsos hasta $X" y Claudia se ajusta inmediatamente; el ajuste requiere ediciones más matizadas de las instrucciones de pie. Consecuencia operativa para el primer mes: tasa de superficie de alrededor del 20 al 25 % (alta pero limitada), tasa de anulación de alrededor del 3 al 5 % y ambas cifras caerán en el mes 2 a medida que Maya amplía el alcance deliberadamente. La trayectoria del recorrido de seis meses del Concepto 10 supone este comienzo conservador.

El resumen. En tu herramienta de codificación agéntica, cambia al modo de plan, pega el resumen a continuación, solicita a la herramienta que produzca un plan escrito y lo guarde en docs/plans/decision-4.md, revísalo y luego sal del modo de plan para ejecutarlo.

Generar la identidad criptográfica de Claudia y configurar su sobre delegado. En esta Decisión se incluyen dos primitivas arquitectónicas: la clave de firma (Concepto 8) y el sobre delegado (Concepto 9). Requisitos:

1. Genera un nuevo par de claves ed25519. Guarda la clave privada en ~/.openclaw/keys/identic-ai.pem con permisos estrictos (chmod 600). Almacena la clave pública por separado; tu propia capa de verificación (Decisión 5) la utiliza para verificar las declaraciones de Claudia.
2. Almacenamiento respaldado por hardware opcional (solo macOS). Si Maya está en macOS y desea protección respaldada por hardware, use el marco de seguridad para almacenar la clave privada en el llavero en lugar de en el sistema de archivos; la ruta se convierte en una referencia de llavero.
3. Crea la clave API del tablero y luego registra a Claudia como agente. Seguimiento completo, dos credenciales distintas:

• La clave API de la junta es la credencial de delegación. Paperclip tiene una tabla board_api_keys real y las rutas de aprobación llaman a assertBoard(), por lo que lo que aceptan es una credencial a nivel de junta. Minting one no es un solo verbo CLI: es el flujo de desafío de autenticación CLI de Paperclip. POST /api/cli-auth/challenges con {"requestedAccess": "board"} devuelve un boardApiToken (un valor pcp_board_...) más un approvalUrl; Maya abre esa URL en el panel de Paperclip para aprobar el desafío y el token está activo. (En una implementación de desarrollo local_trusted, el token se emite inmediatamente; en una implementación real, el paso de aprobación del panel es la puerta humana). Ese boardApiToken es lo que Claudia sostiene y publica. Conceptualmente, esta clave del tablero es la delegación: Maya le entrega a tu Identic AI una credencial a nivel de tablero, deliberadamente delimitada por tu propia capa de delegación (Decisión 5), no por Paperclip.
• El registro del agente es identidad más una superficie de revocación. Registra a Claudia como un agent de Paperclip real (una fila en agents) y emita una entrada agent_api_keys. Esto le da una identidad Paperclip y algo que Maya puede revocar en la Decisión 7.No es lo que autentica la llamada de aprobación. Restricciones reales a respetar: agents.role es una enumeración validada por el servidor sin valor identic_ai, usa general; adapterType está validado por enumeración (claude_local, acpx_local, codex_local, ...), no claude_code; y no hay un verbo CLI paperclipai agent create, la creación del agente es solo API a través de POST /api/companies/{companyId}/agents (el verbo paperclipai agent local-cli <ref> solo crea una clave para un agente que ya existe).
• Registre el sobre delegado como una fila principal_permission_grants cuyo scope jsonb contiene los umbrales del sobre. Paperclip almacena esto; no lo aplica en la ruta de aprobación (su capa de Decisión 5 sí lo hace).

Ruta simulada: llama al endpoint de registro stub del mock, que devuelve un ID de principal y almacena la envolvente por ti. En ambos casos, la clave pública queda registrada para que tu capa de verificación pueda verificar las firmas de Claudia.

4. Sobre delegado inicial conservador. Maya puede ampliarlo más adelante mediante instrucciones permanentes. Codifique estos umbrales:

• Reembolsos: aprobación automática hasta $2,000; superficie cualquier cosa sobre
• Contrataciones dentro del sobre existente: aprobación automática
• Contrataciones que amplían el sobre de la empresa: siempre mostrar a Maya
• Terminaciones: siempre mostrar a Maya
• Anulaciones de presupuesto: aprobación automática hasta un 20 % por encima del límite mensual; mostrar cualquier cosa por encima
• Migraciones CMA: superficie del primer trimestre; aprobación automática posterior solo para Workers con presupuesto $1,000/mo
• Ediciones de políticas permanentes: siempre mostrar a Maya

5. Paso de confirmación de Maya (requerido antes de enviar). Envía a Maya un mensaje de Telegram a través de Claudia: "Aquí está el sobre delegado propuesto: [resumen JSON]. Responde CONFIRM para registrarlo, o envía ediciones". Envía el registro solo con la respuesta CONFIRM de Maya.
6. Conserva las credenciales y los identificadores. Si el registro es exitoso, almacena en la sesión de Claudia: la clave API de tablero con la que publica las decisiones de aprobación, su ID de agente registrado (ruta completa) o el ID de principal del mock (ruta simulada), y el ID de principal_permission_grants de la envolvente. La skill de la Decisión 3 usa la clave de tablero al publicar; la Decisión 7 usa el ID del agente y el ID de agent_api_keys al revocar.
7. Escribe el sobre en el disco. Guarda el JSON del sobre final en ~/.openclaw/governance/delegated-envelope.json para que Maya pueda editarlo directamente más tarde cuando amplíe o reduzca la autoridad de Claudia.
8. Informa: la huella digital de la clave (no la clave privada), la referencia del llavero si se usa, el ID de la clave API de tablero, el ID del agente registrado, el ID de agent_api_keys y la transcripción del ida y vuelta CONFIRM de Maya.

Qué esperar. Tu asistente produce:

• Un par de claves ed25519 nuevo, clave privada en la ruta configurada con 600 permisos (o en el Llavero si Maya eligió esa opción)
• Integración opcional de macOS Keychain si Maya está en Mac y elige almacenamiento respaldado por hardware
• Un Telegram de ida y vuelta mostrándole a Maya el sobre propuesto y obteniendo su CONFIRMA
• Ruta completa: una clave API de tablero de Paperclip acuñada (la credencial de delegación), Claudia registrada como agente de Paperclip con una entrada agent_api_keys (identidad más superficie de revocación) y la envolvente delegada almacenada como una fila principal_permission_grants. Ruta simulada: registro en el stub del mock.
• El sobre persistió en ~/.openclaw/governance/delegated-envelope.json para edición directa.

Solución de problemas:

• No hay ningún endpoint de registro de identidad al que llamar. Ruta completa: no hay ningún endpoint personalizado de Paperclip que inventar aquí. Crea la clave API de tablero de board_api_keys, registra a Claudia con la primitiva de agente real de Paperclip (POST /api/companies/{companyId}/agents, luego emite una entrada agent_api_keys) y registra la envolvente delegada como una fila principal_permission_grants. No hay ningún verbo CLI paperclipai agent create; la creación de agentes es solo API. La Decisión 5 crea tu propia capa de verificación que los lee, no una ruta nueva de Paperclip. Ruta simulada: el mock envía un endpoint de registro stub; si devuelve 404, ese stub es lo que implementas (es parte del trabajo de la ruta simulada, no de la ruta completa).
• Registro de agente rechazado en role o adapterType. Ambas son enumeraciones validadas por el servidor. role no tiene valor identic_ai; usa general. adapterType es uno de claude_local, acpx_local, codex_local y similares, no claude_code. El personaje de "Identic AI" de Claudia vive en tu governance_ledger, no en las enumeraciones de agentes de Paperclip.
• Maya no CONFIRMA; quiere editar el sobre. Esperado y bien. Los defaults conservadores son puntos de partida; Maya puede tener valores específicos de sus operaciones. Vuelve a enviar el sobre propuesto con sus ediciones y vuelve a solicitar CONFIRMAR.
• Error de permisos clave (falla chmod 600). Problema a nivel del sistema de archivos; compruebe que el directorio ~/.openclaw/keys/ sea propiedad del usuario de Maya.

Conclusión de la Decisión 4. La Identic AI de Maya ahora posee una clave API del tablero Paperclip (la credencial con la que maneja las rutas de aprobación) y está registrada como agente de Paperclip (su identidad y superficie de revocación), llevando un sobre delegado configurado registrado en Paperclip pero aplicado por tu propia capa de Decisión 5. La sobre inicial conservadora significa que el primer mes se sentirá "pesado en la superficie": ese es el punto. La ampliación se produce deliberadamente mediante ediciones de instrucciones permanentes, no mediante un exceso de permisos inicial.

Decisión 5: construir la capa de delegación y verificación

En una línea: crea la capa que hace que las credenciales de Claudia sean significativas, los controles que verifican su atestación ed25519 y verifican la envolvente delegada antes de que cualquier decisión llegue a Paperclip, además de tu propia tabla governance_ledger. En la ruta completa, esta capa vive en su skill de integración y envuelve las rutas de aprobación reales de Paperclip; en la ruta simulada vive en el mock.

Las decisiones 1 a 4 prepararon a Claudia y le dieron sus credenciales; la Decisión 5 hace que esas credenciales sean significativas. Aquí es donde la primitiva de delegación de confianza (Concepto 7), la verificación de delegación firmada (Concepto 8) y la intersección de dos sobres (Concepto 9) se convierten en código activo. Sin la Decisión 5, Claudia puede firmar todas las decisiones que quiera: nada verifica la firma ni revisa el sobre, por lo que una decisión firmada es solo una llamada API sin verificar.

PRIMM: Predecir

Antes de construir la capa de verificación, prediga la respuesta al hecho más contradictorio al respecto. En la Decisión 4, acuñó dos credenciales de Paperclip para Claudia: una clave API de junta y una clave API de agente. Uno de ellos es la credencial que realmente utiliza para impulsar las rutas de aprobación reales (POST /api/approvals/{id}/approve y amigos). La otra es sólo su identidad y una superficie de revocación.

Predice: ¿cuál impulsa las rutas de aprobación, la clave API de la junta o la clave API del agente? ¿Y por qué sería ese, dado que Claudia es una agente, no miembro de la junta directiva?

---

Respuesta: la clave API de tablero. Esta es la parte contraintuitiva. Todas las rutas de aprobación de Paperclip (approve, reject, request-revision) llaman a assertBoard(): aceptan una credencial de nivel tablero y nada más. Una clave API de agente, incluso la de Claudia, recibe un 403 "Board access required" en estas rutas. Por lo tanto, la credencial que permite a Claudia tomar una decisión de aprobación debe tener alcance de tablero. Esa es exactamente la razón por la que la Decisión 4 hizo que Maya acuñara una clave API de tablero para Claudia: la clave de tablero, reducida deliberadamente por tu propia capa de delegación, es la delegación. El registro de agente le da a Claudia una identidad de Paperclip y algo que Maya puede revocar en la Decisión 7, pero no autentica la llamada de aprobación. Si construyes la capa de verificación esperando que una clave de agente funcione en las rutas de aprobación, cada una de las decisiones de Claudia terminará en 403 antes de que se abran sus controles. (Ruta simulada: la ruta única /resolve del mock no impone esta distinción; es una realidad de la ruta completa. La ruta simulada aun así la enseña, así que tu modelo mental será correcto si luego completas la implementación).

Un ancla concreta antes de las reglas. La explicación más clara de cómo se comporta toda esta capa es un reembolso de rutina recorrido de un extremo a otro, a través del razonamiento de Claudia, las tres puertas, la llamada real de Paperclip y ambas filas de auditoría. Lee esta traza primero; luego las tres puertas y la referencia de ruta de abajo se leen como una búsqueda, no como algo para absorber en frío. La traza se muestra en su forma de implementación completa: rutas reales de Paperclip, columnas activity_log reales. Las entradas son ilustrativas: sintetizadas para mostrar la forma de los datos, no exportadas desde una implementación en ejecución. (En la ruta simulada, los pasos son los mismos en espíritu, pero la ruta única /resolve del mock y las formas de filas simplificadas reemplazan la superficie real de Paperclip).

Un reembolso de rutina pasa de pendiente a una decisión registrada en aproximadamente 40 segundos, completamente autónomo y completamente auditado, con dos filas de auditoría conectables y cero interrupciones humanas.

1. La aprobación llega a Paperclip. Un reembolso por encima del límite máximo del sobre se modela como una aprobación request_board_approval, con el detalle del reembolso dentro del jsonb payload (la enumeración type de aprobación de Paperclip es hire_agent, approve_ceo_strategy, budget_override_required, request_board_approval; no hay ningún tipo refund). Ten en cuenta que no hay una columna issueIds de nivel superior en approvals: los enlaces de problemas se encuentran en la tabla de unión issue_approvals separada y el servicio completa details.linkedIssueIds cuando se escribe la fila.

{
  "id": "apr_01HZ4Q...",
  "companyId": "co_maya...",
  "type": "request_board_approval",
  "status": "pending",
  "requestedByAgentId": "worker_tier1_support",
  "payload": {
    "kind": "refund",
    "amountCents": 89000,
    "currency": "USD",
    "customerId": "C-3421",
    "accountAgeDays": 1167,
    "priorRefunds6mo": 0,
    "reason": "billing-error-duplicate-charge"
  },
  "createdAt": "2026-05-12T09:14:03.117Z"
}

2. La habilidad de sondeo de Claudia mejora (de la Decisión 3; la cadencia de sondeo es de aproximadamente 60 segundos):

[2026-05-12T09:14:42] claudia.skill.paperclip-governance-delegate:
  poll GET /api/companies/co_maya/approvals?status=pending → found 1 pending (apr_01HZ4Q...)
  routing to per-approval reasoning prompt

3. Razones de Claudia (de la plantilla de mensaje de razonamiento por aprobación, Decisión 3):

[2026-05-12T09:14:42] claudia.reasoning:
  input: approval=apr_01HZ4Q..., payload.kind=refund, amount=$890, customer_age=3.2yr, prior_refunds=0
  layer-1 check (standing instructions):
    - "auto-approve refunds under $2,000 with no prior refunds and account >2yr" → MATCH
  layer-3 pattern (derived):
    - "Maya tends to approve fast in this band; ~91% historical match" → REINFORCES
  decision: approve
  confidence: 0.91
  reasoning_summary: "Long-tenure customer (3.2yr), no prior refunds, amount within
                     delegated envelope ($2,000 ceiling), pattern reinforces standing rule."

4. La capa de delegación de Claudia firma y bloquea la decisión (las tres puertas de la Decisión 5, se ejecutan antes de cualquier llamada a Paperclip):

[2026-05-12T09:14:43] delegation-layer.gate-check:
  signed decision payload with ed25519 (signature ed25519:k7n2m...8q3w)
  gate 1: signer's credentials recognized and unrevoked (board API key bk_claudia_maya;
          agent ag_claudia_maya registered) → PASS
  gate 2: ed25519 signature verifies against Claudia's registered public key → PASS
  gate 3: delegated envelope (principal_permission_grants.scope):
    payload.kind=refund, amount=$890, ceiling=$2,000 → IN ENVELOPE → PASS
  all gates passed → calling the real Paperclip route

5. La capa de delegación llama a la ruta de aprobación real de Paperclip (POST /api/approvals/{approvalId}/approve, autenticada por la clave API del tablero de Claudia, porque la ruta de aprobación requiere acceso al tablero):

[2026-05-12T09:14:43] delegation-layer.post:
  POST /api/approvals/apr_01HZ4Q.../approve
  auth: Claudia's board API key
  body: { "decisionNote": "auto-approved by Owner Identic AI; attestation ed25519:k7n2m...8q3w" }
  → 200 OK  (the approval's status is now 'approved'; this is a recorded decision,
             it does not move issue iss_3421 or resume a Worker)

6. Paperclip escribe la fila activity_log (columnas reales; la ruta de aprobación es una acción del tablero, por lo que la fila es actor_type='user', no actor_type='agent'):

{
  "id": "act_8z2k...",
  "company_id": "co_maya...",
  "actor_type": "user",
  "actor_id": "local-board",
  "agent_id": null,
  "action": "approval.approved",
  "entity_type": "approval",
  "entity_id": "apr_01HZ4Q...",
  "details": {
    "type": "request_board_approval",
    "linkedIssueIds": ["iss_3421"],
    "decisionNote": "auto-approved by Owner Identic AI; attestation ed25519:k7n2m...8q3w"
  },
  "created_at": "2026-05-12T09:14:43.298Z",
  "run_id": null
}

Esta fila se ve exactamente como una que Maya escribiría resolviendo ella misma la aprobación. Paperclip no puede distinguirlos; la siguiente fila, en su propio governance_ledger, es la que lleva la distinción.

7. Tu governance_ledger escribe la fila paralela de Claudia (tu propia tabla aditiva, esquema en docs/governance-ledger-schema.sql):

{
  "ledger_id": "gov_2k8z...",
  "approval_id": "apr_01HZ4Q...",
  "principal": "owner_identic_ai",
  "acting_on_behalf_of": "owner_human_maya",
  "signer_agent_id": "ag_claudia_maya",
  "action_taken": "approve",
  "confidence": 0.91,
  "layer_source": "standing_instruction",
  "layer_reference": "si_refund_under_2000_long_tenure_no_priors",
  "reasoning_summary": "Long-tenure customer (3.2yr), no prior refunds, amount within delegated envelope, pattern reinforces standing rule.",
  "attestation": "ed25519:k7n2m...8q3w",
  "override_status": null,
  "timestamp": "2026-05-12T09:14:43.298Z"
}

Total transcurrido: unos 40 segundos desde la aprobación pendiente hasta la decisión registrada (principalmente la latencia del razonamiento de Claudia más la criptografía de firma). Maya no fue interrumpida. Las dos filas, la fila activity_log de Paperclip (una acción del tablero, actor_type='user') más su fila governance_ledger con principal='owner_identic_ai', hacen que la decisión sea recuperable más tarde: Maya puede hacer consultas SQL en ambas tablas (unidas por el ID de aprobación) para reconstruir exactamente lo que hizo Claudia y por qué. La disputa de Paperclip por sí sola no puede decirle si ella o Claudia lo resolvieron; la fila governance_ledger es la que responde a eso. Observe lo que el paso 5 no hizo: registró una decisión; no movió el problema iss_3421 ni reanudó un Worker. Hacer avanzar ese problema es un paso explícito independiente (PATCH /api/issues/iss_3421 para establecer su estado o asignar un Worker para que lo recoja), exactamente como se enseñó en los cursos seis y siete.

Esa es toda la capa en un solo trazo. Los pasos 4, 5 y 7 son exactamente lo que construye la Decisión 5: las tres puertas, la llamada real de Paperclip y la escritura governance_ledger. El resto de la Decisión 5 son las reglas detrás de ese seguimiento: primero las tres puertas en detalle, luego la referencia de ruta como una tabla de búsqueda que puedes escanear cuando la necesitas, no algo para leer linealmente.

Aquí las dos rutas divergen marcadamente. Lee el bloque de tu ruta.

Ruta simulada

Implementas los endpoints de control e identidad en el mock local en mocks/paperclip-mock.ts, donde el control de delegación firmada y el endpoint stub de registro ya están marcados como stubs para que los completes. El mock mantiene una forma simplificada: una única ruta POST .../approvals/{id}/resolve representa todo el flujo de decisión y el propio mock recorre los tres controles antes de resolver. Este es el contenido de trabajo con el que se construyó y probó la ruta simulada; constrúyelo exactamente como están dispuestos los stubs del mock.

El siguiente brief, en su forma simulada: modifica el stub /resolve del mock para aceptar un signature y signer_principal_id, ejecuta los tres controles (firmante registrado, firma verificada, acción dentro de la envolvente almacenada) y, si tiene éxito, escribe tanto una entrada simulada de activity_log como una fila de governance_ledger.json. Implementa los endpoints stub de registro y revocación del mock. Luego salta a las notas compartidas de "qué esperar" más abajo.

Ruta de implementación completa

El trazo trabajado de arriba mostró la capa en ejecución. Este bloque son las reglas detrás de él, en tres partes: (A) lo que construyes, (B) las tres puertas en detalle, (C) la referencia de ruta como una tabla de búsqueda. Lee A y B; hojea C y vuelve a él cuando transfieras las llamadas reales.

Parte A: lo que construyes (y lo que no). No hay nuevos endpoints de Paperclip que construir. Paperclip 2026.513.0 ya posee las rutas de aprobación, la tabla board_api_keys, el registro agents, agent_api_keys, principal_permission_grants y activity_log. Lo que construyes en la Decisión 5 es tu propia capa de delegación dentro de la skill paperclip-governance-delegate, más tu propia tabla aditiva governance_ledger. Paperclip nunca verifica una firma y nunca aplica la envolvente delegada en la ruta de aprobación; tu capa hace ambas cosas y solo entonces llama a la ruta real de Paperclip con la clave API de tablero de Claudia. Parte B: los tres controles, en orden, para cada decisión que llega a Claudia. Estos son los pasos 4 y 5 de la traza trabajada, en detalle.

1. Control 1, el firmante es un principal reconocido. Confirma que las credenciales de Claudia siguen siendo válidas: su clave API de tablero (con la que publica) está presente y no está revocada, y su fila registrada en agents más la entrada agent_api_keys todavía existen (la Decisión 7 revoca aquí). Una clave de tablero revocada obtiene un 403 en las rutas de aprobación; una clave de agente revocada falla en las rutas solo para agentes. Este control falla rápido y queda auditable en tu governance_ledger.
2. Control 2, verificación de firma. Verifica la firma ed25519 de Claudia sobre el payload de decisión en JSON canónico contra su clave pública registrada. Esta es tu propia capa de atestación; prueba que la decisión provino de la clave de Claudia y no fue manipulada. Paperclip no tiene campo de firma, así que este control existe solo en tu capa.
3. Control 3, envolvente delegada. Lee la envolvente delegada del jsonb principal_permission_grants.scope de Claudia y prueba que la acción declarada (tipo, importe) esté dentro de ella. Paperclip almacena esta fila pero no la aplica en la ruta de aprobación, así que este control es la disciplina de tu capa, no un límite impuesto por Paperclip. La autoridad aplicada es la intersección de la envolvente de la propietaria y este subconjunto delegado (Concepto 9).

Luego: al pasar las tres puertas, llama a la ruta real de Paperclip (Parte C), autenticada por la clave API del tablero de Claudia, con un decisionNote opcional (puede repetir la firma ed25519 allí para auditoría). Y escribe una fila governance_ledger (tu propia tabla, esquema en docs/governance-ledger-schema.sql), que se puede unir al activity_log de Paperclip mediante el ID de aprobación. Esa fila conlleva la distinción entre propietaria humana y propietaria-Identic-AI; activity_log de Paperclip no lo hace (consulta la corrección de honestidad a continuación).

Parte C: el Paperclip real enruta las llamadas de tu capa (verificado con 2026.513.0; una tabla de búsqueda, escanéala cuando conectes las llamadas, no necesitas memorizarla):

• POST /api/approvals/{approvalId}/approve (200 para una llamada con credenciales del tablero), cuerpo {decisionNote?}. El cuerpo también puede llevar un decidedByUserId, pero Paperclip lo ignora: la ruta atribuye la decisión al actor autenticado, no a ese campo. No lo trates como una entrada significativa.
• POST /api/approvals/{approvalId}/reject (200), POST /api/approvals/{approvalId}/request-revision (200). Las tres llaman a assertBoard(): una llamada con clave API de agente recibe un 403 "Board access required".
• GET /api/companies/{companyId}/approvals?status=pending (200) para el sondeo, GET /api/approvals/{approvalId} (200) para leer una aprobación
• GET /api/companies/{companyId}/activity (200) para volver a leer el registro de auditoría

Ten en cuenta que las rutas de acción son planas (/api/approvals/{id}/approve), no están limitadas a la empresa. No hay ningún verbo resolve ni PATCH /api/approvals/{id}: los verbos de decisión son approve, reject y request-revision, cada uno de los cuales es una subruta POST.

Sé honesto acerca de lo que activity_log de Paperclip registra para las aprobaciones. Esta es la corrección que sostiene toda la capa. Las rutas de aprobación son acciones del tablero: cada fila de activity_log que escriben lleva actor_type='user', actor_id='local-board' (el ID de usuario del tablero), agent_id=null. Una aprobación que resuelve Claudia y una que Maya resuelve ella misma quedan ambas como actor_type='user'; Paperclip no puede distinguirlas, porque para Paperclip ambas son llamadas del tablero. actor_type='agent' sí existe en activity_log, pero solo para incidencias, latidos y actividad de ejecución, nunca para una decisión de aprobación. Por eso, la distinción entre dos principales no es algo que heredes de Paperclip para las aprobaciones. Vive en tu governance_ledger: la fila que escribe Claudia lleva principal='owner_identic_ai' con su atestación y su razonamiento, y eso distingue una aprobación resuelta por Claudia de una resuelta por Maya. Esta es exactamente la razón por la que el curso construye el governance_ledger: es la verdad de auditoría que Paperclip no proporciona de forma nativa para las aprobaciones. La arquitectura funciona como fue diseñada; no se queda corta.

Aprobar es registrar una decisión, no mover una máquina de estados. Esta es la corrección más importante del borrador anterior. Aprobar una aprobación en Paperclip registra la decisión. No cambia el estado de la incidencia vinculada, no ejecuta la acción del payload y no reanuda a ningún Worker. No hay ningún step.wait_for_event conectado para reanudar Workers desde aprobaciones de Paperclip (esa primitiva pertenece a Inngest, Curso Cinco). Continuar el trabajo después de una aprobación es un paso explícito y separado: PATCH /api/issues/{id} para cambiar el estado de la incidencia, asignar un Worker para que su siguiente latido la recoja o poner en cola un agent_wakeup_request. El trabajo de tu capa de delegación termina en "la decisión queda registrada y la fila de governance_ledger queda escrita"; impulsar el trabajo posterior es su propio paso, exactamente como enseñaron los cursos seis y siete.

El resumen. En tu herramienta de codificación agéntica, cambia al modo de plan, pega el resumen a continuación, solicita a la herramienta que produzca un plan escrito y lo guarde en docs/plans/decision-5.md, revísalo y luego sal del modo de plan para ejecutarlo.

Construye la capa de delegación y verificación. Ruta completa: esta capa vive en la skill paperclip-governance-delegate y envuelve las rutas de aprobación reales de Paperclip; no agregas endpoints de Paperclip. Ruta simulada: implementa los controles equivalentes y los endpoints stub en mocks/paperclip-mock.ts. Requisitos:

1. Tres controles, ejecutados antes de publicar cualquier decisión. Para cada decisión que tome Claudia:
   • Control 1, el firmante es un principal reconocido. Ruta completa: confirma que la clave API de tablero de Claudia (la que usa para publicar) está presente y no está revocada, y que su fila agents más la entrada agent_api_keys todavía existen. Ruta simulada: busca signer_principal_id en el almacén de registro del mock. Si no está reconocido o está revocado, rechaza la operación y escribe una fila en governance_ledger que registre el intento rechazado (los intentos de falsificación y de clave vencida deben ser auditables).
   • Control 2, verificación de firma. Verifica la firma ed25519 de Claudia sobre el payload de decisión en JSON canónico contra su clave pública registrada. Si no es válida, rechaza la operación y regístrala. Paperclip no tiene campo de firma; este control vive solo en tu capa.
   • Control 3, sobre delegado. Ruta completa: lee el sobre desde principal_permission_grants.scope jsonb de Claudia. Ruta simulada: lee el sobre que el mock guardó durante el registro. Prueba la acción declarada (tipo, importe) contra ese sobre; si queda fuera, rechaza la operación y regístrala. Paperclip no aplica esto en la ruta de aprobación; tu capa sí.
2. Cuando pasen los tres controles, publica la decisión. Ruta completa: llama a la ruta real de Paperclip, POST /api/approvals/{approvalId}/approve (o /reject, o /request-revision), autenticada con la clave API de tablero de Claudia (las rutas de aprobación requieren acceso de tablero), con un decisionNote opcional (puedes repetir allí la firma para auditoría). Ruta simulada: resuelve mediante la única ruta stub /resolve del mock.
3. Sé honesto acerca de la atribución de Paperclip; no la finjas. No inventes un campo actor en la fila de Paperclip. En la ruta completa, la ruta de aprobación es una acción del tablero: Paperclip escribe la fila de activity_log con actor_type='user', actor_id='local-board' (el ID de usuario del tablero), agent_id=null, entity_type='approval', entity_id=<approval id>, action='approval.approved'. Una aprobación que resuelve Claudia y una que resuelve Maya se ven idénticas en activity_log. La distinción entre propietaria humana y propietaria-Identic-AI la lleva tu fila de governance_ledger, no Paperclip. En la ruta simulada, el mock implementa atribución nativa de principal para mayor claridad didáctica; no esperes eso del Paperclip real.
4. NO reanudes a un Worker. La aprobación es un registro de decisión. No cambia la incidencia vinculada ni reanuda nada. Continuar el trabajo es un paso explícito y separado (PATCH /api/issues/{id} para establecer el estado, asignar un Worker o poner en cola un agent_wakeup_request); ese paso queda fuera del alcance de esta capa.
5. Crea la tabla governance_ledger con el esquema de docs/governance-ledger-schema.sql. Es tu propia tabla aditiva; no toca el esquema de Paperclip. Escribe una fila por cada decisión que tome Claudia (publicada o rechazada), unible a activity_log mediante el ID de aprobación.
6. Revocación, para la Decisión 7. Ruta completa: revocar las credenciales de Claudia es una operación con credenciales de tablero. DELETE /api/agents/{id}/keys/{keyId} es la ruta real para revocar una entrada de agent_api_keys (establece revoked_at); revocar la clave API de tablero que Claudia posee es el movimiento paralelo. Ambas operaciones requieren las credenciales de tablero de la propietaria humana; no hay ningún endpoint que tengas que construir. Ruta simulada: implementa el endpoint stub de revocación del mock y exige autenticación de la propietaria humana del mock, nunca una firma de Identic AI.
7. Sugerencias de biblioteca: para ed25519 en TypeScript usa @noble/ed25519; en Node, el módulo integrado crypto; el JSON canónico para firmar debe ordenar las claves y eliminar espacios en blanco para que firmante y verificador coincidan byte a byte.
8. Informa: la implementación de los controles, una prueba exitosa de cada control (incluidas las rutas de rechazo), la llamada a la ruta real de Paperclip (ruta completa) o la resolución del mock (ruta simulada), y una fila de ejemplo de governance_ledger.

Qué esperar. Tu asistente produce:

• Una capa de verificación de tres puertas: el firmante es un agente registrado, la firma verifica y la acción dentro del sobre delegado
• Verificación de firma usando una biblioteca estándar ed25519 (en TypeScript, @noble/ed25519 es la opción típica; en Node, el módulo incorporado crypto funciona)
• Lógica de intersección de envolventes que lee la envolvente delegada (principal_permission_grants.scope en la ruta completa, el almacén del mock en la ruta simulada) y prueba la acción declarada contra ella
• Ruta completa: llamadas reales a POST /api/approvals/{id}/approve y similares con la clave API de tablero de Claudia, con Paperclip escribiendo filas de activity_log que llevan actor_type='user' (la ruta de aprobación es una acción del tablero). Ruta simulada: la ruta /resolve del mock hace el equivalente, con la atribución nativa de principal del mock.
• Tu propia tabla governance_ledger creada y una fila escrita para cada decisión que toma Claudia: aquí es donde reside la distinción propietaria humana vs propietaria-Identic-AI

Solución de problemas:

• La verificación de firma funciona en las pruebas pero falla con la clave real. Más común: falta de coincidencia en la codificación de la carga útil. Verifica que tanto el firmante como el verificador utilicen la misma codificación JSON canónica (claves ordenadas, sin espacios en blanco adicionales) antes de firmar/verificar.
• Los controles de envolvente pasan para acciones que deberían quedar fuera. La envolvente en scope (o el almacén del mock) es más permisiva de lo previsto. Prueba casos límite explícitamente: un reembolso de $2,000.01 contra una envolvente de $2,000 debería fallar; un reembolso de exactamente $2,000 depende de la semántica inclusiva o exclusiva (elige una y documéntala).
• La aprobación no solucionó el problema ni reanudó al Worker. Ese es un comportamiento correcto, no un error. Una aprobación de Paperclip es un registro de decisión. continuar el trabajo es un paso explícito separado; cablear ese paso por sí solo, después de que se registre la decisión.
• governance_ledger las filas están escritas pero el resumen semanal de Maya (Concepto 11) no las incluye. Preocupación diferente; ese es un problema de cableado de la Decisión 6+, no de la Decisión 5. Verifica que el registro tenga filas primero.

Conclusión de la Decisión 5. Tu capa de delegación verifica la atestación de Claudia, aplica la envolvente delegada y solo entonces impulsa las rutas reales de aprobación de Paperclip con su clave API de tablero (ruta completa) o el mock (ruta simulada). Contra el Paperclip real, la ruta de aprobación es una acción del tablero, así que activity_log registra actor_type='user' en ambos casos; la distinción entre propietaria humana y propietaria-Identic-AI reside en tu propio governance_ledger, que es exactamente la verdad de auditoría que este curso busca proporcionar. Todo lo que Claudia hace desde aquí fluye por este camino de verificación.

Decisión 6: Demostración de un extremo a otro con una avalancha de aprobaciones de rutina más una importante

En una línea: genera solicitudes de aprobación para una semana realista contra la fuerza laboral del Curso Siete, la mayoría rutinaria, una importante y observe a Claudia manejar las rutinas de forma autónoma mientras le muestra correctamente la importante a Maya a través de Telegram.

Este es el momento en que la promesa del octavo invariante se vuelve observable en operación. Las decisiones 1 a 5 son la configuración; la Decisión 6 es la prueba. Si la demostración no muestra la propiedad de escala (Claudia maneja rápido lo rutinario, presenta lo importante a Maya y escribe una fila de governance_ledger por cada decisión que toma), algo anterior está mal. Trata la demostración como una verificación de las decisiones anteriores y una prueba de estrés honesta de la arquitectura.

PRIMM: Predecir

Estás a punto de inyectar 30 solicitudes de aprobación sintéticas en Paperclip y observar cómo Claudia las maneja. La mezcla: 22 reembolsos en el rango de $500 a $1,500, 4 reembolsos en el rango de $1,500 a $2,000, 2 anulaciones de presupuesto del 10 al 15 % por encima del límite, 1 contratación de Nivel 2 para un nuevo idioma (sin extensión de sobre) y 1 contratación con extensión de sobre.

Una instrucción permanente importa para esta predicción, repetida aquí para que no tengas que buscarla. Maya tiene una instrucción permanente: la primera contratación en un nuevo idioma es un momento estratégico y debe presentársele, incluso cuando la contratación no necesita extensión de sobre. (Esta es la instrucción que estableció el PRIMM del Concepto 1).

Dos predicciones:

1. ¿Cuántos de los 30 debería manejar Claudia de forma autónoma (aprobación automática) en comparación con las que muestra a Maya, según el sobre conservador de la Decisión 4?
2. ¿Aproximadamente cuánto tiempo debería tomar el procesamiento autónomo de decisiones, de extremo a extremo, para todas ellas (suponiendo un ciclo de sondeo de 60 segundos)?

---

Respuestas:

1. 28 autónomas, 2 presentadas a Maya. Los 22 reembolsos entre $500 y $1,500 están todos dentro del sobre delegado, así que todos son autónomos (22). Los 4 reembolsos entre $1,500 y $2,000 siguen por debajo del techo de $2,000, así que también son autónomos (4 más, 26 en total). Las 2 anulaciones de presupuesto del 10 al 15 % están por debajo del techo del 20 %, así que también son autónomas (2 más, 28 en total). La contratación para el nuevo idioma queda fuera del sobre delegado por la instrucción permanente de Maya del PRIMM Predict del Concepto 1 (la primera contratación en español es un momento estratégico), así que se presenta a Maya. La contratación con extensión de sobre queda fuera del sobre delegado por definición, así que también se presenta. 2 presentadas a Maya, 28 autónomas.
2. 2 a 3 minutos en total. Con un ciclo de sondeo de 60 segundos, Claudia recoge las 30 solicitudes en su primer ciclo de sondeo después de la inyección. Razonar sobre cada una toma aproximadamente de 3 a 5 segundos en casos rutinarios (la plantilla de prompt es corta y las decisiones son claras). Las 28 decisiones autónomas se resuelven en unos 2 minutos. Las 2 presentadas van al Telegram de Maya y esperan su respuesta, lo que no cuenta dentro del tiempo de procesamiento de Claudia.

Si tu predicción está lejos, algo en tu comprensión del sobre o de la arquitectura de sondeo está mal. Usa la demostración para recalibrar.

El resumen. En tu herramienta de codificación agéntica, cambia al modo de plan, pega el resumen a continuación, solicita a la herramienta que produzca un plan escrito y lo guarde en docs/plans/decision-6.md, revísalo y luego sal del modo de plan para ejecutarlo.

Demuestra el pipeline completo de extremo a extremo. Genera una carga de trabajo sintética de 30 solicitudes de aprobación con una distribución realista, publícalas en Paperclip y verifica que Claudia maneje los elementos rutinarios de forma autónoma mientras presenta los importantes. Requisitos:

1. Genera 30 solicitudes de aprobación sintéticas con esta distribución:
   • 22 reembolsos en el rango $500-$1,500 (Claudia debería aprobarlos automáticamente)
   • 4 reembolsos en el rango $1,500-$2,000 (Claudia los aprueba automáticamente pero los marca en el resumen semanal)
   • 2 anulaciones de presupuesto entre un 10 % y un 15 % por encima del límite (Claudia las aprueba automáticamente)
   • 1 propuesta de contratación para un especialista de Nivel 2 en español sin extensión de sobre (Claudia la presenta a Maya según la instrucción permanente del PRIMM Predict del Concepto 1: "la primera contratación en un nuevo idioma es un momento estratégico")
   • 1 contratación con extensión de sobre propuesta (Claudia la presenta; queda fuera del sobre delegado por definición)
2. Inyecta las 30 en la cola de aprobaciones de Paperclip (ruta completa: créalas mediante POST /api/companies/{companyId}/approvals; ruta simulada: el helper de inyección de cola del mock). Activa la skill de sondeo de Claudia (o espera el siguiente ciclo de sondeo de 60 segundos).
3. Captura tiempos precisos. Los compararemos con la predicción del PRIMM Predict anterior.
4. Verifica contra la traza de auditoría:
   • 28 aprobaciones ahora deberían tener status: approved. Ruta completa: cada una tiene una fila coincidente de activity_log en Paperclip y, como la ruta de aprobación es una acción del tablero, esa fila lleva actor_type='user', actor_id='local-board', agent_id=null. El hecho de que Claudia (no Maya) la haya impulsado queda registrado en tu governance_ledger, no en activity_log. Ruta simulada: las filas equivalentes del mock.
   • Cada una de las 28 también tiene una fila de governance_ledger con principal='owner_identic_ai': esa es la fila que atribuye la decisión a Claudia
   • 2 aprobaciones aún deberían estar en status: pending, esperando a Maya
5. Verifica que Maya haya recibido mensajes de Telegram. Debería tener 2 mensajes de Claudia resumiendo las 2 aprobaciones que surgieron, cada uno con el razonamiento de Claudia de por qué se mostró en lugar de aprobarse automáticamente.
6. Verifica que el tiempo coincida con la predicción (dentro de un orden de magnitud; las cifras reales dependen de la latencia del modelo).
7. Verifica el registro de gobernanza. Se deben escribir 28 filas con los campos del esquema del Concepto 11: action_taken, confidence, layer_source, reasoning_summary, attestation.
8. Respuesta de Maya ida y vuelta. Haz que Maya resuelva ella misma una de las 2 aprobaciones presentadas (aprobar la contratación en español) como propietaria humana: ruta completa, a través del panel de Paperclip; ruta simulada, mediante el camino de resolución humana del mock. Verifica que la decisión esté registrada y que Paperclip escriba una nueva fila de activity_log con actor_type='user', unible a la aprobación presentada por entity_id. (Registrar la decisión en sí no modifica la incidencia vinculada; ese paso posterior es independiente).
9. Maya ejerce una anulación (la mecánica del Concepto 12, obligatoria). Elige una de las 28 aprobaciones que Claudia aprobó automáticamente, un reembolso cerca de la parte superior de la banda es una buena opción y haz que Maya lo revierta: ella decide, tras la revisión, que esta no debería haber sido aprobada automáticamente. Registra la anulación escribiendo el campo governance_ledger.override_status en overridden_by_owner en la fila de esa aprobación, con un override_reason (por ejemplo, "este cliente tiene un patrón que quiero ver yo mismo"). Esta es la verdadera mecánica de recalibración del Concepto 12: la anulación son datos de entrenamiento, no solo una corrección. Verifica que la fila ahora muestre override_status='overridden_by_owner' y que se capture el motivo.
10. Ejecuta por tu cuenta el JOIN de la traza de auditoría (la columna vertebral hecha observable). Ejecuta el comando slash /verify-audit-trail del zip inicial (hace el JOIN entre activity_log y governance_ledger por el ID de aprobación). Observa directamente: una aprobación resuelta por Claudia y la contratación en español resuelta por Maya son indistinguibles solo en activity_log, ambas con actor_type='user'; solo la fila de governance_ledger, presente para la de Claudia y ausente para la de Maya, revela cuál fue la Identic AI. Esta es la distinción entre dos principales, observada en lugar de solo leída.
11. Pide a Claudia que produzca el resumen de gobernanza semanal (el resumen del Concepto 11, compilado, no solo leído). Pide a Claudia, a través de Telegram, que produzca el resumen de gobernanza semanal a partir de las filas governance_ledger que acaba de escribir la demostración: totales, desglose por categoría, la anulación que Maya acaba de hacer y cualquier indicador de confianza. Compara su forma con el resumen de muestra del Concepto 11. Este es el resumen que Maya consume semanalmente; aquí lo genera una vez a partir de filas reales del registro para que el factor de forma sea concreto, no solo descrito.
12. Informa: el desglose de tiempos, los recuentos de filas de auditoría (activity_log + governance_ledger), los dos mensajes de Telegram que recibió Maya, el flujo de respuesta de Maya, la fila de anulación, el resultado de la consulta JOIN y el resumen semanal generado.

Qué esperar. Tu asistente genera la carga de trabajo, ejecuta la demostración y reporta:

• 28 aprobaciones autónomas resueltas en aproximadamente 2 a 3 minutos
• 2 aprobaciones presentadas a Maya en Telegram con el razonamiento de Claudia adjunto
• activity_log muestra las filas de acciones del tablero; governance_ledger muestra 28 filas con resúmenes de razonamiento y puntuaciones de confianza
• La respuesta de Maya a una aprobación presentada fluye hasta la resolución
• Una aprobación automática anulada por Maya, con override_status y override_reason escritas en la fila governance_ledger
• La salida del JOIN de /verify-audit-trail, que muestra que las aprobaciones resueltas por Claudia y Maya son idénticas en activity_log y se distinguen solo por governance_ledger
• Un resumen de gobernanza semanal generado por Claudia a partir de las filas reales del registro de la demostración

Solución de problemas:

• La demostración se ejecuta pero ningún mensaje de Telegram llega a Maya. La integración de la app de mensajería de la Decisión 1 no está conectada a la lógica de aparición de la habilidad. Consulta el controlador de notificaciones de la habilidad.
• Claudia aprueba algo que debería haber presentado a Maya. El control del sobre en la Decisión 5 es demasiado permisivo. Recorre manualmente la aprobación específica con la lógica de intersección del Concepto 9 para identificar qué verificación falló.
• El tiempo es mucho más lento de lo previsto (10 veces o más). La latencia del modelo suele ser la causa. Verifica la longitud de la plantilla de prompt; si incluye contexto detallado para cada decisión, la latencia se multiplica. Recorta el prompt a lo esencial.

La traza resuelta vive en la Decisión 5. La explicación más clara de lo que produce la Decisión 6 es el hilo de aprobación de siete pasos al comienzo de la Decisión 5: un reembolso rutinario recorrido de extremo a extremo, con el razonamiento de Claudia, los tres controles, la llamada real a Paperclip y ambas filas de auditoría. La Decisión 6 es esa misma traza, ejecutada 28 veces en paralelo con 2 aprobaciones presentadas a Maya. Si la saltaste, léela ahora: es la imagen concreta de una sola aprobación autónoma, y la demostración aquí es esa imagen a volumen.

Las 2 aprobaciones presentadas a Maya se ven diferentes de las 28 autónomas. Para una aprobación presentada, Claudia escribe una fila de governance_ledger con action_taken: "surface_to_owner" y envía un mensaje de Telegram a Maya en lugar de llamar a la ruta de aprobación de Paperclip. Cuando Maya resuelve luego esa aprobación por sí misma (ruta completa: el panel de Paperclip; ruta simulada: el camino de resolución humana del mock), su acción escribe una fila de activity_log de Paperclip con actor_type='user' y actor_id establecido en su ID de usuario del tablero. Esa fila tiene la misma forma que la que produjo la capa de delegación de Claudia para las 28 aprobaciones autónomas: ambas son acciones del tablero. La distinción entre dos principales se observa uniendo activity_log con governance_ledger por el ID de aprobación: una aprobación que resolvió Claudia tiene una fila de governance_ledger con principal='owner_identic_ai'; una que Maya resolvió directamente no tiene esa fila. La distinción vive en tu registro, no en activity_log.

Conclusión de la Decisión 6. El pipeline de extremo a extremo funciona y ahora has hecho la columna vertebral, no solo la has leído. La promesa de la primitiva delegada (Claudia maneja rápido lo rutinario, presenta lo importante, cada decisión que toma queda registrada en governance_ledger) es observable en operación: ejecutaste por tu cuenta la consulta JOIN entre activity_log y governance_ledger y viste que la distinción entre dos principales vive en tu registro, no en la traza de auditoría de Paperclip. Ejercitaste la mecánica de anulación del Concepto 12 al revertir una de las aprobaciones automáticas de Claudia en el campo override_status. Y le pediste a Claudia que generara el resumen semanal del Concepto 11 a partir de filas reales del registro. Este es el momento en que la afirmación arquitectónica central del curso se verifica en código, y la razón por la que el curso construye governance_ledger.

Decisión 7: recuperación de portátiles robados y continuidad del cambio de dispositivo

En una línea: simula dos escenarios operativos, le roban el portátil a Maya (revocar las credenciales de Paperclip de Claudia desde otro dispositivo) y Maya recibe una Mac nueva (migrar su sesión de OpenClaw a ella), y verifica que ambos flujos funcionen correctamente.

El Concepto 8 nombró el caso del portátil robado como el modo de falla que sostiene esta decisión. Una arquitectura sin historia de recuperación para esto es frágil. La Decisión 7 verifica que la historia de recuperación funciona, no escribiéndola desde cero, sino ejercitando el flujo de revocación en dos escenarios realistas. Una Decisión 7 exitosa prueba que la Identic AI de Maya es recuperable, no solo desplegable. El mecanismo que hace funcionar la revocación: Claudia tiene dos credenciales de Paperclip, una clave API de tablero (la que usa para impulsar las rutas de aprobación) y una entrada de agent_api_keys (su identidad de agente). Revocar a Claudia significa revocar ambas: la clave API de tablero y la clave de agente mediante DELETE /api/agents/{id}/keys/{keyId} (que establece revoked_at). Una vez revocada la clave de tablero, la sesión de OpenClaw "robada" recibe un 403 en las rutas de aprobación; una vez revocada la clave de agente, también fallan las rutas solo para agentes. En la ruta completa, ambas revocaciones son acciones del lado de Paperclip realizadas con las credenciales de tablero de la propietaria humana; no existe una ruta de firma de Identic AI para ninguna de ellas. En la ruta simulada, el endpoint stub de revocación del mock hace lo equivalente.

Una nota sobre probar una clave revocada en desarrollo. En el modo de desarrollo local_trusted, un bearer token revocado o no válido en una ruta board se ignora silenciosamente y la solicitud vuelve al actor local-board, así que "publicar en la ruta de aprobación con la clave revocada" no demuestra la revocación con claridad. En su lugar, prueba una ruta solo para agentes (por ejemplo, GET /api/agents/me, que devuelve 401 para una clave de agente revocada), o revisa directamente la columna revoked_at. El resumen de abajo usa la ruta solo para agentes.

Los dos escenarios cubren diferentes modos de falla:

Escenario	Modo de falla	Lo que estamos probando
Portátil robado	Adversarial: alguien tiene la clave de firma de Maya + ambas claves API	La revocación funciona; el nuevo registro de agente + clave de tablero funciona; las claves antiguas quedan muertas
Cambio de dispositivo planificado	Operativo: Maya quiere moverse a una máquina nueva	La migración de sesión funciona; la Claudia del dispositivo nuevo es coherente con la anterior

El resumen. En tu herramienta de codificación agéntica, cambia al modo de plan, pega el resumen a continuación, solicita a la herramienta que produzca un plan escrito y lo guarde en docs/plans/decision-7.md, revísalo y luego sal del modo de plan para ejecutarlo.

Dos escenarios para probar en secuencia: revocación de portátil robado y luego cambio de dispositivo planificado. Requisitos:

Escenario 1, revocación de portátil robado:

1. Simula la pérdida. Trata la Mac principal de Maya como comprometida: el atacante tiene la clave de firma ed25519 de Claudia y sus dos credenciales de Paperclip (la clave API de tablero y la clave API de agente).
2. Revoca las credenciales de Paperclip de Claudia. Desde otro dispositivo (Maya inicia sesión en Paperclip en un segundo dispositivo con sus credenciales de tablero), revoca ambas: la clave API de tablero de Claudia y su entrada de agent_api_keys mediante DELETE /api/agents/{id}/keys/{keyId} (ruta completa; ruta simulada: llama al endpoint stub de revocación del mock). Esto debe hacerse con las credenciales de tablero de la propietaria humana de Maya, nunca con una firma de Identic AI: una Identic AI comprometida no debe poder revocarse ni volver a registrarse.
3. Verifica el requisito de autenticación humana. Intenta la revocación con una solicitud firmada por Identic AI en lugar de credenciales de la junta y confirma que se haya rechazado. (Esto verifica la propiedad de seguridad: una Identic AI comprometida no puede revocarse a sí misma).
4. Verifica que las claves antiguas estén muertas. Desde la sesión "robada" de OpenClaw, llama a una ruta solo para agentes, GET /api/agents/me, con la clave API de agente de Claudia ahora revocada; Paperclip debe devolver 401. (No pruebes esto con la ruta de aprobación: en el modo de desarrollo local_trusted, un bearer token revocado en una ruta de tablero se ignora silenciosamente y vuelve a local-board, así que la ruta de aprobación no mostraría la revocación. La ruta solo para agentes es la prueba limpia. Revisar revoked_at directamente en la base de datos también funciona).
5. Vuelve a registrarte en un dispositivo nuevo. En una máquina diferente, genera un nuevo par de claves ed25519, crea una clave API de tablero nueva y registra a Claudia como agente de Paperclip nuevamente con una nueva entrada agent_api_keys, todo a través de la sesión con credenciales de tablero de Maya, la misma persona, el mismo sobre delegado (principal_permission_grants.scope) que antes.
6. Verifica que Claudia esté completamente operativa en el nuevo dispositivo.

Escenario 2, cambio de dispositivo planificado:

7. DETÉN EL DEMONIO PRIMERO (paso crítico). En el dispositivo antiguo, ejecuta openclaw gateway stop y confirma con openclaw status que el proceso ya no se está ejecutando. Copiar un directorio de sesión en vivo mientras el demonio se está ejecutando puede dañar la base de datos SQLite integrada o hacer que el nuevo dispositivo descarte silenciosamente las decisiones recientes que tomó Claudia. La parada limpia no es negociable.
8. Copia la sesión. Mueve ~/.openclaw/ del dispositivo antiguo al nuevo, excepto el directorio de claves de firma, que se regenera.
9. Genera un nuevo par de claves en el nuevo dispositivo. Crea una clave API de tablero nueva y registra a Claudia como agente de Paperclip con una clave API de agente nueva, todo mediante la sesión con credenciales de tablero de Maya, como reemplazo de las credenciales antiguas (la identidad de Claudia permanece continua en tu registro de gobernanza; solo cambian las credenciales). Luego revoca la clave API de tablero antigua y la entrada antigua de agent_api_keys.
10. Inicia el demonio en el nuevo dispositivo. Ejecuta openclaw gateway start y verifica con openclaw status.
11. Verifica la continuidad de sesión. Pregúntale a Claudia en el nuevo dispositivo "¿cuál fue la última aprobación que manejaste?"; debe hacer referencia a la última aprobación real de la sesión del dispositivo anterior. Persona, instrucciones permanentes, patrones aprendidos: todos presentes.
12. Ejecuta una aprobación de verificación. Envía una solicitud de aprobación nueva; confirma que Claudia la maneja correctamente con entradas de auditoría coherentes con lo que habría producido el dispositivo anterior.

Documenta cada escenario: qué se conservó durante la transición, qué no se conservó y por qué, y qué tuvo que hacer Maya manualmente frente a qué fue automático.

Qué esperar. Tu asistente ejecuta ambos escenarios y reporta:

• Escenario de portátil robado: la revocación se completa con las credenciales de tablero de la propietaria humana y falla (correctamente) con una solicitud firmada por Identic AI. La clave de agente revocada de la sesión "robada" devuelve 401 en GET /api/agents/me, y su clave de tablero devuelve 403 en las rutas de aprobación. Una clave API de tablero nueva más el registro de agente en un dispositivo nuevo, hecho mediante la sesión con credenciales de tablero de Maya, queda plenamente operativo. La personalidad de Claudia, las instrucciones permanentes y los patrones acumulados sobrevivieron (porque viven en la sesión del sistema de archivos de Maya, que el portátil robado se llevó; en la práctica Maya restaura su sesión desde una copia de seguridad, y la prueba arquitectónica verifica que los propios patrones son recuperables desde esa copia).
• Escenario de cambio de dispositivo: la sesión migra intacta mediante una copia del sistema de archivos. La Claudia del dispositivo nuevo tiene la misma personalidad, historial y patrones. La clave API de tablero nueva más el nuevo registro de agente son el único cambio a nivel de credenciales. El registro de gobernanza permanece intacto y continuo.

Solución de problemas:

• La ruta de revocación acepta una solicitud firmada por Identic AI. El requisito de autenticación está mal; la revocación debe exigir las credenciales de tablero de la propietaria humana. Corrígelo (ruta completa: la revocación es, por diseño, una acción de Paperclip con credenciales de tablero, así que verifica que no la estés enrutando mediante la autenticación de agente de Claudia; ruta simulada: corrige el endpoint stub de revocación del mock). Una Identic AI comprometida no debe poder revocarse a sí misma.
• Claudia del nuevo dispositivo no tiene la sesión anterior. La migración de sesión mediante copia del sistema de archivos es el caso más simple; si falla, verifica que se haya copiado todo el ~/.openclaw/ (habilidades, personalidad, historial) y no solo los archivos de configuración.
• El registro de gobernanza tiene un vacío durante la transición. Es esperable si la transición toma un tiempo significativo; documenta la brecha y confirma que Maya no perdió ninguna aprobación en curso durante el cambio.

Conclusión de la Decisión 7. Ambos modos de falla están cubiertos. Maya puede recuperarse de un portátil robado; Maya puede migrar limpiamente a un dispositivo nuevo. La historia de recuperación de la arquitectura queda verificada, no solo declarada. Esto concluye el laboratorio.

---

Parte 5: Realismo operativo: qué aprende la Identic AI y cómo funciona la auditoría

El laboratorio de la Parte 4 produce una Identic AI de la propietaria en funcionamiento. La parte 5 trata sobre lo que sucede con el tiempo: lo que Claudia aprende durante seis meses de las decisiones de Maya, cómo Maya audita el comportamiento de Claudia a través de un registro paralelo y qué hacer cuando Claudia y Maya no están de acuerdo. Tres conceptos, la misma forma que la Parte 5 del Curso Siete.

Concepto 10: Lo que la Identic AI aprende en seis meses

En la demostración de la Decisión 6, Claudia ya estaba configurada con 200 decisiones de aprobación históricas importadas (Decisión 2) y un documento de instrucciones permanentes (Decisión 4). Ese es el estado inicial. Durante seis meses de operación, Claudia acumula mucho más y el Concepto 10 analiza qué tipo de acumulación realmente la ayuda a ser la Identic AI de Maya en lugar de simplemente un registro de chat de la vida de Maya.

Tres capas de contexto acumulado. Capa 1: instrucciones explícitas para estar de pie. Maya le cuenta cosas a Claudia en Telegram. Las instrucciones son de primera clase: Claudia las registra, las indexa y las aplica con fiabilidad. Son las reglas que Maya escribe conscientemente. Ejemplos concretos que Maya podría haber dado en el tercer mes:

• "Siempre explíqueme las contrataciones de extensión de sobre, sin excepciones."
• "Reembolsos inferiores a $300 con cuenta de cliente con antigüedad mayor a dos años: aprobación automática."
• "Reembolsos para clientes con más de tres reembolsos anteriores en los últimos seis meses: siempre se me muestran sin importar el monto."
• "Anulaciones presupuestales de los Workers en sus primeros 30 días de operación: siempre me salen a la superficie."
• "Nunca autoapruebes nada que toque el sobre de autoridad del Especialista Legal."

Éstas se leen como políticas de la empresa porque eso es lo que son: la política de Maya, expresada en un lenguaje sencillo, acumulada gradualmente a medida que descubre qué reglas realmente quiere.

Capa 2: retroalimentación por decisión. Cada vez que Maya anula a Claudia, Maya brinda retroalimentación. Estas son correcciones a los patrones, superpuestas a las reglas explícitas. Ejemplos concretos:

• (Claudia aprobó automáticamente un reembolso de $1,400. Maya lo anula).__"Deberías haber sacado a relucir esto. Este cliente ha estado con nosotros 6 semanas, ese no es el patrón de permanencia a largo plazo en el que confío".
• (Claudia le mostró a Maya una contratación rutinaria de Nivel 1. Maya la aprueba y agrega:) "Puedes aprobar esto sin mí. Contrataciones de Nivel 1 por menos de $300 al mes, envolvente establecida: este es exactamente el caso de aprobación automática."
• (Claudia aprobó una anulación presupuestaria del 18% para un Worker de 4 meses. Maya no anula pero comenta:)__"Bien esta vez, pero en adelante ten en cuenta que este Worker ha tenido dos anulaciones seguidas; la tercera debería venir a mí."

Estos comentarios se unen a la sesión de Claudia y refinan el comportamiento futuro. Críticamente, no son sólo correcciones; incluyen el razonamiento de Maya. El razonamiento es lo que le permite a Claudia aplicar la lección a casos similares, pero no idénticos, más adelante.

Capa 3: patrones derivados. Al observar las decisiones de Maya a lo largo del tiempo, Claudia construye modelos que Maya nunca estableció como reglas. Ejemplos concretos que podrían surgir en el quinto mes:

• "Maya aprueba los reembolsos más rápido los lunes que los viernes. Posible inferencia: los reembolsos de los viernes se analizan más, tal vez debido a la carga de atención al cliente del fin de semana."
• "Maya tiende a mostrar solicitudes de anulación de presupuesto si el registro de actividad reciente del Worker muestra un solo incidente de gran costo, incluso dentro del sobre de aprobación automática."
• "Maya ha aprobado todas las contrataciones de una línea de productos de nivel 1 en los últimos 40 días; ha mostrado todas las contrataciones de la nueva línea de productos de la UE. El patrón sugiere que la línea de la UE se encuentra en una fase de confianza diferente."

Cada patrón derivado viene con un nivel de confianza. Algunos son fuertes después de 50 decisiones; algunos se equivocan después de 500. La honestidad de la Identic AI sobre de qué capa proviene una decisión es lo que hace que Maya pueda recalibrarse cuando debería hacerlo. Un recorrido de seis meses. Esto es lo que Maya podría experimentar durante sus primeros seis meses con Claudia, en orden aproximado:

| Mes | ¿Qué está pasando? Qué está haciendo Claudia | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | 0 (Decisiones 1-4) | OpenClaw instalado; 200 aprobaciones históricas importadas; 8 instrucciones de pie configuradas | El patrón coincide con la historia importada; aplica instrucciones permanentes de manera confiable; emerge ~20% de las decisiones porque los patrones aún son débiles | | 1 | Maya anula a Claudia ~12 veces; da retroalimentación cada vez | La retroalimentación de la capa 2 se une a la sesión; comportamiento en casos similares mejora visiblemente en un mes | | 2 | Maya agrega 3 instrucciones permanentes más en respuesta a patrones superficiales recurrentes | La tasa de superficie cae a ~12%; se mantiene la confiabilidad de la aprobación automática | | 3 | Primer patrón emergente de Capa 3: Claudia nota la tendencia de Maya a sacar a la luz anulaciones presupuestarias en los Workers del primer mes; comienza a mostrarlos de manera proactiva | Maya confirma que el patrón es correcto; une reglas explícitas en la Capa 1 la próxima vez que Maya edite | | 4-5 | La tasa de superficie se estabiliza alrededor del 8-10%; la tasa de anulación cae a ~3%; las revisiones semanales del registro de gobernanza toman ~10 minutos | Estado estable; Los patrones de la capa 3 se están acumulando pero lentamente | | 6 | Llega un caso novedoso: Gerente-Agente propone contratar a un Worker para una tarea de cumplimiento normativo que ningún Worker ha desempeñado antes | Claudia reconoce "ningún patrón, superficie" y rutas hacia Maya; Maya hace un nuevo juicio, comenta su razonamiento, se suma como un nuevo patrón |

Observe la trayectoria: los primeros meses están llenos de retroalimentación (Capa 2) y reglas explícitas (Capa 1), porque Maya está enseñando activamente a Claudia. Para el mes 4-5, la tasa de correcciones cae bruscamente, no porque Claudia haya memorizado todos los casos, sino porque el estilo de toma de decisiones de Maya ahora está razonablemente capturado. Para el mes 6, la atención de Maya se centra en casos novedosos, recalibraciones y resúmenes semanales. La promesa del octavo invariante, que la atención de Maya queda libre para lo que realmente necesita su juicio, es operativamente observable en esta trayectoria. El límite entre lo que se puede enseñar y lo que no. No todo en la sesión de Maya es un patrón que se puede enseñar. Las capas inferiores (instrucciones explícitas, retroalimentación por decisión) se aplican de manera confiable; la tercera capa (patrones derivados) es probabilística y varía en calidad. Una buena Identic AI marca la diferencia y es honesta sobre de qué capa se basa. Claudia podría decir en su resumen de gobernanza semanal: "Esta semana autoaprobé 47 reembolsos según sus instrucciones explícitas; le diferí 3 según patrones que he aprendido, pero en los que solo tengo una confianza moderada". Esa honestidad es lo que hace que Maya pueda recalibrarse cuando debería (Concepto 12).

Pruebe con IA

Pega esto en tu asistente de codificación de IA: _"El Concepto 10 describe tres capas de contexto que acumula una Identic AI de la propietaria: instrucciones permanentes explícitas, retroalimentación por decisión y patrones derivados. Dadas las tres capas, diseña una instrucción de un párrafo que Claudia podría incluir en su resumen de gobierno semanal que le deje claro a Maya qué decisiones provienen de cada capa, para que Maya sepa dónde enfocar su atención de recalibración. La instrucción debe ser lo suficientemente concreta como para que Maya pueda actuar en consecuencia; lo suficientemente vaga como para que no requiera que Claudia tenga que hacerlo. Vuelve a explicar su razonamiento en detalle cada semana. Muéstrame tres borradores diferentes de esta instrucción, variando qué tan prominente es la atribución de capa.

Lo que estás aprendiendo: el problema de la atribución de capas es fundamental para un diseño honesto de Identic AI. Si Claudia oculta de qué capa está dibujando, Maya no podrá recalibrar bien. Si Claudia explica demasiado, el resumen semanal se vuelve ilegible. El equilibrio adecuado es una elección de diseño; el ejercicio te hace tomar esa decisión y ver la compensación.

En pocas palabras: durante seis meses, Claudia acumula tres capas de contexto: instrucciones explícitas que Maya escribe (Capa 1, confiable), retroalimentación por decisión que Maya da cuando Claudia se equivoca en algo (Capa 2, confiable, incluye el razonamiento de Maya) y patrones derivados que Claudia aprende al observar a Maya decidir (Capa 3, probabilística, varía en confianza). La trayectoria a lo largo de los meses va desde una intensa enseñanza activa (meses 1 a 3) hasta un estado estable con recalibración ocasional de casos novedosos (meses 4 a 6+). Una buena Identic AI es honesta acerca de qué capa se basa en una decisión determinada; esa honestidad es lo que hace que el ciclo de recalibración de Maya funcione.

Concepto 11: El registro de gobernanza: el flujo de auditoría de la Identic AI

En el Curso Siete, el registro de talento era el flujo de auditoría de la empresa: cada evento de contratación, evaluación, jubilación y recontratación a lo largo de la historia de la fuerza laboral, consultable con SQL. El Curso Ocho agrega un flujo de auditoría paralelo: el registro de gobernanza, que registra cada decisión que Claudia tomó en nombre de Maya.

Dos registros paralelos, una fuente de verdad para cada uno. El registro de talento registra lo que hizo la fuerza laboral. El registro de gobernanza registra lo que la Identic AI de Maya hizo en nombre de Maya. Comparten una clave de unión (el ID de aprobación, el ID del problema de origen, el ID del Worker), por lo que un analista puede correlacionarlos (¿qué decisiones que afectan al Worker X a lo largo del tiempo fueron tomadas por la propia Maya o por Claudia en su nombre?), pero son fuentes de verdad distintas que se mantienen por separado. Maya posee el registro de gobernanza; la empresa es propietaria del registro de talento.

El esquema, concretamente. Cada fila del registro de gobernanza captura:

governance_ledger
├── ledger_id                  -- primary key for this governance row
├── timestamp                  -- ISO 8601, millisecond resolution
├── approval_id                -- joins to talent_ledger / activity_log
├── source_issue_id            -- joins to the originating issue (refund request, hire proposal, etc.)
├── principal                  -- "owner_identic_ai" (always: this ledger is Identic-AI-only)
├── acting_on_behalf_of        -- the human owner's ID (Maya's ID)
├── action_taken               -- approve / request_revision / surface_to_owner / decline
├── confidence                 -- 0.0 to 1.0: Claudia's self-rated confidence
├── layer_source               -- "standing_instruction" / "per_decision_feedback" / "derived_pattern"
├── layer_reference            -- the specific instruction or pattern that triggered (FK)
├── reasoning_summary          -- 1-2 sentences explaining why
├── override_status            -- null initially; "overridden_by_owner" if Maya later corrected
└── override_reason            -- if overridden, Maya's stated reason (joins back as Layer 2 feedback)

Los nombres de los campos coinciden con el ejemplo trabajado en la Decisión 6 de la Parte 4: ledger_id, approval_id, principal, acting_on_behalf_of, action_taken, confidence, layer_source, layer_reference, reasoning_summary, override_status, timestamp. Un ejemplo de entradas semanales. Cómo se verían las cuatro filas del registro de gobernanza de Maya, en lenguaje sencillo:

Hora	Acción	Por qué	Capa	Confianza
Lunes 09:14	Reembolso aprobado de $890 al cliente C-3421	El cliente tiene una antigüedad de cuenta de 3,2 años, no tiene reembolsos previos, coincide con mi patrón de "larga duración y baja prioridad" (Capa 3)	patrón _derivado	0,91
Lunes 11:02	Surfaced to Maya: reembolso de $1,400 al cliente C-7755	El cliente tiene 2 reembolsos previos en los últimos 4 meses; su instrucción permanente (Capa 1: "más de 3 reembolsos anteriores, siempre aparece") casi se activa; Salí de forma conservadora a las 2	instrucción de pie	0,78
mar 03:11	Aprobación de aumento presupuestario del 12 % para el Worker W-tier1-eu-3	El Worker está en el mes 4, la anulación es para manejar un incidente documentado del registro de actividad, aprobación automática por sobre delegado	instrucción de pie	0,96
miércoles 16:48	Surfaced to Maya: propuesta de contratación de Especialista en Cumplimiento	No hay contrataciones previas de este tipo en el registro de talento; ningún patrón aprendido; por defecto a la superficie	patrón _derivado (ausencia)	0,45

Cada fila se puede consultar, unir y exportar. Maya no lee esto crudo; su resumen semanal se genera a partir de él.

El patrón de revisión semanal. Maya lee el registro de gobernanza semanalmente de la misma manera que el tablero del Curso Siete lee el registro de talento: no fila por fila, sino como un resumen. Claudia produce un resumen semanal enviado al Telegram de Maya. Un ejemplo realista:

Resumen semanal de gobernanza, semana del 6 al 12 de mayo

Totales: 142 decisiones atendidas. 134 autoaprobados (94%). Te surgieron 8 (6%). Anulaste 1 de mis aprobaciones automáticas (0,7%).

Desglose por categoría:

• Reembolsos: 97 (94 aprobados, 3 presentados a Maya)
• Anulaciones de presupuesto: 28 (27 aprobadas, 1 presentada)
• Migraciones de sustrato: 12 (12 aprobadas)
• Confirmaciones de edición de políticas: 5 (2 aprobadas, 3 presentadas a Maya)

Su anulación esta semana: reembolso de $1,847 al cliente C-4429 (martes). Su comentario: "este cliente tiene múltiples reembolsos anteriores, debería haber aparecido". Actualicé el patrón: para los clientes con más de 2 reembolsos anteriores en los últimos 6 meses, ahora lo mostraré sin importar el monto. (Se unieron los comentarios de la capa 2).

Banderas de confianza que me gustaría que le echaras un vistazo:

• Dos reembolsos que aprobé con un nivel de confianza de 0,62-0,68 (inferior a mi umbral habitual de 0,85+). Ambos implicaban patrones inusuales que no he visto a menudo. Están en el registro en las filas G-2204 y G-2241 si quieres comprobarlo.
• Está empezando a surgir un patrón derivado: el momento del reembolso parece variar según el día de la semana en sus decisiones. No voy a actuar sobre esto todavía, es demasiado pronto.

Carga esperada para la próxima semana: según el tamaño actual de la fuerza laboral y las últimas 4 semanas, se esperan aproximadamente 150 decisiones. No hay proyectos importantes que cambian mi carga de trabajo esperada.

Este es el factor de forma que Maya realmente consume. No se hizo una revisión fila por fila, ni registros sin procesar, sino un resumen semanal estructurado con los patrones, las excepciones y las banderas de confianza que surgieron.

La revisión semanal es lo que mantiene a Maya informada en la escala correcta. Ella no lee todas las decisiones; lee los patrones de decisiones y las excepciones. El registro de gobernanza convierte seis meses de las acciones de Claudia en una auditoría cuestionable y resumible sobre la que Maya puede actuar, no solo en una mancha de historia.

Un ejemplo de consulta SQL que Maya podría ejecutar. Supongamos que un miembro del equipo de éxito del cliente le pregunta a Maya sobre una serie de decisiones de reembolso de un solo cliente. Maya puede consultar su registro:

SELECT timestamp, action_taken, reasoning_summary, layer_source, override_status
FROM governance_ledger
WHERE source_issue_id IN (
  SELECT issue_id FROM activity_log
  WHERE customer_id = 'C-4429'
)
ORDER BY timestamp;

El resultado es la auditoría completa de cada decisión de gobierno que Claudia tomó sobre temas relacionados con ese cliente. Maya puede verificar que Claudia manejó al cliente correctamente, identificar si debería haber tomado alguna decisión y retroalimentar lo aprendido. El registro de gobernanza es lo que hace que la gobernanza delegada sea auditable en lugar de simplemente_operativa_.

Pruebe con IA

Pega esto en tu asistente de codificación de IA: _"Estoy diseñando el esquema del registro de gobernanza para una Owner Identic AI. El esquema del Concepto 11 del Curso Ocho es un punto de partida razonable. Dado el esquema, diseña tres consultas adicionales que Maya podría querer ejecutar más allá del ejemplo del problema del cliente. Para cada consulta, escribe el SQL y explica qué pregunta operativa está respondiendo Maya. Las consultas deben ser el tipo de cosas que Maya realmente querría preguntar durante una revisión semanal o al investigar una inquietud específica, no ejercicios sintéticos".

Lo que está aprendiendo: el registro de gobernanza no es valioso sólo porque registra decisiones; es valioso porque Maya puede interrogarlo. Las consultas que tú desearía existir en un espectro que va desde "qué hizo Claudia esta semana" (revisión semanal) hasta "¿Claudia manejó correctamente esta situación específica" (investigación) y "los patrones aprendidos de Claudia están a la deriva" (verificación de calibración). Saber qué consultas escribiría le indica para qué espera utilizar realmente el registro.

_En pocas palabras: el registro de gobernanza es el flujo de auditoría de cada decisión que Claudia tomó en nombre de Maya, que se puede agregar solo, es consultable y se resume semanalmente para Maya. Es el paralelo al registro de talento del Curso Siete: dos flujos de auditoría, una fuente de verdad para cada uno, unidos por identificaciones de aprobación y emisión. El resumen semanal es lo que hace que la arquitectura se automonitoree a escala de la propietaria; Maya lee patrones y excepciones, no filas individuales. La capacidad de consulta SQL es lo que hace que la investigación sea manejable cuando Maya la necesita.

Concepto 12: Cuando el juicio de la Identic AI y el de la propietaria divergen

El concepto operativo más importante de la Parte 5 es cómo manejar el caso en el que Maya no está de acuerdo con Claudia. El instinto de un lector, después del Concepto 11, podría ser que este es un modo de falla: Claudia hizo algo mal, Maya lo corrige, idealmente deja de suceder. Ese instinto está mal. El desacuerdo entre Maya y Claudia es una señal saludable y la arquitectura está diseñada para hacerlo productivo en lugar de castigar.

Por qué el desacuerdo es saludable. Tres razones:

Primero, ningún patrón derivado es correcto en el primer intento. Los patrones de la Capa 3 de Claudia (Concepto 10) son aproximaciones aprendidas. Algunas serán buenas después de 50 decisiones; algunos se equivocarán después de 500. La única forma de descubrir cuál es cuál es observar dónde fallan. Si Claudia y Maya nunca están en desacuerdo, Claudia aún no ha sido empujada a un territorio nuevo; los patrones no han sido sometidos a pruebas de estrés. El desacuerdo es la señal de que se ha tocado el límite del juicio confiable de Claudia. En segundo lugar, el juicio de Maya evoluciona. Maya en el primer mes y Maya en el sexto mes no son la misma persona: ha aprendido cosas sobre su negocio, el mercado ha cambiado, la fuerza laboral ha crecido. Los patrones que Claudia aprendió en el primer mes gradualmente quedarán obsoletos. El desacuerdo es la señal de que el juicio de Maya ha cambiado y Claudia necesita ponerse al día. En tercer lugar, el ciclo de recalibración es en sí mismo un momento de enseñanza. Cuando Maya anula a Claudia, normalmente da una razón de una sola frase ("este cliente tiene reembolsos anteriores, debería haber aparecido"). Esa razón se une a la capa de retroalimentación por decisión (Capa 2 del Concepto 10). La próxima vez que surge un patrón similar, Claudia compara la nueva retroalimentación con el patrón anterior. La anulación no es sólo una corrección; son datos de entrenamiento que Claudia utiliza para refinar su comportamiento futuro. La válvula de escape. Arquitectónicamente, Maya siempre puede anular a Claudia. Cuando Maya revierte una de las decisiones de Claudia, su anulación es una nueva acción de la junta: escribe una nueva fila activity_log (una acción de la junta, exactamente como cualquier decisión de una propietaria humana) y establece override_status en overridden_by_owner en la fila governance_ledger original de Claudia, con la razón de Maya. Tanto la decisión original de Identic AI como la corrección de Maya se conservan y governance_ledger es lo que cuenta la historia completa, ya que el propio activity_log de Paperclip registra la decisión de Claudia y la anulación de Maya de manera idéntica como acciones de la junta. No existe un modo de falla en el que Maya quede excluida de tu propia empresa por tu Identic AI. El compromiso de la arquitectura es que el ser humano siempre sea recuperable. Los patrones no saludables. Tres patrones son señales de advertencia:

1. Divergencia sostenida de alta frecuencia. Si Maya anula a Claudia más del 20% del tiempo, la configuración es incorrecta. O el ámbito delegado es demasiado amplio (Claudia está tomando decisiones que no debería) o los patrones aprendidos de Claudia están sistemáticamente mal calibrados. Es hora de revisar la Decisión 4.
2. Maya deja de leer el registro de gobernanza. Si Maya está demasiado ocupada para leer el resumen semanal, el registro de auditoría se convierte en un peso muerto. La arquitectura sólo funciona si Maya se mantiene en el bucle en la escala correcta; si opta por no participar por completo, volverá a la aprobación automática de facto, la respuesta A incorrecta del Concepto 1.
3. Claudia se muestra demasiado. La falla del espejo: si Claudia le muestra más del 30% de las decisiones a Maya, la propiedad de escala se rompe. Claudia está siendo demasiado conservadora; Es necesario relajar el sobre delegado o sus umbrales de confianza.

Como heurística aproximada y los números deben tratarse como una orientación inicial en lugar de un punto de referencia para optimizar, un estado operativo saludable parece algo así como 90-95% de las decisiones manejadas de forma autónoma por Claudia, 5-10% llegan a Maya, menos del 5% de anulaciones. Las cifras exactas varían según la empresa, la tolerancia al riesgo de Maya y el tipo de trabajo que hace la fuerza laboral. Los rangos numéricos anteriores son ilustrativos, no se comparan con un conjunto de datos publicado. Lo que importa más que alcanzar porcentajes específicos es la forma: la mayoría de las decisiones son autónomas, surge una fracción significativa pero pequeña, las anulaciones son lo suficientemente raras como para que cada una se lea atentamente.

PRIMM: Predecir

Para cada escenario a continuación, clasifícalo como saludable, no saludable: configuración,no saludable: desconexión o no saludable: demasiado conservador:

1. Después de seis meses, Claudia autoaprueba el 92% de las decisiones; Maya anula el 2%; Maya lee el resumen semanal todos los viernes.
2. Después de tres meses, Claudia le muestra el 35% de las decisiones a Maya; Maya los procesa en cuestión de horas.
3. Después de ocho meses, Claudia autoaprueba el 98% de las decisiones; Maya no ha leído el resumen semanal en un mes.
4. Después de dos meses, Claudia autoaprueba el 88% de las decisiones; Maya anula el 22% de ellos.
5. Después de cuatro meses, Claudia autoaprueba el 91% de las decisiones; Maya anula el 4%; Maya ocasionalmente agrega una instrucción de Capa 1 en respuesta a patrones de anulación.

Respuestas: (1) saludable: dentro de los rangos objetivo, propietaria comprometida. (2)no saludable: demasiado conservador: la tasa de aparición es demasiado alta; Es necesario aflojar los umbrales de confianza de Claudia o su sobre delegado. (3)no saludable: desconexión: Maya efectivamente lo ha delegado todo; esta es la aprobación automática_de facto_, la Respuesta Incorrecta A del Concepto 1. (4)no saludable: configuración: tasa de anulación del 22% significa que el sobre delegado es incorrecto o los patrones de Claudia están sistemáticamente mal calibrados; Es hora de revisar la Decisión 4. (5)saludable: la recalibración activa a través de ediciones de instrucciones permanentes es exactamente el ciclo que defiende el Concepto 12.

En pocas palabras: cuando Maya y Claudia no están de acuerdo, la arquitectura lo trata como una señal saludable, no como un fracaso. La anulación actualiza los comentarios de Claudia por decisión; los patrones se perfeccionan con el tiempo; Maya mantiene el control porque la válvula de escape siempre está disponible. Los patrones nocivos a los que hay que prestar atención son la divergencia sostenida de alta frecuencia (configuración incorrecta), la desconexión de Maya del libro de gobierno (arquitectura derrotada) y la superposición de Claudia (propiedad de escala rota). Un estado saludable es ~90-95% autónomo, ~5-10% superficial, menos del 5% anulado.

---

Parte 6: La frontera honesta

El curso ha sido honesto en todo momento acerca de qué partes de la arquitectura se envían y cuáles son de investigación abierta. La Parte 6 es el tratamiento explícito de la frontera abierta: tres conceptos sobre lo que no está completamente resuelto en mayo de 2026, cómo será el camino a seguir y dónde aterriza realmente la afirmación de la octava invariante del Curso Ocho frente a dónde apunta.

Concepto 13: Memoria soberana, donde el juicio acumulado de la propietaria vive a largo plazo

El Concepto 5 estableció que la sesión OpenClaw de Maya vive en el sistema de archivos de Maya local por diseño, no como una opción de participación. Esa propiedad satisface el compromiso de autosoberanía de Tapscott para un solo dispositivo. Lo que no satisface del todo es la carcasa multidispositivo.

Una aclaración antes de continuar: la accesibilidad de la interfaz no es la ubicación de la sesión. Las más de 50 integraciones de OpenClaw (incluidos más de 15 canales de chat: WhatsApp, Telegram, Discord, Slack, Signal, iMessage) significan que Maya puede acceder a tu Identic AI desde cualquier lugar donde tenga su teléfono o portátil y sus apps de mensajería. Telegram en su teléfono, Telegram en su portátil, Discord en la oficina de un compañero de trabajo: todos son interfaces para la misma Identic AI. Pero la accesibilidad de la interfaz y dónde vive la sesión misma son cuestiones diferentes. Las apps de mensajería son servidores proxy sin estado; la sesión (el contexto acumulado de Maya, los patrones aprendidos, las claves de firma) vive en cualquier dispositivo que esté ejecutando el demonio OpenClaw. Por defecto, ese es un dispositivo. El caso de múltiples dispositivos a continuación trata sobre cómo la sesión llega a un segundo dispositivo, no sobre cómo Maya la alcanza.

Las tres opciones arquitectónicas, hoy. Cuando Maya quiere que tu Identic AI la siga a través de su portátil, su teléfono, tu máquina de trabajo, su Mac de casa, se enviarán tres patrones en mayo de 2026:

1. Soberanía de dispositivo único (valor predeterminado). La sesión reside en un dispositivo. Maya usa OpenClaw solo desde ese dispositivo. Autosoberano en sentido estricto; restringido en el sentido práctico.
2. Sincronización alojada por el usuario. Maya ejecuta tu propia capa de sincronización: un servidor privado que ella controla (una Raspberry Pi en casa, un VPS pequeño), que ejecuta un protocolo de sincronización de código abierto. Su OpenClaw en cada dispositivo empuja y extrae del servidor de sincronización. Todavía autosoberano en sentido estricto (Maya es propietaria del servidor); mayor carga operativa.
3. Sincronización en la nube cifrada con clave de usuario. Maya utiliza un servicio de sincronización de terceros, pero la sesión está cifrada en el lado del cliente con una clave que solo Maya posee. El proveedor de la nube almacena texto cifrado; las llaves nunca salen de los dispositivos de Maya. Autosoberano en la práctica si el cifrado se implementa correctamente, pero Maya confía en la implementación del cifrado y en la ausencia de filtraciones de canales laterales.

OpenClaw admite la primera opción lista para usar y señala la segunda y la tercera, pero ninguna de las tres es una solución limpia y sin concesiones para el caso de múltiples dispositivos en mayo de 2026. Tapscott llama a esto "reinventar la pila de IA". Tiene razón.

¿Qué es realmente una investigación abierta? Tres preguntas aún no han recibido respuestas:

1. ¿Cómo sobrevive el contexto acumulado del usuario a la obsolescencia del tiempo de ejecución? Si el proyecto OpenClaw se cierra en 2030 y el usuario tiene 4 años de datos de sesión acumulados, ¿puede migrar a un tiempo de ejecución diferente? Hoy: en principio sí (los datos están en el sistema de archivos de Maya, legibles por humanos); en la práctica, el siguiente tiempo de ejecución tendría que importar el formato de sesión de OpenClaw, lo que supone que el formato es estable. Ésta es una cuestión de soberanía a largo plazo.
2. ¿Qué pasa con la identidad criptográfica? La clave de firma de Maya representa a Claudia. Si Maya quiere pasar a un tiempo de ejecución diferente que utiliza un protocolo de identidad diferente, ¿qué sucede con la continuidad de Claudia en Paperclip? La relación entre la noción de identidad de Identic AI del tiempo de ejecución y la noción de identidad delegada del ecosistema más amplio no está estandarizada.
3. ¿Qué pasa con las copias de seguridad y la recuperación? Si Maya pierde sus dispositivos, sus copias de seguridad y sus credenciales principales simultáneamente, pierde su Identic AI. El patrón que se enviará en mayo de 2026 es Maya es responsable de sus propias copias de seguridad. Si la arquitectura debería respaldar una historia de recuperación más sólida (claves divididas por Shamir, recuperación social) es una cuestión de diseño activa.

El Curso Ocho enseña los compromisos arquitectónicos (sistema de archivos local por defecto, claves propiedad del usuario, sin bloqueo de plataforma) y nombres donde la operacionalización es parcial. El curso no pretende que la historia de la soberanía a largo plazo, múltiples dispositivos y múltiples tiempos esté completamente resuelta.

_En pocas palabras: la historia de la autosoberanía de un solo dispositivo se resuelve mediante el diseño de sesión local del sistema de archivos de OpenClaw. El caso de múltiples dispositivos tiene tres patrones, cada uno con sus compensaciones. El caso de la soberanía a largo plazo (obsolescencia en tiempo de ejecución, continuidad de la identidad, recuperación) es una investigación genuinamente abierta a partir de mayo de 2026. El Curso Ocho enseña los compromisos arquitectónicos y nombra lo que aún no se ha enviado.

Concepto 14: Alineación de valores más allá de la coincidencia de patrones

El concepto 10 distinguió tres capas del contexto acumulado de Claudia: instrucciones explícitas, retroalimentación por decisión y patrones derivados. La tercera capa es la parte del Curso Ocho en la que la enseñanza es menos segura. La coincidencia de patrones no es una alineación de valores y la distinción es importante. Los patrones son superficiales; los valores son estructura. Claudia podría aprender que "Maya tiende a aprobar reembolsos en el rango de $500 a $2000 cuando la cuenta del cliente tiene más de dos años". Ese es un patrón. El valor subyacente sobre el que está actuando Maya podría ser "los clientes de larga data representan un bajo riesgo de fraude y un alto riesgo de abandono, por lo que priorizo ​​su satisfacción": una creencia estructural sobre la dinámica cliente-negocio. Dos políticas diferentes podrían producir el mismo patrón: una basada en los valores de relación con el cliente de Maya, otra basada, digamos, en una heurística arbitraria que Maya tomó de un podcast. Claudia aprender el patrón es realmente útil para las decisiones de rutina; Claudia confundir el patrón con el valor es peligroso cuando el patrón se rompe (un cliente de larga data intenta un reembolso fraudulento; el patrón dice "aprobar"; el valor dice "verificar primero").

Cuando esto sea importante desde el punto de vista operativo. La coincidencia de patrones funciona bien cuando el mundo es estable. Falla en los casos que la arquitectura más necesita manejar correctamente: situaciones novedosas, casos extremos, los momentos en los que el juicio de Maya es más valioso. Una Identic AI que coincide con sus decisiones pasadas es buena en la rutina; una Identic AI que ha modelado sus valores es buena en novedosos. Esto último es lo que señala la transcripción de Tapscott cuando habla de "reflejar tus valores". No es lo que se envió en mayo de 2026.

El estado de vista previa de la investigación. Los laboratorios Anthropic y otros tienen avances de investigación que van más allá: entrevistas para obtener valores, extracción de principios de decisiones pasadas, diálogos explícitos de "¿qué harías si..." que sacan a la luz la estructura subyacente? Estos existen; ninguno de ellos estará listo para el plan de estudios en mayo de 2026 en el sentido de que el Curso Ocho podría enseñarlos como un patrón estable. El compromiso del Curso Ocho es enseñar bien la capa de coincidencia de patrones (Conceptos 10 a 12) y nombrar la capa de alineación de valores como la frontera abierta.

Lo que esto implica para la primitiva delegada. La afirmación del Curso Ocho es que la Identic AI de la propietaria elimina el cuello de botella de la atención de la propietaria. La afirmación es cierta en la capa de coincidencia de patrones: Claudia maneja correctamente las decisiones rutinarias con la suficiente frecuencia como para escalar la fuerza laboral de Maya mucho más allá del límite de 10 a 40 Workers. La afirmación no es del todo cierta en la capa de alineación de valores: Claudia a veces tomará una decisión novedosa que Maya habría tomado de otra manera y la arquitectura tiene que asumir esto y diseñar para la recalibración (Concepto 12). La primitiva delegada escala la empresa nativa de IA en un orden de magnitud, no infinitamente. Más allá de cierta escala (¿cientos de Workers, miles?), la tasa residual de decisiones novedosas se vuelve lo suficientemente grande como para que la delegación pura de coincidencia de patrones no se mantenga y la investigación de alineación de valores debe realizarse para que la arquitectura pueda escalar aún más. No sabemos exactamente dónde está ese techo; el curso es honesto sobre su carácter parcial.

En pocas palabras: la capa de coincidencia de patrones de Claudia (Concepto 10) maneja bien la rutina; su capa de alineación de valores (la frontera abierta) maneja mal lo novedoso. La afirmación del octavo invariante del Curso Ocho es cierta en la capa de coincidencia de patrones: Maya puede escalar su fuerza laboral más allá del límite de atención anterior. La afirmación es parcial en la capa de alineación de valores; existe un límite en algún lugar más allá del cual la delegación puramente basada en patrones deja de escalar. Dónde se ubica ese techo depende de la investigación de alineación de valores que aún no se ha enviado. El curso es honesto sobre su carácter parcial.

Concepto 15: Qué sigue, la economía de Identic AI, la disciplina de evaluación y el cierre de las primitivas arquitectónicas

El Curso Ocho es el último curso de la secuencia arquitectónica de la ruta Agent Factory. El Curso Nueve, que enseña la disciplina transversal del desarrollo impulsado por evaluaciones, cierra la ruta en sí. El Concepto 15 cierra el Curso Ocho y señala lo que viene a continuación en dos escalas: dentro de la ruta (Curso Nueve y la disciplina de evaluación) y más allá (las fronteras abiertas de la economía de Identic AI). Tres cosas para nombrar:

• hacia dónde nos lleva la arquitectura Owner Identic AI a continuación
• cómo se ven realmente los otros casos de uso de Identic AI (del lado del cliente, del lado de los empleados, de igual a igual) a medida que el campo madura
• en qué se convierte la arquitectura de siete invariantes una vez que la disciplina de evaluación del Curso Nueve se envuelve a su alrededor. La economía de Identic AI como la describe Tapscott. De la transcripción de HBR: "Creo que dedicaremos mucho menos tiempo a actividades relacionadas con la ejecución... Los agentes de IA pueden manejar el análisis de coordinación, la programación, fluir a través de todas las demás cosas relacionadas con la ejecución, pueden hacerlo a la velocidad de la máquina. La ejecución se vuelve cada vez más mercantilizada. Y así, como gerente y ejecutivo, lo que diferencia a una empresa ya no es su capacidad de ejecutar, sino su capacidad de pensar en términos generales, de elegir los objetivos correctos, de definir propósito, hacer juicios estratégicos de alta calidad." La forma arquitectónica que Tapscott está describiendo es una red de Identic AIs: del lado de la propietaria en cada empresa nativa de IA, del lado de los empleados en cada fuerza laboral, del lado del cliente en cada individuo, interactuando bajo credenciales firmadas, con los humanos interviniendo solo en lo importante o estratégico. El Curso Ocho construye un nodo de esa red por completo; la red en sí es lo que apunta el Curso Ocho.

Identic AI del lado del cliente como caso de uso de la barra lateral. Una cliente, Sarah, en 2027, 2028 o 2030, tiene su propio OpenClaw ejecutándose en su portátil. Quiere interpretar una cláusula contractual de la empresa de Maya. Ella envía un mensaje a Sarah-OpenClaw (la Identic AI del cliente, no a Maya) a través de WhatsApp: "¿puedes hablar con ContractCo sobre la cláusula 7.3 de mi contrato?" Sarah-OpenClaw firma una solicitud con las credenciales de Sarah y la publica en el Gerente-Agente de la compañía de Maya. El Gerente-Agente verifica la identidad de Sarah (clave de acceso más firma, los mismos primitivos que el Curso Ocho enseña para el caso de Maya pero a través de un límite que no es de confianza), la dirige al Especialista Legal y devuelve la respuesta. La Identic AI de Sarah y la fuerza laboral de Maya se reúnen como pares en la red, mediada por credenciales firmadas, sin que ninguna de las partes sea propietaria de toda la interacción. Esta es la arquitectura que el Curso Ocho permite pero no ofrece. Las primitivas de delegación de confianza en los Conceptos 7-9 se transfieren; el modelo de confianza entre partidos es la pieza que falta.

Identic AI del lado del empleado. Un Worker de la empresa de Maya, un empleado en lugar de un Worker de IA contratado, tiene tu propia Identic AI que le ayuda a redactar correos electrónicos, prepararse para reuniones y gestionar tus tareas. El empleado Identic AI habla con la fuerza laboral de la empresa y con los propios compañeros de Identic AI del empleado. Este es el caso de uso que OpenClaw ya sirve para usuarios individuales: una IA personal que vive en la máquina de una persona, accesible a través de sus apps de mensajería, es exactamente la configuración de nodo único que ofrece OpenClaw. El Curso Ocho no lo enseñó porque la caso estructural era de la propietaria; pero la arquitectura se extiende de forma natural.

Identic AI entre pares. Las Identic AIs de dos individuos interactúan directamente: la Identic AI de Maya habla con la Identic AI de su cofundadora para coordinar una reunión; la Identic AI de Sarah negocia un reembolso directamente con la Identic AI de Maya. El estado final de Tapscott es que los humanos estén informados sólo en lo estratégico; la interacción rutinaria ocurre entre las IA. Esto es más especulativo que los demás; el problema de la delegación de confianza en la capa peer-to-peer tiene subproblemas abiertos.

La tesis de las siete invariantes, operacionalizada. Lo que era especulativo cuando se abrió el Curso Tres es concreto después de que se cierra el Curso Ocho. Utilizando el ordenamiento y denominación de tesis canónicas:

Invariante	Qué requiere	Curso que lo operacionaliza en profundidad
1. El ser humano es el protagonista	Intención humana, presupuesto, dotación de autoridad, rendición de cuentas	Fundamental al otro lado de la ruta
2. Todo ser humano necesita un delegado	Un agente personal que contiene contexto, juicio y autoridad	Curso Ocho
3. La fuerza laboral necesita una capa de gestión	Contratar, asignar, gobernar, observar, jubilarse: la fuerza laboral OS	Curso Seis (Paperclip)
4. Cada Worker elige su propio motor	Tiempo de ejecución por Worker adaptado al trabajo	Curso Tres (presenta la elección del motor)
5. Cada Worker corre contra un sistema de registro	Tienda autorizada accesible a través de MCP	Curso Cuatro
6. La fuerza laboral se puede ampliar según las políticas	La contratación como capacidad exigible	Curso Siete (Agentes Gestionados por Claude)
7. La fuerza laboral funciona con un sistema nervioso	Eventos, durabilidad, control de flujo bajo sobre	Curso Cinco (Inngest)

Siete invariantes, seis cursos que los operacionalizan en profundidad (Tres, Cuatro, Cinco, Seis, Siete, Ocho; la Invariante 1 recorre todos ellos como el compromiso fundamental con el principio humano). La arquitectura está operativa. Una empresa nativa de IA que tiene los siete es escalable, auditable, gobernable y construida alrededor de primitivos que no quedarán obsoletos en la próxima versión del tiempo de ejecución, porque la arquitectura se compromete con patrones, no con_proveedores_. Lo que luego añade el Curso Nueve es la disciplina impulsada por la evaluación que convierte "construido y en funcionamiento" en "mediblemente confiable". La arquitectura está completa después del Curso Ocho; el plan de estudios se completa después del Curso Nueve.

Qué sigue, dentro de la ruta y más allá. El Curso Ocho abordó tres áreas de investigación abiertas: memoria autónoma en tiempos de ejecución (Concepto 13), alineación de valores más allá de la coincidencia de patrones (Concepto 14) y el modelo de confianza entre partes para la Identic AI del lado del cliente y de igual a igual (Concepto 15). Estos aún no forman parte del plan de estudios; son la frontera activa de la investigación. Un lector que termine el Curso Ocho tiene el marco para evaluar las soluciones a estos problemas a medida que se presentan: qué hace que una propuesta de alineación de valores sea creíble, qué hace que una arquitectura de confianza entre partidos sea autosoberana, qué hace que una historia de soberanía a largo plazo sea honesta.

Las primitivas arquitectónicas se ponen en funcionamiento después del Curso Ocho; la ruta continúa en el Curso Nueve. El Curso Nueve enseña lo que se postergó deliberadamente a lo largo de la secuencia arquitectónica: la disciplina transversal del desarrollo impulsado por la evaluación. Cada Worker construido en los Cursos 3-7, cada contratación autorizada en el Curso Siete y cada decisión delegada que Claudia toma en el Curso Ocho tienen la misma propiedad: ninguno de ellos es_mediblemente_ digno de confianza hasta que su comportamiento haya sido evaluado, rastreado, calificado y mejorado. El Curso Nueve aborda esa disciplina utilizando una pila de evaluación en capas (calificación de seguimiento para el comportamiento del agente, evaluaciones a nivel de repositorio para el flujo de trabajo de desarrollo, evaluaciones RAG para la capa de conocimiento, observabilidad de la producción). La analogía: el desarrollo basado en pruebas era la disciplina final de cualquier plan de estudios de ingeniería SaaS; el desarrollo impulsado por la evaluación es la disciplina final de cualquier plan de estudios de IA agente. Arquitectura (Cursos 3 a 8) más disciplina (Curso 9) equivalen al itinerario completo de Agent Factory.

Conclusión: El Curso Ocho pone en práctica la invariante 2 de la tesis de Agent Factory, el delegado, en la configuración específica que permite a una empresa nativa de IA escalar más allá de la atención de su fundadora. Las siete invariantes arquitectónicas se operacionalizan en profundidad en los cursos 3 a 8; el Curso Nueve agrega la disciplina transversal del desarrollo impulsado por evaluaciones que convierte la arquitectura en algo medible y confiable en producción. Las fronteras abiertas de investigación mencionadas en los Conceptos 13-15 (memoria autosoberana, alineación de valores, confianza entre partidos) se encuentran más allá tanto de la arquitectura como de la disciplina; son el trabajo de la próxima década.

---

Cómo llegar a ser realmente bueno en esto

Leer el Curso Ocho no te hace bueno para crear una Owner Identic AI. Su uso sí lo es y el camino se ve así: cuatro fases, en orden, a lo largo de unas pocas semanas.

Fase 1: Vive con una Identic AI en apuestas bajas (semana 1). Instala OpenClaw en tu propia máquina, tu máquina real, no en un sandbox. Incorpora una persona real: la tuya, no la de Maya. Envíale un mensaje a través de tu app de mensajería real sobre tu día real. Dale algunas instrucciones permanentes sobre cómo quieres que maneje tu correo electrónico real, tu calendario real o tu lista de tareas real. Esta fase no se trata de gobernanza. Se trata de desarrollar la intuición de cómo se siente una Identic AI cuando realmente vive contigo, cuando su memoria se acumula, cuando te sorprende con un empujón proactivo. Estarás listo para el caso de uso de gobernanza solo después de que llegue esta fase; saltar directamente a la gobernanza delegada sin la intuición personal de la IA produce errores de calibración.

Fase 2: observa dónde te equivocas (semana 2). Presta atención a los momentos en que tu Identic AI muestra algo que habrías ignorado o actúa automáticamente sobre algo que hubieras querido ver. Cada uno de estos es una señal: o las instrucciones permanentes están equivocadas o los patrones que está aprendiendo están fallando. Corrige en lenguaje sencillo; mira el siguiente caso similar para ver si la corrección se mantuvo. Tu sentido de cuándo confiar en tu Identic AI y cuándo no se construye observándola actuar según tus decisiones reales, no leyendo sobre Maya. Fase 3: aplica la arquitectura a la gobernanza (semana 3+). Si eres propietaria de una empresa nativa de IA, configura tu Identic AI como delegado de gobernanza frente a tu fuerza laboral real de Paperclip. Usa el sobre conservador de la Decisión 4 como punto de partida. Establece el modo de ejecución en seco (indicador --dry-run de la Decisión 3) durante los primeros tres días; leer lo que Claudia habría hecho; genera confianza en la calibración antes de permitir la firma real. Luego, empieza a trabajar con firmas reales durante una semana; observar el registro de gobernanza; espera perfeccionar activamente las instrucciones permanentes. La invariante 2, el delegado, se convierte en una propiedad de tu operación, no en un concepto de un curso. Fue entonces cuando el Curso Ocho hizo su trabajo.

Fase 4: Estado estable y calibración activa (mes 2+). Después de aproximadamente 4 semanas de funcionamiento, el ritmo debería parecer invisible: verifica con tu Identic AI varias veces al día las aprobaciones que se muestran, lee el resumen de gobernanza semanal en 10 minutos y edita ocasionalmente una instrucción permanente. Los patrones arquitectónicos del Curso Ocho todavía funcionan, pero los experimentas como "mi IA maneja la rutina, yo manejo las consecuencias, reviso semanalmente". Ese es el punto.

Un modo de error al que debes prestar atención cuando lo uses por ti mismo. La forma más común en la que los lectores hacen un mal uso del Curso Ocho es optar por no participar en la revisión semanal. La propiedad de seguridad de la arquitectura, que Maya sigue siendo la principal con recuperación de auditoría completa, solo se mantiene si Maya permanece en el circuito en la escala correcta. Si se da cuenta de que ignora su resumen de gobernanza durante dos semanas seguidas, ha caído en la Respuesta incorrecta A del Concepto 1 (aprobación automática de facto). Recupérate volviendo a participar en la revisión semanal antes de cambiar cualquier otra cosa.

Si no eres propietaria de una empresa nativa de IA: los patrones aún se aplican a escalas más pequeñas. Una Identic AI que maneja tus aprobaciones de correo electrónico personales, tus conflictos de calendario o tu clasificación de información utiliza el mismo modelo de aprendizaje de tres capas y el mismo ciclo de recalibración. El Curso Ocho enseña arquitectura; la superficie a la que lo aplicas es tuya para elegir.

---

Referencia rápida

Los 15 conceptos en una línea cada uno

1. Una empresa nativa de IA deja de escalar cuando la propietaria se convierte en el cuello de botella. La API de contratación se puede llamar; la propietaria no lo es. Entre 10 y 40 Workers, la propietaria se convierte en el cuello de botella.
2. La Identic AI es la respuesta arquitectónica, según el marco HBR de Tapscott: personalización + reflejo de valores + extensión de uno mismo + autosoberanía + memoria persistente.
3. La Identic AI de la propietaria es el caso estructural. El Curso Ocho enseña bien una configuración; el concepto 15 nombra a los demás (del lado del cliente, del lado del empleado, de igual a igual) como la frontera.
4. OpenClaw es el tiempo de ejecución. Código abierto, propiedad del usuario, máquina local, accesible a través de la app de mensajería. Verificado de openclaw.ai.
5. La sesión es de Maya. Su contexto acumulado vive en el sistema de archivos de Maya en archivos legibles por humanos. La autosoberanía puesta en práctica.
6. Aplicaciones de chat como capa de interfaz. La Identic AI vive donde ya vive la propietaria: más de 50 integraciones, incluidos más de 15 canales de chat (WhatsApp, Telegram, Discord, Slack, Signal, iMessage), no una aplicación separada.
7. Dos directores, identidades distintas. activity_log de Paperclip registra cada aprobación como una acción de la junta; el propio governance_ledger del curso lleva la distinción propietaria humana versus propietaria-Identic-AI. Una auditoría veraz requiere distinción.
8. Delegación firmada de credenciales locales. La Identic AI de Maya firma con una clave que posee Maya; el Paperclip verifica; revocable desde cualquier dispositivo que Maya aún controle.
9. La intersección de dos sobres. El sobre propietaria-autoridad (techo) de Maya intersectado con el sobre delegado de Claudia (subconjunto que Maya eligió) es igual a lo que realmente se ejecuta.
10. Tres capas de contexto acumulado: instrucciones permanentes explícitas, retroalimentación por decisión, patrones derivados. El tercero es probabilístico; las Identic AIs honestas lo dicen.
11. El registro de gobernanza. Auditoría de solo anexo de cada decisión que Identic AI tomó en nombre de la propietaria. Resumen semanal a Maya.
12. El desacuerdo es una señal saludable. Maya anula a Claudia y las actualizaciones del patrón. Una tasa de anulación sostenida de más del 20% significa que la configuración es incorrecta.
13. La memoria autónoma en la capa multidispositivo y de largo plazo es una investigación abierta. El Curso Ocho enseña los compromisos y nombra lo parcial.
14. Los patrones no son valores. Claudia maneja bien la rutina; falla en lo novedoso. El primitiva delegada escala la fuerza laboral en un orden de magnitud, no infinitamente.
15. La secuencia arquitectónica cierra después del Curso Ocho; la ruta se cierra después del Curso Nueve. Siete invariantes arquitectónicos operacionalizados en profundidad en los Cursos 3-8; el desarrollo impulsado por la evaluación (Curso Nueve) es la disciplina transversal que convierte la arquitectura en un comportamiento medible y confiable. La Identic AI del lado del cliente y de igual a igual es la frontera de investigación abierta más allá de ambos.

Comando referencia rápida

¿Quieres...	Comando OpenClaw
Instalar en una máquina nueva	curl -fsSL https://openclaw.ai/install.sh | bash o npm i -g openclaw
Incorporación inicial	openclaw onboard
Verifica la instalación	openclaw status
Listar skills instaladas	openclaw skills list
Instalar una nueva habilidad	openclaw skills install <name> (de ClawHub)
Actualizar a la última versión	openclaw update --channel stable

Referencia rápida de ubicación del archivo

Qué	Dónde
Sesión y contexto acumulado	~/.openclaw/workspace/ (el espacio de trabajo del agente es la memoria persistente de OpenClaw)
Persona y contexto duradero	Archivos ~/.openclaw/workspace/USER.md, MEMORY.md y espacio de trabajo context/
Clave de firma de Identic AI	~/.openclaw/keys/identic-ai.pem (o almacén de claves de plataforma)
Skills de autoría local	~/.openclaw/workspace/skills/<name>/SKILL.md
Registros	vía openclaw logs (consulta los documentos de OpenClaw para conocer las ubicaciones de los registros en el disco)

Árbol de decisión de tipo de extensión

Need the owner's Identic AI to handle a routine decision class autonomously?
    → Configure the delegated envelope (Decision 4 / Concept 9) and a standing instruction.

Need to teach the Identic AI a new pattern from a recent override?
    → That's automatic: per-decision feedback joins Layer 2. Concept 10.

Need the company workforce to recognize a new Identic AI principal?
    → Identity registration at Paperclip (Decision 4 / Concept 8).

Need to revoke a compromised Identic AI?
    → Revocation flow (Decision 7 / Concept 8). From any device Maya still controls.

Cuando algo se siente mal

The owner is reading too many approvals → delegated envelope is too narrow.
    Concept 9. Expand the envelope conservatively, watch for new failure modes.

The Identic AI is auto-approving things the owner would have surfaced → patterns
    are miscalibrated. Concept 12. Use the override; the next pattern update incorporates it.

The Identic AI is unreachable → check chat-app integration first (Decision 1),
    then OpenClaw daemon status (`openclaw status`), then the Paperclip-integration
    skill's config (Decision 3).

The audit trail is incomplete → governance ledger writes are silently failing.
    Concept 11. Check Paperclip's activity_log for the missing rows; the Identic AI's
    side of the write may have succeeded while Paperclip's side failed.

---

Referencias y lecturas adicionales

• Tapscott, Don. (2026). You to the Power of Two: redefiniendo el potencial humano en la era de la Identic AI. La fuente del marco de "Identic AI" que hereda el Curso Ocho.
• HBR IdeaCast Episodio 1066, "Con el surgimiento de agentes, estamos ingresando al mundo de la Identic AI" (17 de febrero de 2026). Don Tapscott entrevistado por Adi Ignatius. hbr.org/podcast/2026/02/with-rise-of-agents-we-are-entering-the-world-of-identic-ai
• Sitio oficial de OpenClaw: openclaw.ai
• Documentación de OpenClaw: docs.openclaw.ai
• OpenClaw GitHub: github.com/openclaw/openclaw
• Documentación de Paperclip: docs.paperclip.ing
• Curso Siete (el prerrequisito directo): De la fuerza laboral fija a la dinámica
• Curso Sexto (el plano directivo): De un Worker a una Fuerza laboral
• Curso Cinco (la dotación operativa): De FTE digital a Worker de producción
• Curso Nueve (el próximo curso): Desarrollo impulsado por evaluaciones para IA agéntica, la disciplina transversal que convierte la arquitectura de los cursos 3 a 8 en un comportamiento de producción medible y confiable

---

_El Curso Ocho es la operacionalización profunda del Invariante 2 de la tesis de Agent Factory: el delegado que contiene el contexto, el juicio y la autoridad del ser humano. Luego, el Curso Nueve agrega la disciplina transversal del desarrollo impulsado por la evaluación que convierte a cada Worker, cada contratación y cada decisión delegada en algo mediblemente confiable. Lo que se construye con ambos, la arquitectura de los cursos 3-8 y la disciplina del curso 9, es lo que viene a continuación.