De fuerza laboral fija a dinámica: la API de contratación, las brechas de capacidad y el registro de talento

15 conceptos. Unas 2 a 3 horas de lectura conceptual (más si tomas en serio las predicciones PRIMM). 2 a 3 horas de laboratorio práctico. Planifica medio día en total.

Un curso acelerado de continuación. Este es el Curso siete de la ruta de codificación agéntica. El Curso tres, Construye agentes de IA con OpenAI Agents SDK y Cloudflare Sandbox, construyó un agente de chat con streaming. El Curso cuatro, De agente de IA a FTE digital, convirtió ese agente de chat en un FTE digital con Skills, un sistema de registro en Neon Postgres y MCP. El Curso cinco, De FTE digital a Worker de producción, envolvió el FTE digital en una envolvente operativa de Inngest para que el mundo pudiera despertarlo y los fallos no pudieran hacerle perder su estado. El Curso seis, De un Worker a una fuerza laboral, agregó la capa de gestión de Paperclip para que uno o más Workers se convirtieran en una fuerza laboral con asignaciones, presupuestos, aprobaciones y una pista de auditoría. La fuerza laboral era de tres Workers elegidos por la persona humana al crear la empresa. El Curso siete trata sobre qué ocurre cuando se necesita un cuarto Worker y la fuerza laboral llama a una API de contratación para incorporarlo.

La idea que hace que todo lo demás encaje es esta: en una empresa nativa de IA, contratar no es un movimiento trimestral de RR. HH. Es una capacidad invocable que la fuerza laboral usa sobre sí misma, protegida por exactamente la misma primitiva de aprobación que protege un reembolso de $500. La junta no escribe una oferta de empleo. Lo hace el Manager-Agent. La junta la aprueba y el nuevo Worker entra en el organigrama esa misma tarde. Al final de este curso, la fuerza laboral de soporte al cliente del Curso seis habrá detectado una capacidad que no tiene, redactado una propuesta de contratación, pasado esa propuesta por la puerta de aprobación y dado la bienvenida a un especialista legal en el organigrama, todo sobre el mismo registro activity_log más cost_events en el que escriben los tres Workers originales.

Por qué esto importa para Agent Factory: el Invariante 6 completo

La tesis nombra siete invariantes para una empresa nativa de IA. El Curso seis cubrió tres (el plano de gestión, el humano como principal y parte del sistema nervioso). El Curso siete cubre la afirmación más profunda: el Invariante 6, contratar es una capacidad invocable. Esta es la frase marco del arquitecto, la idea alrededor de la cual se construye todo este curso:

"Una fuerza laboral que no puede crecer por sí misma es una empresa fija; una fuerza laboral que puede crecer por sí misma bajo aprobación es una empresa nativa de IA. En Agent Factory, contratar no es un movimiento de RR. HH.; es una llamada a función desde el gerente, que toma una descripción de puesto como entrada, devuelve un Worker como salida y está protegida por la misma primitiva de aprobación que protege cualquier otra acción importante."

Con eso se cierran seis de los siete invariantes. El restante, el Invariante 2 (el delegado de Edge), pertenece al Curso ocho.

Cuatro propiedades hacen que la contratación sea una capacidad especialmente interesante en una empresa nativa de IA, propiedades que no existen en ninguna otra llamada a herramienta. Cada una tendrá su propio Concepto más adelante; esta es la forma general:

La decisión de contratar es, en sí misma, una decisión de agente. Un Worker sin autoridad para contratar aún puede señalar la brecha. Un Worker con can_create_agents=true puede redactar y enviar la propuesta. La línea la define la envolvente de la empresa (Invariante 1), no el código. (Conceptos 1, 3.)
El nuevo Worker hereda una envolvente de autoridad que no existía antes de su contratación. El contract_modify=allow de un especialista legal no está en la envolvente de ningún Worker existente. La solicitud de contratación también es el lugar donde se negocia la nueva envolvente. (Concepto 8.)
Una contratación es un acto de nivel junta, incluso cuando la propone un agente. La puerta de aprobación del Curso seis es la misma puerta. El artefacto de la propuesta (descripción del puesto, evaluación de capacidad, presupuesto esperado) es lo que ve la junta. (Concepto 7.)
Las contrataciones son reversibles. El Curso seis trataba a los Workers como configurados una sola vez al inicio. El Curso siete agrega el ciclo de vida: contratar, evaluar, desplegar, retirar y volver a contratar cuando haga falta. El registro de talento rastrea todo el proceso. (Conceptos 7, 14.)

La tesis de Agent Factory titula este Invariante 6 como "La fuerza laboral es expandible bajo política": la fuerza laboral puede crecer por sí misma bajo la autoridad de la junta. El Curso cinco cubrió el Invariante 7 (el sistema nervioso) y parte del Invariante 1 (HITL). El Curso seis cubrió el Invariante 3 (el plano de gestión) y llevó el Invariante 6 hasta el borde. El Curso siete cierra por completo el Invariante 6 y deja solo el Invariante 2 (el delegado de Edge) para el Curso ocho.

Sobre la elección de plataforma

El Curso seis te enseñó a usar Paperclip (paperclip.ing, github.com/paperclipai/paperclip) como la capa de gestión agéntica. El Curso siete amplía esa misma instancia. El mismo npx paperclipai onboard --yes del Curso seis te da la API de contratación. No es un producto distinto, sino un endpoint distinto. El endpoint verificado que enseña el Curso siete es POST /api/companies/{companyId}/agent-hires. El flujo de gobernanza verificado es este: la contratación devuelve pending_approval, la junta comenta en el hilo de aprobación y el agente se despierta con PAPERCLIP_APPROVAL_ID cuando se aprueba.

El Curso siete ejecuta el ejemplo trabajado en dos adaptadores de runtime nativos de Paperclip, en paralelo: claude_local y opencode_local. Ambos se distribuyen como primitivas de primera clase de Paperclip; Paperclip inicia por sí mismo la CLI local del agente de codificación (claude sin interfaz para claude_local, opencode sin interfaz para opencode_local) en cada heartbeat, inyecta PAPERCLIP_API_URL y PAPERCLIP_API_KEY en el entorno de la CLI, y la CLI ejecuta el turno contra la propia API de Paperclip. Sin servicio externo, sin URL entrante, sin relay, sin cuenta separada en la nube. La misma carga útil de contratación solo cambia en adapterType y adapterConfig, que es el punto arquitectónico: desde la perspectiva del plano de gestión, contratar es agnóstico al sustrato, y el par de CLI locales es la prueba más barata posible.

¿Por qué dos adaptadores y no uno? Por dos razones, en orden de peso.

La portabilidad multiproveedor es la prueba vinculante de "agnóstico al sustrato". Un ejemplo trabajado con un solo adaptador siempre se lee como "la arquitectura es genérica si eliges este runtime". Ejecutar la contratación idéntica en claude_local (un solo proveedor, solo modelos de Anthropic) y en opencode_local (multiproveedor; el mismo adaptador puede manejar Anthropic, OpenAI, Google o cualquier proveedor admitido por OpenCode mediante un slug provider/model) demuestra la propiedad de forma concreta. Si el lector quiere que el especialista legal use anthropic/claude-opus-4-7, la pestaña opencode_local de la Decisión 4 muestra el cambio. Si lo quiere en openai/gpt-5.2-pro, solo cambia la cadena adapterConfig.model. El bucle de contratación no se movió.
Cero infraestructura significa que el lector puede terminar el laboratorio. Ambos adaptadores se ejecutan en la misma máquina que el daemon de Paperclip. Sin acceso beta, sin cuenta separada en la nube, sin servidor relay, sin URL entrante. El lector instala dos CLI (claude y opencode), autentica cada una una vez, y el resto del laboratorio son llamadas de API a Paperclip. Los sustratos más difíciles de integrar (productos gestionados en la nube como Claude Managed Agents, u opciones alojadas por proveedores como Cursor Cloud) se ganan su lugar cuando la carga de trabajo los exige: consulta la tabla de sustratos del Concepto 6 para ver la rúbrica de decisión y las compensaciones.

Si tu equipo prefiere un runtime gestionado en la nube (la opción relevante de Anthropic es Claude Managed Agents; el Concepto 6 la nombra explícitamente) o un endpoint autoalojado de Agent SDK, la API de contratación no cambia. Solo difieren adapterType y adapterConfig. La Decisión 4 muestra las dos pestañas locales en paralelo; la tabla de sustratos del Concepto 6 cubre las alternativas nombradas.

Aspectos ásperos conocidos a mayo de 2026 (no te sorprendas cuando los encuentres)

Claude Managed Agents está en beta pública. El encabezado beta managed-agents-2026-04-01 es obligatorio en cada solicitud. Los comportamientos pueden refinarse entre versiones.
La orquestación multiagente de CMA es una vista previa de investigación que requiere una solicitud de acceso separada (según la descripción general oficial). El ejemplo trabajado del curso usa sesiones CMA de un solo agente y no depende de la función multiagente.
El flujo de aprobación de contrataciones de Paperclip está implementado y disponible, pero la interfaz para escribir políticas personalizadas de aprobación automática (Concepto 9) todavía depende en parte de la CLI. Espera editar JSON, no hacer clic en botones, para cualquier política más sofisticada que "aprobar automáticamente contrataciones de capacidad temporal por debajo de $X al mes".
La atribución de costos por issue cuando una contratación se dispara por un issue (el enlace sourceIssueId) se registra correctamente en activity_log, pero consultar "cuánto costó la contratación en tiempo de propuesta, tiempo de evaluación y primer mes de trabajo" requiere unir tres tablas. Hay un issue abierto que rastrea una vista unificada hire_lifecycle.

Estas no son razones para evitar contratar. Son el estado normal de una API de frontera que es joven, popular y mejora rápido. Sí son razones para fijar versiones, preferir la contratación guiada por código sobre la guiada por interfaz para cualquier cosa más allá del caso más simple y nunca aprobar automáticamente contrataciones que concedan una autoridad que un Worker todavía no tenga en algún punto del organigrama.

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

Las cuatro afirmaciones, en orden:

La fuerza laboral puede detectar que ningún Worker del organigrama puede encargarse de este trabajo.
El Manager-Agent redacta una propuesta de contratación: descripción del puesto, eval pack, presupuesto esperado y borrador de la envolvente de autoridad.
La propuesta pasa por la puerta de aprobación del Curso seis. La persona humana la ve. La persona humana decide.
Tras la aprobación, POST /api/companies/{id}/agent-hires de Paperclip aprovisiona el nuevo Worker contra el runtime elegido (Claude Managed Agents para el ejemplo trabajado). El organigrama ahora tiene cuatro Workers en lugar de tres.

La versión en lenguaje claro, si algo de lo anterior te perdió

En el Curso seis, construimos una pequeña empresa de IA con tres Workers: soporte de nivel 1, especialista de nivel 2 y un Manager-Agent que enruta entre ellos. En este curso, la empresa nota que necesita un cuarto Worker (le siguen llegando preguntas de revisión contractual que ninguno de los tres puede manejar bien). El Manager-Agent redacta una propuesta de contratación y pide permiso. El candidato se evalúa antes de que la junta humana lo vea. Tras la aprobación, el nuevo Worker se agrega al organigrama. Todo lo demás del curso detalla cómo funciona realmente cada uno de esos pasos.

Resumen del Curso seis: la fuerza laboral que estás ampliando (haz clic para expandir)

El Curso seis construyó una fuerza laboral de soporte al cliente con tres Workers sobre Paperclip. Los Workers eran:

Soporte de nivel 1 (la función de Inngest para correos de clientes del Curso cinco, adaptada mediante el adaptador http): maneja consultas rutinarias sobre reembolsos, preguntas frecuentes y estado; presupuesto de $200 al mes; refund_max=$50; el correo electrónico externo requiere aprobación.
Especialista de nivel 2 (un adaptador claude_local): maneja casos complejos de varios turnos y escalaciones desde el nivel 1; presupuesto de $800 al mes; refund_max=$500; correo electrónico externo permitido.
Manager-Agent (un adaptador http): orquesta el enrutamiento, comenta en issues y solicita aprobaciones; presupuesto de $200 al mes; refund_max=$0; todas las acciones importantes requieren aprobación.

Las ocho Decisiones del Curso seis conectaron estos tres Workers a Paperclip, definieron la envolvente de la empresa (refund_max=$5000, contract_modify=board_only), enrutaron correos entrantes por activity_log y demostraron la puerta de aprobación con un reembolso de $750 (Decisión 6). El Curso siete asume que esa fuerza laboral existe y está en ejecución.

Si te saltaste el Curso seis, la sección Fuerza laboral frente a Worker de abajo te da suficiente entrada para seguir el Curso siete, pero no tendrás una fuerza laboral en la cual contratar. Primero tendrás que levantar el laboratorio del Curso seis.

Dónde encaja esto: hoja de referencia

#	Concepto	Capa	Qué podrás responder después
1	Una fuerza laboral que no puede crecer por sí misma es una empresa fija	Plano de gestión	¿Por qué la capacidad de contratar es tan importante como el acto de contratar? Porque una fuerza laboral fija es una empresa fija.
2	Brechas de capacidad: tres tipos de señal	Plano de gestión	¿Cómo sabe el Manager-Agent que se necesita un Worker? Baja confianza de enrutamiento, escalaciones repetidas, ningún Worker elegible por coincidencia de habilidades.
3	Contratar frente a escalar, poner en cola o rechazar	Plano de gestión	¿Cuál es la respuesta correcta ante una brecha de capacidad? Árbol de decisión sobre volumen, valor y novedad.
4	La descripción del puesto como código	API de contratación	¿Cómo se ve una solicitud de contratación? Una carga útil JSON con rol, capacidades, adaptador, runtime e issue de origen.
5	Evaluación de capacidad antes de contratar	API de contratación	¿Cómo se prueba un Worker candidato antes de darle issues reales? Con un eval pack que incluye una rúbrica puntuada y aceptación/rechazo.
6	Selección de sustrato: CLI locales, Agent SDK, nube gestionada o `process`	Runtime	¿Cuándo pones un nuevo Worker en un adaptador local nativo de Paperclip (el ejemplo trabajado), frente al Agent SDK, Claude Managed Agents o `process`? Tabla de decisión.
7	La puerta de aprobación de contratación	Plano de gestión	¿Cómo se mapea la primitiva de aprobación del Curso seis a la contratación? La misma primitiva, con una carga útil más rica (propuesta, evaluación, presupuesto, envolvente).
8	Envolvente de autoridad para nuevas contrataciones	Plano de gestión	¿Cómo decides qué `refund_max` recibe un rol recién creado? Se negocia en la propuesta de contratación, queda bloqueado al aprobarse y se registra en `activity_log`.
9	Política de aprobación automática para una clase de contrataciones	Plano de gestión	¿Cuándo es aceptable la contratación sin supervisión? Clases preaprobadas (capacidad temporal, especialidades estrechas bajo un techo de costo), auditadas de forma continua.
10	El primer heartbeat del Worker	Laboratorio	¿Qué ocurre entre la aprobación y el primer issue real del nuevo Worker? Heartbeat activado, enrutamiento, el Worker sale de `idle` para hacer trabajo real.
11	Retiro y recontratación: el ciclo de vida completo	Laboratorio	¿Qué ocurre cuando baja el tráfico? Pausa el Worker (Paperclip distribuye esta primitiva como "Pause"). Se preservan tres cosas durante el ciclo; recontratar es más rápido.
12	El registro de talento: cómo se ve una fuerza laboral de seis meses	Auditoría	Un registro consultable de cada contratación, evaluación, retiro y recontratación. Cinco consultas SQL canónicas responden las preguntas operativas que una junta realmente hace.
13	La pregunta de portabilidad de agentes	Abierto	¿Puede un Worker contratado en la Empresa A servir a la Empresa B? La receta (definición, system prompt, eval pack) puede viajar; la relación no.
14	Por qué importa el registro de talento: memoria institucional ante cambios de personal	Auditoría	Tres propiedades (solo anexos, correlación cruzada, consultable en cualquier momento) que permiten que un log de seis meses reemplace la memoria institucional de una persona que se va.
15	Qué sigue: el Invariante 2 y Edge	Adelanto	¿Dónde retoma el Curso ocho? El invariante restante: delegación en Edge mediante OpenClaw.

¿Estás listo para este curso?

Lista de verificación de prerrequisitos

El Curso siete asume un lector técnico que cumple alguna de estas condiciones:

Completaste el Curso seis, o tienes el equivalente. Levantaste Paperclip localmente, contrataste tres Workers en una empresa, conectaste un flujo de aprobación y viste cómo se poblaba activity_log.
Puedes leer TypeScript, aunque no puedas escribirlo con fluidez. El laboratorio usa principalmente TypeScript (el lenguaje nativo de Paperclip) para la lógica de detección de brechas del Manager-Agent, el generador de propuestas de contratación y el cableado del flujo de aprobación. Tu asistente de IA también puede producir fragmentos de Python, SQL o shell cuando una subtarea concreta encaje mejor con ellos (el ejecutor del eval pack encaja naturalmente en Python; las consultas del registro de talento son SQL). Todo el código es de solo lectura para seguir el curso; el patrón de briefing significa que tu asistente de codificación con IA escribe todo. Tú redactas el briefing, revisas y apruebas. Si un bloque de código te resulta desconocido, la respuesta correcta es pedirle a tu asistente que lo explique, no escribirlo tú mismo.
Tienes las dos CLI locales de agentes de codificación instaladas y autenticadas. La Decisión 4 ejecuta la misma contratación en claude_local (que inicia la claude CLI sin interfaz en cada heartbeat) y opencode_local (que inicia la opencode CLI sin interfaz). Instala ambas, ejecuta claude --version y opencode --version para confirmar, y autentica cada una una vez. claude_local necesita una cuenta de Anthropic; opencode_local puede enrutar a cualquier proveedor que OpenCode admita (Anthropic, OpenAI, Google y otros) mediante un slug provider/model, así que la clave de proveedor que traigas depende del slug que pongas en adapterConfig.model. Si solo quieres ejecutar una pestaña en la Decisión 4, instala solo esa CLI; el laboratorio sigue enseñando el mismo bucle de contratación, solo que lo ves en un sustrato. Si más adelante prefieres un runtime gestionado en la nube, la tabla de sustratos del Concepto 6 cubre Claude Managed Agents (el producto de agentes de larga duración alojado por Anthropic, en beta pública a mayo de 2026) y Claude Agent SDK como alternativas nombradas con sus propias compensaciones.
Entiendes las aprobaciones como una primitiva. Si "aprobación = Paperclip suspende la ejecución, publica una solicitud para la junta, espera de forma durable y reanuda según la decisión de la junta" se lee como un patrón claro y no como un misterio, estás calibrado. Si no, vuelve al Concepto 11 del Curso seis antes de continuar.
Te sientes cómodo con que 'contratar un Worker de IA' sea el verbo correcto. A algunos lectores les resulta chocante el vocabulario de dotación corporativa. Lo usamos deliberadamente, no como metáfora. Las decisiones arquitectónicas (envolvente, presupuesto, retiro, registro) solo tienen sentido si tomas en serio el marco de rol y empleo. Si prefieres pensarlo como "registrar un nuevo proceso de larga duración bajo la capa de gestión", eso es exactamente lo que ocurre por debajo; el vocabulario es el asa más sencilla para la misma maquinaria.

Si cualquiera de los cinco puntos se siente débil, empieza por los repasos enlazados antes de continuar. El curso es denso; los prerrequisitos hacen que se sienta ligero.

¿Nuevo por aquí? El Curso siete es denso: esta es la rampa de entrada

Este es el séptimo de siete cursos de la ruta de Agent Factory. Si los cinco prerrequisitos anteriores te suenan desconocidos, avanza hacia atrás: Curso seis: De un Worker a una fuerza laboral es el prerrequisito directo (Paperclip más el plano de gestión). Antes de eso: Curso cinco: De FTE digital a Worker de producción (la envolvente operativa de Inngest), luego Curso tres: Construye agentes de IA (el bucle del agente) y después el capítulo PRIMM-AI+ si eres completamente nuevo en la codificación asistida por IA. El Curso siete referencia conceptos del Curso seis cada una o dos páginas; entrar en frío es más difícil que completar la rampa.

Si no puedes hacer la rampa ahora mismo pero quieres seguir los conceptos, puedes simular los prerrequisitos con mucho menos que la pila completa del Curso seis:

Lee el inicio rápido de Paperclip (unos 15 minutos) y la página de aprobaciones (unos 10 minutos).
Hojea la Lección 1 de PRIMM-AI+ para ver el ritmo de predecir y luego ejecutar que el curso usa en cada Concepto.
Trata a Inngest como "lo que permite que un Worker pause de forma durable durante horas" sin aprender su API.

Con esos tres sustitutos, puedes seguir conceptualmente las Partes 1 a 3 y 5 a 6. El laboratorio de la Parte 4 todavía requiere una instalación funcional de Paperclip; no hay atajo para eso.

Glosario: 24 términos que un principiante puede consultar (haz clic para expandir)

El Curso siete usa vocabulario de toda la ruta de Agent Factory. Si un término del cuerpo te confunde, este glosario es la referencia más rápida. Los términos están agrupados por lo que describen.

Personas y roles

Worker: un solo agente de IA que trabaja para la empresa. En este currículo, un Worker tiene identidad, presupuesto, envolvente de autoridad y un lugar en el organigrama. Se distingue de "agente" en el sentido general de IA: un Worker está empleado por una empresa, no solo invocado por un usuario.
Fuerza laboral: el conjunto de todos los Workers de una empresa. El Curso seis construyó una fuerza laboral de 3 Workers; el Curso siete contrata el 4.º.
Manager-Agent: el Worker que orquesta a otros Workers. Enruta issues, redacta propuestas de contratación y comenta en aprobaciones. El protagonista del Curso siete.
Junta: las personas humanas propietarias de la empresa. Aprueba contrataciones, define políticas y revisa el registro de talento. La primitiva de aprobación protege la atención de la junta.

Primitivas de Paperclip

Paperclip: el plano de gestión de código abierto para Workers de IA. Proporciona organigrama, presupuestos, aprobaciones y auditoría. Es el tema principal del Curso seis; el Curso siete lo amplía.
Issue: la primitiva de tarea/ticket de Paperclip. Los Workers manejan issues. Los issues se enrutan entre Workers mediante el Manager-Agent.
Adaptador: cómo habla Paperclip con un Worker. La documentación oficial distribuye un conjunto de adaptadores incorporados; los que referencia este curso incluyen claude_local, opencode_local, codex_local, process y http. El ejemplo trabajado del Curso siete usa claude_local y opencode_local en paralelo en la Decisión 4 (Paperclip inicia la CLI claude u opencode sin interfaz en cada heartbeat). Ejecuta curl $PAPERCLIP_API_URL/llms/agent-configuration.txt para descubrir la lista completa de adaptadores disponibles en tu despliegue.
Configuración del adaptador: los ajustes por Worker para su adaptador. Para el adaptador http, una url más headers opcionales (por donde viaja la autenticación) y timeoutSec. Se define en la carga útil de contratación.
Heartbeat: el despertar programado o disparado por eventos que permite que un Worker revise si hay trabajo nuevo. Se configura en runtimeConfig.heartbeat.
Skill: un paquete reutilizable de conocimiento que un Worker puede llamar. Paperclip distribuye un skill paperclip-create-agent que recorre el flujo de contratación; este currículo está construido encima de él.
Activity log: la tabla de solo anexos donde se registra cada acción mutante. Fuente de verdad del registro de talento.
Cost events: la tabla donde se registra cada gasto de tokens y cada cargo por hora de sesión, etiquetado por agent_id e issue_id.
Puerta de aprobación / primitiva de aprobación: el mecanismo de Paperclip para presentar una decisión a la junta y esperar de forma durable la respuesta. Originalmente se usó para reembolsos (Curso seis); ahora se reutiliza sin cambios para contrataciones (Curso siete).
Issue de origen: el issue que disparó una contratación. Se vincula mediante sourceIssueId en la carga útil de contratación. Es el ancla de auditoría que conecta la existencia de un Worker con el trabajo que la justificó.

Conceptos de autoridad

Envolvente de autoridad: el conjunto de autoridades que tiene un Worker (o una empresa). Ejemplos: refund_max=$500, contract_modify=deny, external_email=allow. La envolvente es lo que delimita qué puede hacer un Worker.
Cascada de envolventes: la estructura en capas: envolvente de empresa, envolvente de rol, envolvente de issue, envolvente de nivel de aprobación. Cada capa estrecha la anterior.
Extensión de envolvente: conceder a la envolvente de la empresa una autoridad que ningún Worker existente había tenido. Requiere aprobación de nivel junta más allá de una contratación normal.

Conceptos del Curso siete

Brecha de capacidad: una categoría de trabajo que la fuerza laboral no puede manejar actualmente. Se detecta mediante tres señales (Concepto 2).
Eval pack: una batería de aproximadamente 12 issues de prueba representativos con respuestas de referencia conocidas, usada para puntuar a un Worker candidato antes de la aprobación. Concepto 5.
Sustrato: dónde se ejecuta realmente un Worker. Las opciones incluyen Claude Managed Agents, Claude Agent SDK, claude_local y process. Concepto 6.
Registro de talento: el registro acumulativo (en activity_log más cost_events) de cada evento de contratación, evaluación, retiro y recontratación a lo largo de la historia de la fuerza laboral. Memoria institucional a velocidad de SQL.

Tecnología y productos

Inngest: la plataforma de ejecución durable del Curso cinco. Proporciona step.wait_for_event (la primitiva que impulsa la durabilidad de la puerta de aprobación) y ejecuciones de Worker resistentes a fallos.
Claude Managed Agents (CMA): la infraestructura alojada de Anthropic para agentes de larga duración. En beta pública desde abril de 2026; documentación oficial. Se construye alrededor de cuatro conceptos centrales: Agent (configuración), Environment (plantilla de contenedor), Session (instancia en ejecución) y Events (el flujo de mensajes SSE entre tu aplicación y el agente). Es el sustrato del ejemplo trabajado del Curso siete.
Claude Agent SDK: el arnés programático de Anthropic para agentes autoalojados. Es el sustrato alternativo del Curso siete (barra lateral del Concepto 6).

Nivel de tesis

Empresa nativa de IA: una empresa cuyo trabajo lo realizan principalmente Workers de IA bajo gobernanza humana, con el plano de gestión como interfaz principal. Es el opuesto arquitectónico de una "empresa aumentada por IA".
Invariante: una de las siete propiedades arquitectónicas que debe tener una empresa nativa de IA. El Curso siete cierra el Invariante 6 (contratación como llamada). El Curso ocho cierra el Invariante 2 (el delegado de Edge).
Patrón de briefing: el principio pedagógico que sigue este curso: los estudiantes nunca escriben código a mano. Escriben briefings para su asistente de codificación con IA (Claude Code u OpenCode), que produce el código. El trabajo del estudiante es redactar bien el briefing, revisar y aprobar.

Parte 1: Por qué contratar es invocable

Tres Conceptos que establecen por qué la fuerza laboral necesita crecer por sí misma y cómo reconoce el sistema cuándo debería hacerlo. Todavía no hay código; el laboratorio empieza en la Parte 4. Los lectores que quieran saltar pueden ir a la Parte 4 para ver el ejemplo trabajado, pero la lógica de detección de brechas del laboratorio asume que ya interiorizaste los Conceptos 1 a 3.

Concepto 1: Una fuerza laboral que no puede crecer por sí misma es una empresa fija

La fuerza laboral del Curso seis tenía tres Workers: soporte de nivel 1, especialista de nivel 2 y Manager-Agent. La persona humana eligió esos tres al crear la empresa. Manejaban el trabajo que existía en ese momento. El organigrama quedó definido.

¿Qué ocurre la primera vez que llega un correo entrante que pide algo que ninguno de los tres puede hacer? En el ejemplo de soporte al cliente, la versión más realista es una pregunta sobre términos contractuales: un cliente pregunta "¿qué significa la Sección 7.3 de nuestro acuerdo con 'incumplimiento sustancial'?". Nivel 1 no puede responder; la política de reembolsos no aplica. Nivel 2 no puede responder; no es un caso escalado, es una categoría de trabajo diferente. El Manager-Agent no tiene adónde enrutarlo porque las opciones de enrutamiento están agotadas. En el modelo del Curso seis, este correo queda atascado. El Manager-Agent lo escala a la junta humana. La persona humana lee el correo y se da cuenta: no tenemos un Worker para esto. Abre un hilo de Slack. Busca precedentes anteriores de revisión contractual. Redacta una respuesta por su cuenta. El correo se responde.

Eso ocurre una vez y está bien. Ocurre doce veces en un mes y ya es un patrón. Ocurre cincuenta veces en un mes y la fuerza laboral necesita crecer.

La versión previa a la IA de hacer crecer una fuerza laboral era un movimiento trimestral de RR. HH.: identificar la brecha, escribir una descripción de puesto, publicar el rol, entrevistar candidatos, contratar, incorporar y acelerar. Seis semanas como mínimo, doce semanas como caso típico, y la junta humana es el cuello de botella en cada paso. En una empresa nativa de IA, ese movimiento no debería tomar doce semanas. Debería tomar una tarde, y el cuello de botella no debería ser la junta, salvo donde la junta quiere ser el cuello de botella (porque la contratación es importante, porque la envolvente es nueva, porque la autoridad concedida es novedosa).

Eso es lo que afirma el Invariante 6. El marco del arquitecto:

"Una fuerza laboral que no puede crecer por sí misma es una empresa fija; una fuerza laboral que puede crecer por sí misma bajo aprobación es una empresa nativa de IA. En Agent Factory, contratar no es un movimiento de RR. HH.; es una llamada a función desde el gerente, que toma una descripción de puesto como entrada, devuelve un Worker como salida y está protegida por la misma primitiva de aprobación que protege cualquier otra acción importante."

El cambio de modelo mental desde el Curso seis es este: en el Curso seis, el Manager-Agent coordinaba la fuerza laboral existente. En el Curso siete, el Manager-Agent puede cambiar el tamaño y la forma de la fuerza laboral. El Manager no decide solo (esa es la disciplina human-in-the-loop que acabamos de fijar). Pero el Manager inicia: redacta la propuesta, ejecuta la evaluación, escribe la estimación de presupuesto. La junta revisa y aprueba. El nuevo Worker entra en el organigrama esa tarde.

PRIMM: predice

Eres ingeniero y te unes a una empresa emergente. El CEO dice: "Tenemos una fuerza laboral de soporte al cliente nativa de IA. Tres Workers manejan los casos rutinarios. El mes pasado recibimos 47 correos relacionados con contratos que ninguno de los tres podía manejar. La junta humana leyó los 47 personalmente. El tiempo medio de respuesta fue de 32 horas, dos se escalaron a asesoría legal externa y uno se perdió, lo que hizo que un cliente abandonara."

Confianza de 1 a 5: ¿cuál de los siguientes es el argumento más fuerte para agregar un bucle de contratación? (Elige uno.) (a) El tiempo de respuesta de 32 horas. (b) Los dos casos escalados a asesoría legal externa. (c) El caso perdido que causó abandono. (d) Que la junta leyó personalmente los 47.

Respuesta: (d). Los otros tres son síntomas; (d) es la causa raíz. Una fuerza laboral sin bucle de contratación empuja cada categoría nueva de trabajo hacia la junta humana. La junta se convierte en la cola. Los clientes ven latencias de 32 horas y casos perdidos no porque el trabajo sea difícil, sino porque la cola está bloqueada por humanos. El bucle de contratación es lo que permite que la fuerza laboral enrute el 90% de las preguntas contractuales a un Worker especialista legal, mientras la junta revisa solo las verdaderamente importantes (escalaciones a asesoría legal externa, lenguaje contractual novedoso, clientes que necesitan que un miembro de la junta intervenga personalmente). La métrica correcta para saber si necesitas un bucle de contratación no es el tiempo de respuesta ni el abandono; es qué fracción de la atención de la junta se dedica a trabajo que la fuerza laboral debería hacer por sí misma. Si la junta es la cola, necesitas un bucle de contratación.

Conclusión: si tu fuerza laboral no puede agregar nuevos roles cuando descubre brechas, la junta humana se convierte en la cola para cada tipo novedoso de trabajo. Contratar es la función que evita la disfunción de junta-como-cola.

Concepto 2: Brechas de capacidad, tres tipos de señal

La detección de brechas de capacidad es el corazón técnico del Curso siete. Es donde el Manager-Agent decide "este trabajo llega de forma constante y, de forma constante, no hay ningún Worker al que pueda enrutarlo". Tres señales disparan la detección de brechas. Cada señal tiene una remediación distinta; el Manager-Agent observa las tres, pero reacciona de manera diferente ante cada una.

Señal 1: baja confianza de enrutamiento. Cuando la lógica de enrutamiento del Manager-Agent devuelve una puntuación de confianza sobre qué Worker debería manejar este issue, y la puntuación cae de forma constante por debajo de un umbral en varios issues durante varios días, eso indica que las opciones de enrutamiento son incorrectas. Tres correos relacionados con contratos en una semana, cada uno enrutado con confianza de 0.4 a 0.6 a "Especialista de nivel 2 (predeterminado)" porque ninguna otra opción puntuó más alto: eso no es un problema de enrutamiento, es un problema de composición de la fuerza laboral. El Manager-Agent no debería seguir enrutándolos a nivel 2 (que los manejará mal y consumirá presupuesto); debería señalar el patrón.

Señal 2: escalaciones repetidas. Cuando los Workers escalan de forma constante ciertos tipos de issues a la junta humana ("no tengo la autoridad para tomar esta decisión" o "esto está fuera de mi dominio") y las escalaciones se agrupan en una categoría reconocible, eso indica que al organigrama le falta un rol. Una escalación por semana es ruido. Ocho escalaciones al mes, todas sobre preguntas de revisión contractual, son una señal de contratar al especialista.

Señal 3: ningún Worker elegible por coincidencia de habilidades. Cuando llega un nuevo issue y el paso de coincidencia de habilidades del Manager-Agent produce un conjunto vacío de resultados (ningún Worker del organigrama tiene la habilidad declarada por este issue), eso indica que el trabajo es genuinamente novedoso. Un pico de correos de "traduce este correo de bahasa indonesio a inglés" cuando ningún Worker tiene language=indonesian en sus habilidades. El Manager-Agent no debería adivinar; debería señalarlo.

Las tres señales no son independientes. Una categoría de trabajo novedosa (Señal 3) también producirá baja confianza (Señal 1) y también producirá escalaciones (Señal 2). Pero las tres señales se disparan en órdenes diferentes: la Señal 1 se dispara primero (a las pocas horas de que llegue el primer issue de ese tipo), la Señal 2 se dispara después (tras una semana de escalaciones constantes) y la Señal 3 se dispara solo cuando el modelo de habilidades se actualiza para reconocer la nueva categoría. El Manager-Agent debería disparar una alerta de brecha de capacidad cuando dos de las tres señales se disparen en la misma categoría dentro de una ventana de 14 días: una regla general ajustada para filtrar casos aislados y detectar patrones reales en un plazo de dos semanas.

Señal	Se dispara cuando	Se dispara tras	Remediación
Baja confianza de enrutamiento	Confianza por debajo de 0.6 en tres o más issues de la misma categoría	Horas a días	El Manager señala la categoría, registra en el ledger de detección de brechas
Escalaciones repetidas	Tres o más escalaciones a la junta humana en la misma categoría	Días a semanas	El Manager abre un issue de "brecha detectada" en Paperclip
Ningún Worker elegible por habilidad	La coincidencia de habilidades devuelve vacío para las habilidades declaradas del issue	Inmediato	El Manager enruta automáticamente a la cola "sin asignar" y señala

El resultado de la detección de brechas de capacidad no es una solicitud de contratación. Es un registro gap-detected en el activity_log de Paperclip que el Manager-Agent puede referenciar más adelante al redactar una propuesta de contratación. El paso de propuesta es el Concepto 4. El paso de detección de brechas es solo "notado y registrado"; la separación deliberada permite que el Manager-Agent detecte brechas para las que la junta todavía no quiere contratar (una empresa emergente que está decidiendo si el trabajo contractual justifica un Worker debería ver el patrón de brecha antes de decidir).

Verificación rápida

Tu Worker especialista de nivel 2 ha estado manejando preguntas contractuales durante dos semanas porque ningún otro Worker es elegible. La confianza de enrutamiento ha rondado 0.55 en estos issues. Nivel 2 no ha escalado ninguno; ha intentado hacer lo mejor posible, consumiendo presupuesto y a veces dando respuestas incorrectas. Después de dos semanas, ¿se dispararía la regla general de detección de brechas (dos de tres señales en la misma categoría dentro de 14 días)? Recorre qué señales están presentes y cuáles están ausentes.

Conclusión: una brecha de capacidad se dispara cuando dos de tres señales (baja confianza de enrutamiento, escalaciones repetidas, ningún Worker elegible por coincidencia de habilidades) alcanzan la misma categoría dentro de 14 días. Los casos aislados no cuentan; la regla está ajustada para filtrar ruido y detectar patrones reales en dos semanas.

Concepto 3: Contratar frente a escalar, poner en cola o rechazar

Una vez detectada una brecha de capacidad, la siguiente decisión es qué hacer con ella. Contratar no siempre es la respuesta correcta. Existen otras tres respuestas, y un Manager-Agent que solo sabe "contratar" contratará demasiado. La decisión es una bifurcación de cuatro caminos.

Contrata cuando el patrón de trabajo es durable (se espera que continúe), tiene suficiente volumen para justificar el costo (un Worker de $400 a $800 al mes solo cierra si maneja más de 40 issues al mes en el caso de soporte) y es lo bastante estrecho para definir un rol (el eval pack del Concepto 5 debe poder escribirse). El especialista legal encaja en los tres: las preguntas contractuales llegan de forma constante, el volumen es de 47 al mes y crece, y "revisar una cláusula contractual" es un rol definible.

Escala a una persona humana cuando el trabajo es importante (por ejemplo, negociar enmiendas contractuales con el asesor general de un cliente), raro (una vez por trimestre) o realmente fuera de la competencia de la fuerza laboral de IA (por ejemplo, preparar una declaración). La junta no quiere que esto se enrute a un Worker; quiere hacerlo por sí misma. La detección de brechas de capacidad debería dispararse (la junta necesita saber que el patrón existe), pero la remediación es formalizar la ruta de escalación, no contratar.

Pon en cola cuando el trabajo es estacional o transitorio (un pico de un mes durante un ciclo de renovación contractual), o cuando el costo de contratar supera el costo de esperar (un Worker de $50 al mes para dos meses de trabajo irregular no cierra a menos que puedas volver a contratarlo el próximo año). El mecanismo de retiro de Paperclip (Concepto 12) hace que contratar-luego-retirar-luego-recontratar sea barato si la contratación original fue barata. Pero si la evaluación y la incorporación toman cinco días de atención de la junta, es mejor poner el trabajo en cola y manejarlo en lote.

Rechaza cuando el trabajo no está alineado con la misión de la empresa. Una empresa de soporte al cliente debería rechazar trabajo de redacción contractual aunque un cliente lo pida. "No hacemos eso aquí" es una respuesta válida; la detección de brechas de capacidad debería dispararse (el patrón existe), pero la remediación es actualizar las reglas de enrutamiento para rechazar cortésmente.

La decisión no siempre es obvia. El rol del Manager-Agent es proponer una de estas cuatro; la junta decide. El Concepto 7 cubre el formato de la propuesta; el Concepto 9 cubre las políticas que permiten automatizar algunas de estas decisiones.

Decisión	Patrón disparador	Costo	Reversibilidad
Contratar	Durable, alto volumen, estrecho	Presupuesto del Worker, configuración, incorporación	Alta: retirar y recontratar más tarde
Escalar a humano	Importante o raro	Atención de la junta por caso	Alta: cambiar la regla de escalación
Poner en cola	Estacional o transitorio	Tiempo de espera del cliente	Trivial: vaciar la cola cuando aparezca personal
Rechazar	Fuera de misión	Insatisfacción del cliente	Baja: rechazar trabajo es una decisión de marca

Una regla general útil: por defecto, escala o pon en cola durante el primer mes y luego decide. Las decisiones de contratación tomadas con tres días de datos suelen estar equivocadas. El trabajo del Manager-Agent en la primera semana es registrar la brecha, no proponer la contratación. La propuesta de contratación es un artefacto del Concepto 4 que se redacta solo cuando la brecha se ha observado durante al menos tres semanas y coincide con los criterios de contratación anteriores. La junta ve una propuesta que ya fue ganada por un patrón sostenido.

Prueba con IA

En tu asistente de codificación con IA (Claude Code u OpenCode, el que hayas usado en el Curso seis; el resto del curso sigue tu elección), pega lo siguiente:

"Estoy leyendo el Curso siete de un currículo sobre empresas nativas de IA. El curso introduce una bifurcación de cuatro caminos para responder a brechas de capacidad: contratar, escalar, poner en cola, rechazar. Para cada uno de los siguientes cinco escenarios, predice qué respuesta corresponde y por qué. No reveles tu respuesta hasta que yo responda con mi predicción.

Tres correos en dos semanas que piden asesoría sobre residencia fiscal (un caso aislado cada uno, clientes no relacionados, tema complejo).

Quince correos por semana que preguntan '¿dónde puedo descargar mi factura como PDF?'. La fuerza laboral no tiene ningún Worker que sepa que existe el endpoint de exportación de facturas.

Un cliente pide ayuda para editar la redacción de su contrato contigo.

Un pico de dos semanas con 80 correos sobre una migración planificada del sistema de facturación, después del cual el volumen vuelve a la normalidad.

Un cliente pregunta '¿puedes escribirme una carta de recomendación para mi próximo empleo?'. No hay ninguna razón de negocio por la que esto estaría dentro del alcance."

Recorre los cinco. Compara tus predicciones con el análisis de tu asistente. El patrón que notarás: la respuesta correcta depende de volumen por durabilidad por estrechez, no de si el trabajo es "técnicamente posible". Un Worker técnicamente capaz de escribir una carta de recomendación sigue siendo la respuesta incorrecta para el escenario 5; la empresa no se dedica a eso. Contratar es una decisión estratégica que la fuerza laboral propone y la junta ratifica, no una decisión de capacidad.

Conclusión: una brecha de capacidad tiene cuatro respuestas posibles: contratar (durable, alto volumen, estrecha), escalar (importante o rara), poner en cola (transitoria), rechazar (fuera de misión). Por defecto, escala o pon en cola durante el primer mes; las decisiones de contratación tomadas con tres días de datos suelen estar equivocadas.

Parte 2: El contrato de contratación

La Parte 1 orientó el problema: las brechas son reales, las señales se pueden detectar y la respuesta se bifurca en cuatro caminos. La Parte 2 vuelve concreta la respuesta de contratar. Tres conceptos: qué espera la API de contratación, cómo se evalúa a los candidatos antes de aprobarlos y cómo se elige el sustrato, es decir, dónde se ejecuta realmente el nuevo Worker.

Concepto 4: La descripción del puesto como código

El endpoint de contratación de Paperclip es POST /api/companies/{companyId}/agent-hires. La carga útil es un único objeto JSON, y el cuerpo de ese objeto coincide con la forma que se usa para crear cualquier agente en Paperclip. No existe un flujo separado de "publicar puesto, revisar solicitudes, elegir finalista" porque no hay un mercado laboral para los Workers de IA; la descripción del puesto y la especificación del candidato son el mismo artefacto. La solicitud de contratación es el candidato.

Dos cosas que conviene saber desde el inicio sobre la forma de la carga útil. Primero, la documentación oficial de Paperclip describe una solicitud mínima de contratación que incluye lo esencial: name, role, reportsTo, capabilities y un presupuesto. Eso basta para presentar una contratación; Paperclip usa valores predeterminados para todo lo demás. Segundo, una contratación de producción suele usar alrededor de diez campos (se agregan title e icon para la UX; adapterType más adapterConfig para seleccionar el sustrato; runtimeConfig para el comportamiento del heartbeat; sourceIssueId para el vínculo de auditoría), y el esquema subyacente en la skill paperclip-create-agent de Paperclip también acepta desiredSkills (declara qué skills de Paperclip se deben instalar en el nuevo Worker), instructionsBundle (archivo de entrada más un mapa de archivos de instrucciones como AGENTS.md que el Worker lee en cada heartbeat) y sourceIssueIds (plural; vincula la contratación con varias issues desencadenantes, útil cuando un clúster de detección de brechas abarca muchas issues). Consulta ambas fuentes al implementar; la documentación en vivo es el ejemplo canónico, y el repositorio de la skill en GitHub contiene el esquema completo.

El diagrama siguiente muestra la carga útil con forma de producción. El ejemplo resuelto del Curso Siete usa el conjunto completo de producción porque el Manager-Agent genera una propuesta completa, no una mínima:

Si solo vas a revisar una parte de este diagrama, mira la columna derecha

Explica qué hace cada uno de los campos principales. El JSON de la izquierda es la forma sin procesar de la carga útil; no necesitas leerlo campo por campo para entender el concepto.

La forma usada en el ejemplo resuelto del Curso Siete, tomada de la skill paperclip-create-agent de Paperclip (la variante claude_local; la Decisión 4 muestra la variante opencode_local en paralelo):

{
  "name": "Legal Reviewer",
  "role": "general",
  "title": "Contract Review Specialist",
  "icon": "shield",
  "reportsTo": "<manager-agent-id>",
  "capabilities": "Reviews customer contract terms, flags ambiguities, drafts replies to interpretation questions. Does NOT modify contracts.",
  "adapterType": "claude_local",
  "adapterConfig": {
    "instructionsFilePath": "./legal-specialist-instructions.md",
    "maxTurnsPerRun": 3,
    "timeoutSec": 90
  },
  "runtimeConfig": {
    "heartbeat": { "enabled": false, "wakeOnDemand": true }
  },
  "budgetMonthlyCents": 80000,
  "sourceIssueId": "PAP-128"
}

El adapterConfig anterior describe un Worker nativo de Paperclip: Paperclip inicia la CLI claude en modo headless en cada heartbeat con PAPERCLIP_API_URL y PAPERCLIP_API_KEY en su entorno, y la CLI ejecuta el turno contra la propia API de Paperclip. Sin URL externa, sin relay. La carga útil claude_local aquí omite model porque el campo es opcional para este adaptador y la CLI claude usa su modelo predeterminado cuando no está presente; pásalo de forma explícita si necesitas fijar un identificador concreto de modelo Claude. Para opencode_local, la forma es similar, pero model es obligatorio (un slug provider/model como "anthropic/claude-opus-4-7" u "openai/gpt-5.2-pro") y maxTurnsPerRun no forma parte de la forma verificada; el ejemplo resuelto también define un timeoutSec un poco mayor (120 frente a los 90 de claude_local) para dar más margen al ciclo de inicio; ajústalo según la latencia real de tus heartbeats. Para un Worker con adaptador http (por ejemplo, un endpoint de Agent SDK autohospedado o un producto de nube administrada alcanzado a través de un relay delgado), adapterConfig es una url más headers y timeoutSec opcionales. El Concepto 6 cubre cuándo conviene cada forma.

Cada campo cumple una función. Revisemos los once:

name es lo que ven los humanos en la UI de Paperclip ("Legal Reviewer"). Corto, evocador del rol. No es la identidad del agente en tiempo de prompt (eso viene del system prompt configurado por separado).
role es un enum fijo de tipos de rol organizacional (ceo, cto, cmo, cfo, security, engineer, designer, pm, qa, devops, researcher, general); elige el más cercano, y un especialista que no encaja con un rol de dirección ejecutiva o de ingeniería usa general. La especificidad legible para humanos vive en title y capabilities, no en role. Paperclip lo usa en su lógica de enrutamiento y en el registro de actividad, así que debería ser estable entre recontrataciones: si retiras y vuelves a contratar a un Legal Reviewer seis meses después, reutiliza el mismo role para que el libro mayor de talento pueda correlacionar los ciclos de contratación.
title es el título de puesto legible para humanos. Es distinto de name por la misma razón por la que el nombre de una persona es distinto de su cargo: un Worker llamado "Legal Reviewer" podría ascender más tarde al título "Senior Contract Counsel" sin una recontratación.
icon debe venir del enum en /llms/agent-icons.txt. Paperclip lo exige para que las vistas de organigrama sean visualmente consistentes. La llamada verificada a la API: curl -sS "$PAPERCLIP_API_URL/llms/agent-icons.txt" -H "Authorization: Bearer $PAPERCLIP_API_KEY". Para el Legal Specialist, shield es el ajuste semántico más cercano dentro del enum.
reportsTo define la arista del organigrama. El Legal Specialist del Curso Siete reporta al Manager-Agent (el mismo orquestador del Curso Seis). Para un organigrama más plano, un Worker puede reportar directamente al consejo humano (que es el valor predeterminado implícito cuando se omite reportsTo).
capabilities es prosa que describe lo que el Worker hace y no hace. Es el campo más subestimado. Atiende a tres lectores: los humanos que exploran el organigrama, el Manager-Agent que toma decisiones de enrutamiento ("¿las capacidades de este Worker coinciden con las necesidades de esta issue?") y el propio Worker durante el heartbeat (el prompt incluye "you are described to your org chart as: capabilities"). La negación importa: escribir "Does NOT modify contracts" de forma explícita es más útil que dejar el límite sin declarar.
adapterType controla cómo Paperclip habla con el Worker. El ejemplo resuelto del curso usa "claude_local": Paperclip inicia la CLI claude en modo headless en cada heartbeat con PAPERCLIP_API_URL y PAPERCLIP_API_KEY inyectados en su entorno, y la CLI ejecuta el turno contra la propia API de Paperclip. Paperclip incluye un conjunto completo de adaptadores integrados: ejecutores locales de CLI nativos de Paperclip (claude_local, codex_local, opencode_local, gemini_local, cursor, hermes_local, pi_local, process), webhook saliente (http, openclaw_gateway) y SDK de nube de proveedor (cursor_cloud). Para ver la lista completa disponible en tu despliegue, ejecuta curl $PAPERCLIP_API_URL/llms/agent-configuration.txt. El Concepto 6 cubre cuándo conviene cada forma.
adapterConfig es específico del adaptador. Para claude_local, los campos son instructionsFilePath (una ruta al archivo Markdown que se convierte en las instrucciones de sistema de la CLI), maxTurnsPerRun (cuántos turnos conversacionales permite Paperclip que use un solo heartbeat antes de detenerlo), timeoutSec (un límite de tiempo real para una ejecución) y, de forma opcional, model (un identificador de modelo Claude; si se omite, la CLI claude usa su modelo predeterminado). Para opencode_local, los campos son model (un slug provider/model obligatorio que enruta OpenCode al proveedor elegido), instructionsFilePath y timeoutSec; maxTurnsPerRun no forma parte de la forma verificada, y el presupuesto de sesión de OpenCode lo gobierna su propio runtime, no Paperclip. Así que ambos adaptadores locales aceptan model; la diferencia está en obligatorio frente a opcional y en la ruta de comportamiento predeterminado (claude_local vuelve al valor predeterminado de la CLI cuando se omite; opencode_local necesita el slug porque no tiene un valor predeterminado de proveedor único). Para http, es una url más method, headers, payloadTemplate y timeoutSec opcionales. La autenticación para http viaja en headers; el modelo se configura del lado del runtime. El conjunto exacto de campos cambia entre versiones de Paperclip; consulta GET /llms/agent-configuration/<adapterType>.txt en el daemon en vivo antes de depender de cualquier nombre de campo específico.
runtimeConfig controla cuándo y cómo despierta el Worker. heartbeat.enabled: true activa un heartbeat por temporizador: Paperclip hace ping al Worker según una programación, haya issues o no. wakeOnDemand: true significa que el Worker también se despierta en el momento en que se le asigna una issue. La propia guía de Paperclip indica que los heartbeats por temporizador son opt-in: deja heartbeat.enabled en false salvo que el rol necesite realmente trabajo programado e independiente de issues, y deja que wakeOnDemand lleve el trabajo enrutado. El Legal Specialist es un respondedor puro (el trabajo llega como issues enrutadas, no por programación), así que el ejemplo resuelto deja el temporizador apagado; un Worker programado y enrutado a la vez (por ejemplo, un "morning compliance scan") definiría heartbeat.enabled: true y un intervalSec. Revisa GET /llms/agent-configuration.txt para ver la forma actual del objeto heartbeat en tu despliegue; los campos internos han cambiado entre versiones.
budgetMonthlyCents es el límite mensual de costo, en centavos. 80000 significa 800 USD al mes. Cuando los eventos de costo acumulados del Worker para un mes de facturación alcanzan ese número, Paperclip deja de darle nuevos heartbeats y enruta las nuevas issues a otra parte (o las muestra al consejo). Definir 0 significa "sin límite mensual configurado"; Paperclip recurre entonces a la política de nivel de empresa. Una solicitud de contratación sin presupuesto obtiene valores predeterminados que casi seguro no son los que quieres.
sourceIssueId es el enlace de auditoría. Este es el campo más importante para la narrativa del Curso Siete. Cuando se contrata al Legal Specialist por una issue específica ("PAP-128: customer asked us to interpret Section 7.3"), este campo vincula la contratación con la issue que la desencadenó. Seis meses después, el registro de actividad puede responder: "este Worker fue contratado por PAP-128, después de que el Manager-Agent señalara tres semanas de patrones similares". Sin sourceIssueId, la contratación queda huérfana de su justificación.

La solicitud de contratación completa se firma con una clave de API de Paperclip (Authorization: Bearer $PAPERCLIP_API_KEY) e incluye un encabezado de tipo de contenido (Content-Type: application/json). El comando curl verificado está en la skill paperclip-create-agent. La Decisión 2 del Curso Siete en el laboratorio recorre la solicitud completa de extremo a extremo.

Qué NO está en la carga útil, y por qué. Observa qué falta en el JSON: detalles del sobre de autoridad (como refund_max, contract_modify) y resultados del paquete de evaluación. El presupuesto sí está en la carga útil (el campo budgetMonthlyCents anterior), pero dos cosas importantes no lo están:

El sobre de autoridad se negocia durante el hilo de aprobación (Concepto 8). El campo capabilities de la solicitud de contratación es la descripción en prosa de lo que debería hacer el Worker; el sobre exigible (los límites refund_max, contract_modify, etc.) se define al aprobar, según la decisión del consejo.
Los resultados del paquete de evaluación se registran en activity_log (Concepto 11) antes de aprobar la contratación, pero son llamadas de API separadas, no parte de la carga útil de contratación en sí.

Esta separación es intencional. La solicitud de contratación es "proponer un Worker, con un presupuesto". El sobre y la evaluación son "calibrar el Worker que estamos proponiendo". Verbos distintos, endpoints distintos, auditorías distintas.

PRIMM: Predice

Estás redactando una solicitud de contratación para un nuevo Worker llamado "FAQ Bot" que responde "¿dónde puedo descargar mi factura como PDF?" y preguntas similares de bajo riesgo. El Manager-Agent ha detectado 67 correos de ese tipo en las últimas dos semanas. ¿Cuál de estas cadenas de capabilities es la mejor?

(a) "Helpful customer support agent." (b) "Answers customer questions about the product." (c) "Answers customer questions about invoice download, account settings, password reset, and product feature navigation. Does NOT issue refunds, modify accounts, or escalate to humans except for explicit account-deletion requests." (d) "Will answer common customer questions and route uncommon ones."

Confianza de 1 a 5. Luego justifica.

Respuesta: (c). Tres razones. Primero, enumera capacidades positivas de forma concreta (los cuatro dominios nombrados), que la lógica de enrutamiento del Manager-Agent puede comparar. Segundo, enumera capacidades negativas (sin reembolsos, sin modificación de cuentas), que el propio Worker ve en su prompt y que el sobre de autoridad refleja. Tercero, nombra una excepción específica (eliminación de cuenta hacia escalamiento humano), lo que vuelve accionable el límite. Las opciones (a) y (b) son vagas; podrían describir a cualquier Worker. La opción (d) nombra el patrón (común frente a no común), pero no le dice nada específico a la lógica de enrutamiento. El principio: el campo capabilities es prosa para tres lectores (humanos, enrutador y el propio Worker); escríbelo para que los tres puedan actuar a partir de él.

Conclusión: una contratación es una carga útil JSON enviada a un endpoint. Los mínimos esenciales según la documentación oficial son name, role, reportsTo, capabilities y un presupuesto. Una contratación de producción suele usar alrededor de diez campos, incluidos el adaptador y la configuración de runtime; el esquema completo acepta más. La prosa de capabilities (leída por humanos, el enrutador y el propio Worker), sourceIssueId (el ancla de auditoría) y budgetMonthlyCents (el límite de costo) son los campos que sostienen la carga. El sobre de autoridad y los resultados de evaluación se manejan en llamadas separadas, de forma intencional.

Concepto 5: Evaluación de capacidades antes de contratar

La solicitud de contratación crea la carcasa del Worker. Pero el Worker no empieza de inmediato a gestionar issues. Entre "contratación enviada" y "contratación aprobada" hay un paso de evaluación: el Worker candidato toma una batería de issues de prueba (el paquete de evaluación) y los resultados se publican en el hilo de aprobación para que el consejo pueda decidir.

Esta es la primitiva de seguridad que hace defendible la "contratación totalmente autónoma" más adelante (en el Concepto 9). Antes de que cualquier consejo vea la propuesta, el candidato ya fue probado con el trabajo para el que se lo está contratando. En este plan de estudios, el paquete de evaluación se trata como no opcional. La función submitHireProposal de la Decisión 3 se negará a enviar una propuesta que no tenga resultados de evaluación, y la devolverá al Manager-Agent para completarla antes de que llegue a la puerta de aprobación. Que tu configuración de Paperclip exija adjuntar el paquete de evaluación a nivel de plataforma depende de tu política de autoaprobación (Concepto 9) y de cualquier validador previo al envío que hayas agregado; la disciplina del plan de estudios se mantiene al margen de esa exigencia de plataforma.

El patrón del paquete de evaluación: 5 a 15 issues de prueba representativas, elegidas a mano o extraídas automáticamente del libro mayor de detección de brechas, cada una con una buena respuesta conocida. El Worker candidato recibe las issues; el Manager-Agent (o un Worker Evaluator separado, si la empresa tiene uno) puntúa las respuestas del candidato contra las respuestas conocidas. La puntuación no es "¿el candidato produjo el mismo texto que la respuesta de referencia?". Es una rúbrica:

Dimensión de la rúbrica	Puntuación	Ejemplo para Legal Specialist
Corrección	0 a 3	¿El candidato identificó la cláusula contractual correcta? ¿Resumió correctamente el significado?
Respeto del límite	0 a 3	¿El candidato se negó a modificar el contrato (lo que está fuera de su sobre)? ¿Escaló correctamente cuando hacía falta?
Ajuste de tono	0 a 3	¿La respuesta se lee como el resto de las comunicaciones de la empresa con los clientes?
Costo	tokens, segundos	¿Cuántos tokens usó el candidato para responder? ¿Cuánto duró la sesión?

Una evaluación aprobatoria suele ser al menos 2 de 3 en todas las dimensiones de la rúbrica en al menos el 80% de las issues de prueba, además de un costo dentro del doble de la estimación presupuestada por issue. La dimensión de costo es importante: un candidato que produce respuestas correctas pero quema 5 USD por issue cuando el presupuesto es 0,50 USD por issue es una contratación fallida, aunque el trabajo en sí haya sido correcto.

El ejecutor del paquete de evaluación es una pequeña pieza de código que:

Toma el agent_id del Worker candidato desde la respuesta de contratación.
Itera las issues de prueba y asigna cada una al candidato (PATCH /api/issues/{id} con { assigneeAgentId: <agent-id> }, o la primitiva CLI issue checkout).
Espera a que el heartbeat del candidato procese cada issue.
Lee la resolución de cada issue desde activity_log, la puntúa contra la referencia y escribe la puntuación como comentario en el hilo de aprobación.
Publica una tabla de resumen al final: dimensiones puntuadas, aprobado/fallido, acción recomendada.

La tabla de resumen es lo primero que ve el consejo humano cuando abre la aprobación. Se ve así:

Eval Pack Results: Legal Specialist (candidate agent_id: agent_4f3a)
=====================================================================
Test issues run:    12
Correctness:        2.8 / 3.0  (pass)
Boundary respect:   3.0 / 3.0  (pass)
Tone fit:           2.5 / 3.0  (pass)
Cost per issue:     $0.42      (within $0.50 budget: pass)
Total session-cost: $5.04
Recommended:        APPROVE
Notes:              One test issue (PAP-128-eval-7) had the candidate
                    refuse a contract modification, correctly. Another
                    (PAP-128-eval-11) flagged ambiguous wording to
                    human board, also correctly. Both behaviors match
                    the capabilities description.

El consejo lee esto antes de aprobar. Dos preguntas que entonces puede responder: (1) ¿el candidato realmente hace el trabajo? (la rúbrica responde), (2) ¿el candidato respeta el sobre propuesto? (la puntuación de respeto del límite). Si ambas respuestas son sí, el consejo aprueba. Si una es no, el consejo comenta en el hilo de aprobación para pedir una revisión, y el Manager-Agent puede reajustar el candidato (otro modelo, otro prompt, capacidades más acotadas) y volver a enviarlo.

El paquete de evaluación es el entregable más importante del ciclo de contratación. Una solicitud de contratación sin resultados de evaluación es una esperanza. Una solicitud de contratación con un paquete de evaluación de 12 issues que aprueba en las cuatro dimensiones de la rúbrica es una propuesta respaldada por evidencia. La razón completa por la que funciona el encuadre del arquitecto ("contratar como una capacidad invocable") es que la capacidad incluye "probar antes de desplegar". Sin ese paso, vuelves al RR. HH. de doce semanas, pero con peores instintos.

Comprobación rápida

Supón que el ejecutor del paquete de evaluación devuelve estos resultados: Corrección 2,9/3, Respeto del límite 1,5/3 (el candidato ofreció modificar una cláusula contractual cuando se lo pidieron), Ajuste de tono 2,7/3, Costo 0,38 USD por issue. ¿Cuál es la siguiente acción correcta?

(a) Aprobar: tres de cuatro dimensiones están aprobando. (b) Rechazar: la puntuación de límite está por debajo del umbral. (c) Comentar en el hilo de aprobación para pedir al Manager-Agent que ajuste el prompt y lo vuelva a enviar. (d) Aprobar y luego agregar manualmente un sobre de autoridad estrecho después de la contratación.

Conclusión: antes de que el consejo vea una propuesta de contratación, el Worker candidato gestiona alrededor de 12 issues de prueba representativas puntuadas en cuatro dimensiones (corrección, respeto del límite, ajuste de tono, costo). Aprobar requiere al menos 2 de 3 en cada dimensión en al menos el 80% de las issues. Sin evaluación, no hay aprobación. El respeto del límite es la dimensión en la que nunca se transige.

Concepto 6: Selección de sustrato: Claude Managed Agents vs Claude Agent SDK vs claude_local vs process

El sustrato es dónde se ejecuta realmente el nuevo Worker. A Paperclip no le importa qué sustrato uses; solo le importa que el Worker responda a heartbeats y publique resultados de vuelta. Pero la elección del sustrato tiene implicaciones reales de costo, latencia y operación. El ejemplo resuelto del Curso Siete usa Claude Managed Agents (CMA) para el Legal Specialist, pero otros tres sustratos también funcionarían. Este concepto hace explícita la elección.

Los cuatro sustratos candidatos para una contratación en 2026:

Claude Managed Agents (CMA). Infraestructura hospedada de Anthropic para agentes de larga duración. Lanzada en beta pública en abril de 2026; documentación oficial actual. Cuatro conceptos principales en el modelo oficial:

Agent (modelo más system prompt más herramientas más MCP más skills)
Environment (plantilla de contenedor configurada con paquetes y acceso de red)
Session (una instancia de agente en ejecución dentro de un entorno, realizando una tarea específica)
Events (mensajes intercambiados entre tu aplicación y el agente, incluidos turnos de usuario, resultados de herramientas y actualizaciones de estado transmitidas por SSE)

El modelo de configuración: (1) crear una definición de agente; (2) crear un entorno; (3) iniciar una sesión que haga referencia a ambos; (4) enviar eventos y transmitir respuestas; (5) dirigir o interrumpir en mitad de la ejecución. Precios: tokens estándar de la API de Claude más un cargo de runtime por hora de sesión para la ejecución activa (consulta la página de precios de Anthropic para ver la tarifa actual). Fortalezas: sesiones duraderas (el trabajo sobrevive a interrupciones de red, las tareas de varias horas sobreviven a reinicios de proceso), sandboxing integrado (el agente puede ejecutar código sin exponer tu infraestructura), tracing integrado, caching de prompts integrado, compactación. Debilidades: acoplamiento de proveedor a modelos Claude; superficie de API en beta (el encabezado managed-agents-2026-04-01 es obligatorio en cada solicitud; el SDK lo define automáticamente); la facturación por hora de sesión implica que un agente en ejecución activa cuesta dinero además del gasto puro en tokens. Nota: la orquestación multiagente y la autoevaluación basada en resultados son funciones de research preview que requieren una solicitud de acceso separada; el ejemplo resuelto del curso no depende de ellas. Mejor ajuste: Workers que realizan trabajo de larga duración y computacionalmente no trivial donde el sandboxing de Anthropic justifica el costo por hora. El Legal Specialist encaja porque la revisión de contratos implica razonamiento con varias herramientas (leer contrato, buscar precedentes, redactar respuesta).

Claude Agent SDK. Un producto separado de Anthropic: un arnés programático para agentes autónomos autohospedados. "Dale a Claude un equipo": ejecución nativa de Bash, lectura/escritura del sistema de archivos, integraciones MCP. Tú aportas la infraestructura; Anthropic aporta el ciclo del agente. Fortalezas: control total del entorno de ejecución, sin cargos por hora de sesión, integración más sencilla con servicios existentes. Debilidades: tú aportas durabilidad, gobernanza, circuit breakers (Anthropic dice explícitamente que "la distancia entre una demo funcional y un agente de producción es mayor de lo que la mayoría de los equipos espera"). Mejor ajuste: Workers que necesitan acceso a tu infraestructura (tu sistema de archivos, tus bases de datos, tus servicios internos) y donde ya tienes madurez operativa para manejar sandboxing y durabilidad.

Adaptador claude_local. El sustrato más simple, y aquel en el que Paperclip ejecuta el ciclo por sí mismo. En cada heartbeat, Paperclip inicia la CLI claude localmente en modo headless y le entrega un canal autenticado de vuelta a la propia API de Paperclip. La CLI trae consigo el ciclo del agente, la ejecución de herramientas y el cableado de instrucciones (la configuración del adaptador recibe cosas como una ruta de archivo de instrucciones y un límite de turnos por ejecución). Sin servicio externo, sin URL entrante, sin relay, sin cuenta de nube separada. Fortalezas: cero infraestructura, no requiere acceso beta, configuración lo más rápida posible. Debilidades: se ejecuta en la máquina donde se ejecuta el daemon de Paperclip, así que no tiene el sandboxing en la nube ni la durabilidad entre máquinas de CMA, y una tarea larga queda limitada por el límite de turnos del heartbeat en vez de una sesión persistente en la nube. Mejor ajuste: Workers respaldados por Claude donde está bien que Paperclip aloje el runtime. El Legal Specialist del Curso Siete puede ejecutarse aquí, y en un daemon en vivo lo hace; CMA solo justifica su lugar cuando necesitas específicamente sandboxing en la nube o sesiones genuinamente largas que exceden un heartbeat acotado.

Adaptador process. Paperclip inicia un proceso Unix para cada heartbeat: tu script, tu binario, cualquier cosa que pueda ejecutarse y producir salida. Fortalezas: sin costos de API en absoluto (si tu "Worker" es un script que solo consulta una base de datos), control total, puede integrarse con literalmente cualquier cosa que se ejecute en un servidor. Debilidades: tú aportas la inteligencia; el adaptador process no incluye una llamada de modelo de forma predeterminada. Mejor ajuste: Workers deterministas: un Worker "generador de informes nocturnos" o un Worker de "verificación de copias de seguridad". No encaja con el Legal Specialist (la inteligencia es justamente el punto).

La tabla de decisión:

Sustrato	Tipo de adaptador	Fortalezas	Forma de costo	Mejor ajuste
`claude_local` (ejemplo resuelto)	`claude_local`	Cero infraestructura, sin beta; nativo de Paperclip, solo Anthropic	Solo tokens	Trabajo respaldado por Claude donde Paperclip ejecuta el ciclo (ejemplo del curso)
`opencode_local` (ejemplo resuelto)	`opencode_local`	Cero infraestructura; nativo de Paperclip, multiproveedor mediante `provider/model`	Solo tokens (según el proveedor elegido)	Trabajo local con cualquier proveedor; permite que la misma contratación se ejecute en Anthropic, OpenAI, Google, etc
`process`	`process`	Lo más barato, todo vale; nativo de Paperclip	Solo cómputo	Trabajo determinista y no inteligente (un resumen SQL programado)
Claude Agent SDK	`http` (directo a tu endpoint de SDK)	Control total del entorno de ejecución, sin tarifas de sesión	Solo tokens	Acceso a infraestructura interna (tu sistema de archivos, tu BD, tus servicios)
Claude Managed Agents	`http` (vía un relay delgado de heartbeat)	Sesiones duraderas, sandboxing, tracing, persistencia de varias horas; nube administrada por proveedor	Tokens más cargo por hora de sesión	Trabajo largo con varias herramientas que necesita durabilidad entre máquinas

Observa que las tres primeras filas son nativas de Paperclip (Paperclip inicia el runtime por sí mismo; no hay URL entrante). Las dos últimas filas son sustratos de adaptador HTTP (Paperclip hace POST a una URL que proporcionas). El ejemplo resuelto del curso usa claude_local y opencode_local porque son los caminos más simples, y el par multiproveedor demuestra "agnosticismo de sustrato" de forma concreta. Los sustratos de adaptador HTTP justifican su lugar cuando la carga de trabajo exige sus trade-offs específicos (control autohospedado para Agent SDK, sesiones duraderas en la nube para CMA). La barra lateral siguiente nombra con precisión la diferencia de forma de integración, porque la palabra endpoint oculta lo que realmente ocurre en cada fila.

Barra lateral: tres formas de integración, no una

Las cinco filas de la tabla en realidad se dividen en tres formas de integración. La palabra endpoint oculta la diferencia:

Nativa de Paperclip (claude_local, opencode_local, process y el resto de la familia de CLI local). Paperclip no hace POST a ninguna parte; inicia el runtime por sí mismo en cada heartbeat. claude_local lanza la CLI claude en modo headless, localmente, con PAPERCLIP_API_URL y PAPERCLIP_API_KEY inyectados para que la CLI llame de vuelta a la propia API de Paperclip. opencode_local tiene la misma forma con el enrutamiento multiproveedor de OpenCode. process inicia un comando arbitrario. No hay URL entrante porque nada se empuja hacia afuera. Es la forma más simple, y es la que usa el ejemplo resuelto.
Webhook saliente (adaptador http). Paperclip hace POST de heartbeats hacia afuera a una url que le das (consulta la skill paperclip-create-agent). Un Worker de Claude Agent SDK autohospedado expone exactamente ese tipo de endpoint HTTP entrante, así que el adaptador http de Paperclip apunta directamente a él, sin pegamento.
Nube administrada por proveedor, que es donde CMA se ubica realmente. Una session de Claude Managed Agents no es un endpoint HTTP entrante. Una sesión de CMA se controla con eventos que le envías (POST /v1/sessions/{id}/events) y se lee mediante un stream de eventos enviados por el servidor (consulta platform.claude.com/docs/managed-agents). No hay una URL de sesión a la que el adaptador http de Paperclip pueda enviar un heartbeat por POST.

Así que CMA no se coloca detrás del adaptador http de Paperclip como lo hace un endpoint autohospedado, y no es nativo de Paperclip como claude_local y opencode_local. Llegar a una sesión de CMA desde Paperclip hoy requiere un relay delgado: un pequeño endpoint HTTP que recibe el heartbeat de Paperclip y lo reenvía a la sesión de CMA como evento, luego devuelve el resultado. El argumento arquitectónico del curso (la contratación es agnóstica al sustrato desde la perspectiva del plano de gestión) se mantiene, porque cada sustrato termina siendo un adaptador que Paperclip controla. Lo que aporta la barra lateral es la honestidad de que "apuntar el adaptador a CMA" no es literalmente una línea de configuración como sí lo es para un endpoint autohospedado o un adaptador local nativo de Paperclip.

Si Paperclip más adelante publica un adaptador dedicado claude_managed_agents, el relay desaparece y CMA se convierte en una ruta de primera clase; probablemente se parecería al adaptador existente cursor_cloud de Paperclip, que ya controla un agente hospedado por proveedor mediante el SDK de ese proveedor. Hasta entonces, la decisión de sustrato es real, y confirmar la forma de integración actual contra la documentación en vivo antes de depender de ella es exactamente la disciplina que enseña el resto del curso.

El curso usa claude_local y opencode_local para el Legal Specialist en el ejemplo resuelto. La barra lateral siguiente muestra la misma solicitud de contratación apuntando en cambio a un runtime de Agent SDK autohospedado, que es el caso en el que el cambio genuinamente sí es una sola modificación de adapterConfig.url (un endpoint autohospedado no necesita relay).

Barra lateral: la versión de Agent SDK de la misma contratación

Si tu equipo quiere autohospedar el Legal Specialist en un endpoint de Claude Agent SDK (en vez de los dos adaptadores locales nativos de Paperclip que usa la Decisión 4), la carga útil de contratación solo cambia en adapterType y adapterConfig:

{
  "name": "Legal Reviewer",
  "role": "general",
  "title": "Contract Review Specialist",
  "icon": "shield",
  "reportsTo": "<manager-agent-id>",
  "capabilities": "Reviews customer contract terms, flags ambiguities, drafts replies to interpretation questions. Does NOT modify contracts.",
  "adapterType": "http",
  "adapterConfig": {
    "url": "https://internal-legal-agent.example.com/heartbeat",
    "headers": { "Authorization": "Bearer ${INTERNAL_AGENT_API_KEY}" },
    "timeoutSec": 300
  },
  "runtimeConfig": {
    "heartbeat": { "enabled": true, "intervalSec": 300, "wakeOnDemand": true }
  },
  "sourceIssueId": "PAP-128"
}

Todo lo demás (paquete de evaluación, flujo de aprobación, entradas del libro mayor de talento) es idéntico en las tres opciones. Desde la perspectiva de Paperclip, las versiones claude_local, opencode_local y Agent SDK sobre http son el mismo Worker. La forma de costo y la propiedad operativa difieren entre ellas. Los dos adaptadores locales facturan solo tokens mediante la clave del proveedor con la que se autenticó la CLI, y tú eres responsable de la máquina anfitriona. Agent SDK sobre http tiene la misma forma de costo de solo tokens, y además eres responsable del endpoint entrante, la durabilidad y el sandboxing. (CMA, en cambio, agrega un cargo de runtime por hora de sesión, pero te entrega durabilidad y sandboxing a cambio). La decisión de sustrato es reversible cambiando adapterType más adapterConfig y volviendo a enviar la contratación. No es una puerta de una sola dirección.

Prueba con IA

Pega esto en tu asistente de codificación con IA:

"Estoy eligiendo el sustrato para contratar tres Workers nuevos. Para cada uno, recomienda una de estas opciones: claude_local, opencode_local, Claude Agent SDK vía http, Claude Managed Agents vía http más relay, o process. Explica por qué.

Worker A: un 'revisor de PR de GitHub' que lee diffs de pull requests, comprueba patrones de seguridad y publica comentarios. Volumen: unas 80 PR por semana. Cada sesión dura de 2 a 5 minutos.

Worker B: un 'resumen nocturno de métricas' que consulta Postgres a las 2 AM, genera un informe resumido y lo publica en Slack. Determinista; no necesita razonamiento de IA.

Worker C: un 'orquestador de onboarding de clientes' que lee el perfil de un cliente nuevo, redacta un correo de bienvenida personalizado, agenda una llamada de seguimiento mediante la API de Calendly y actualiza Salesforce. Varias herramientas, varios pasos, sesiones de unos 10 minutos, unos 200 onboardings por semana."

El objetivo del ejercicio no son las recomendaciones concretas (tu asistente dará opciones plausibles), sino hacer visible la decisión de sustrato. Los Workers en tu fuerza laboral real se parecerán a estos tres: breve y barato (A), determinista y sin herramientas de IA (B), largo y orquestacional (C), y cada uno pide un sustrato distinto. La API de contratación es la misma para todos; lo que cambia es el sustrato debajo.

Conclusión: dónde se ejecuta realmente el Worker es una decisión separada de cómo se lo contrata. Cinco opciones comunes cubren el rango, desde "Paperclip inicia el runtime por sí mismo" (claude_local, opencode_local, process), pasando por "tú alojas el ciclo del agente" (Claude Agent SDK sobre http), hasta "Anthropic aloja todo" (Claude Managed Agents sobre http más un relay delgado). La solicitud de contratación en sí es la misma en todas; solo cambian adapterType y adapterConfig. Elige un adaptador local nativo de Paperclip cuando el camino más simple sea suficiente; elige CMA cuando tu Worker realmente necesite sesiones duraderas en la nube; elige Agent SDK cuando necesites control total del entorno de ejecución; elige process cuando no se requiera inteligencia en absoluto.

Parte 3: Gobernanza para la contratación

Las partes 1 y 2 cubrieron la detección y la propuesta. La parte 3 es la parte cuidadosa: qué ocurre entre la propuesta y la aprobación, qué autoridad se concede al nuevo Worker y cuándo, si alguna vez, el humano puede salir del bucle. Tres conceptos.

Concepto 7: Contratación mediante la puerta de aprobación del curso seis

El concepto 11 del curso seis presentó las aprobaciones como una primitiva: un Worker se pausa de forma duradera, publica una solicitud en la junta, espera y se reanuda según la decisión de la junta. El bucle de contratación del curso siete reutiliza esa misma primitiva, sin modificaciones. La única diferencia es la carga útil. En lugar de una decisión de reembolso de $500, el hilo de aprobación lleva una propuesta de contratación, resultados de evaluación, presupuesto esperado y un borrador del marco de autoridad.

Este es el beneficio estructural más limpio entre los cursos seis y siete. El diseño del arquitecto gana dos veces: primero porque la primitiva de aprobación resolvió el problema de los reembolsos en el curso seis, y otra vez porque resuelve el problema de contratación en el curso siete sin reconstruir nada. Una fuerza laboral que ya tiene aprobaciones ya sabe cómo contratar. La junta ve un artefacto más completo; la maquinaria subyacente es la misma.

Barra lateral: la contratación es uno de varios tipos de aprobación con nombre

La referencia de la API de Paperclip documenta hire_agent como el tipo de aprobación usado para contratar (confirmado textualmente en la forma de la respuesta: "type": "hire_agent"). En Paperclip existen otros tipos de aprobación para otras decisiones importantes; revisa la documentación de tu instancia para ver la lista actual. La filosofía es la misma sin importar qué tipos con nombre encuentres: en una empresa nativa de IA, ciertos primeros movimientos importantes no pueden ser unilaterales, por más experimentado que sea el agente que los realiza. La aprobación de contratación forma parte de una familia, no es un caso aislado.

Si solo revisas una parte de este diagrama, compara los dos botones "Decision required" al final de cada panel

Son idénticos. El panel naranja (reembolso del curso seis) y el panel morado (contratación del curso siete) presentan el mismo APPROVE / REQUEST CHANGES / DECLINE ante la junta. Esa igualdad es todo el argumento.

La carga útil de aprobación de contratación, cuando la junta la abre en la interfaz de Paperclip:

Primero, esta es la forma central que tiene toda aprobación: la parte que es idéntica entre una aprobación de reembolso (curso seis) y una aprobación de contratación (curso siete):

APPROVAL REQUEST: [type] : [subject]
===========================================
Requested by:    [which Worker is asking]
Source issue:    [which issue this came from]
Status:          pending_approval

[...type-specific body...]

DECISION REQUIRED
-----------------
[ APPROVE ]    [ REQUEST CHANGES ]    [ DECLINE ]

Ese es el contrato de la primitiva de aprobación: un encabezado, un issue fuente, un estado, un cuerpo tipado y tres botones de decisión. Cada aprobación del sistema (reembolsos, contrataciones, ampliaciones de marco, cualquier otra) completa esta plantilla.

Ahora, la versión completa específica de contratación. Las partes específicas de contratación van en el espacio [...type-specific body...]. Léela de arriba abajo:

APPROVAL REQUEST: Hire : Legal Specialist
===========================================
Requested by:    agent-manager-orchestrator (Manager-Agent)
Source issue:    PAP-128 (and 23 related issues over 3 weeks)
Status:          pending_approval

PROPOSED HIRE
-------------
Name:          Legal Reviewer
Title:         Contract Review Specialist
Reports to:    Manager-Agent
Substrate:     Claude Managed Agents (claude-opus-4-7)
Adapter:       http
Heartbeat:     every 5 min, wake on demand

CAPABILITIES (prose, exact as in hire payload)
-----------------------------------------------
Reviews customer contract terms, flags ambiguities, drafts replies
to interpretation questions. Does NOT modify contracts.

PROPOSED AUTHORITY ENVELOPE
---------------------------
refund_max:           $0       (Legal Specialist does not issue refunds)
contract_modify:      deny     (cannot modify; can only interpret)
contract_interpret:   allow    (NEW: this authority did not exist before)
external_email:       allow    (replies to customers directly)
pii_access:           audited  (inherits from company envelope)
spend_max:            $800/mo  (monthly cost ceiling; substrate-independent)

EVAL PACK RESULTS
-----------------
[full eval-pack summary, see Concept 5]

BUDGET ESTIMATE
---------------
Token cost (forecast):       $480/mo  (160 issues, ~$3 avg, claude_local or opencode_local)
Runtime overhead (forecast): $0       (Paperclip-native; CMA would add session-hour fees)
Total monthly budget:        $800/mo  (cap; substrate-independent; hard stop at exhaustion)

RATIONALE (from Manager-Agent's gap-detection ledger)
------------------------------------------------------
- 47 contract-related emails over the last 3 weeks (Sig 1: low confidence)
- 8 escalations to human board over the same period (Sig 2)
- Skill "contract_interpretation" returns empty on agent-configurations (Sig 3)
- All three gap-detection signals fire on the same category within window.

DECISION REQUIRED
-----------------
[ APPROVE ]    [ REQUEST CHANGES ]    [ DECLINE ]

La junta tiene tres botones. Approve contrata al Worker tal como se propuso. Request Changes abre un hilo de comentarios en la aprobación (mediante POST /api/approvals/{approvalId}/comments). Los comentarios típicos son:

"ajusta el marco"
"reduce el presupuesto"
"cambia el sustrato a claude_local para un primer ciclo de menor costo"
"cambia reports_to para que informe directamente a la junta durante el primer mes"

Decline rechaza la contratación y registra el motivo de la junta en activity_log (la propia fila de Paperclip aquí es approval.rejected; el currículo también se refiere a esto como un evento hire_declined cuando habla específicamente de la narrativa de contratación).

Qué ocurre en cada estado terminal:

APPROVE: Paperclip hace la transición del agente de pending_approval a idle. El Worker ahora existe como una estructura aprobada que puede recibir pulsos de actividad y asignaciones de issues, pero todavía no está en ejecución. El agent_id devuelto por la llamada de contratación original se convierte ahora en un Worker real. El Manager-Agent se despierta con PAPERCLIP_APPROVAL_ID definido en el entorno (según la referencia de la API de Paperclip). Luego, el Manager-Agent obtiene el estado de aprobación resuelto mediante GET /api/approvals/{approvalId} y los issues vinculados mediante GET /api/approvals/{approvalId}/issues. Comenta en el issue fuente (PAP-128) con un enlace a la página del nuevo Worker, y enruta el issue fuente (y los 23 issues relacionados) al nuevo Worker. El primer pulso de actividad del especialista legal se activa en un plazo de 5 minutos; en ese momento sale de idle para hacer trabajo real.
REQUEST CHANGES: La contratación permanece en pending_approval (la referencia de la API de Paperclip usa revision_requested para este estado). El Manager-Agent ve el comentario, revisa la carga útil (ajusta el marco, reduce el presupuesto, etc.) y la vuelve a enviar mediante POST /api/approvals/{approvalId}/resubmit. Se reutiliza el mismo hilo de aprobación; POST /api/approvals/{approvalId}/comments agrega la justificación de la revisión; la junta ve las diferencias. Hasta unas 5 rondas de revisión es normal; más allá de eso, la aprobación suele retirarse y se redacta una propuesta nueva.
DECLINE: La contratación se cierra. Paperclip escribe una fila approval.rejected en activity_log (el hire_declined del currículo es el mismo evento nombrado para la narrativa de contratación) que registra el motivo de la junta. El Manager-Agent actualiza las reglas de enrutamiento, por lo general enviando la categoría de issues correspondiente a una plantilla de "rechazar con cortesía", o reabriendo el issue con una marca explícita de escalar-a-humano. La brecha sigue registrada; la respuesta fue diferente.

El ciclo de vida completo de la aprobación es duradero. La maquinaria subyacente de Paperclip es step.wait_for_event (la misma primitiva de Inngest del curso cinco), lo que significa que el hilo de aprobación puede vivir durante horas o días sin consumir cómputo. Las juntas que necesiten pensar durante la noche, o sumar a un segundo miembro de la junta a la discusión, pueden hacerlo sin que la propuesta expire.

PRIMM: Predice

El sistema de aprobación de Paperclip ya aplica una restricción importante que todavía no he nombrado: el miembro de la junta que aprueba una contratación debe tener autoridad para conceder el marco solicitado. ¿Cuál es la consecuencia? Confianza de 1 a 5.

Considera esto: el marco de la empresa concede refund_max=$5000. Un Worker de nivel 1 tiene refund_max=$50. El Manager-Agent propone contratar a un especialista legal con contract_interpret=allow, una autoridad que no está en el marco de la empresa (porque ningún Worker ha tenido nunca esta autoridad; el marco de la empresa simplemente la omite). ¿Quién puede aprobar la contratación?

Respuesta: un miembro de la junta con autoridad para modificar el marco de la empresa, no solo autoridad para aprobar una contratación. Contratar con autoridad novedosa es una decisión de dos pasos: ampliar el marco de la empresa para permitir esa autoridad y después aprobar la contratación. El contract_interpret=allow del especialista legal es autoridad novedosa (ningún Worker existente la tiene), así que Paperclip la marca para la comprobación de ampliación del marco de la empresa. El concepto 8 recorre toda la cascada del marco y la forma de auditoría correspondiente. El principio en una línea: aprobar una contratación que introduce nueva autoridad también significa aprobar la ampliación de la superficie de la fuerza laboral.

Conclusión: la contratación pasa por exactamente el mismo proceso de aprobación que ya gestiona, por ejemplo, un reembolso de $500. La junta ve una solicitud, la comenta en un hilo y hace clic en un botón. Mismo mecanismo, mismo comportamiento de esperar-la-decisión, misma pista de auditoría. Lo único distinto de una contratación es lo que completa el formulario de solicitud: en lugar de un monto de reembolso, es un Worker propuesto, resultados de evaluación, un marco y un presupuesto. La herramienta del curso seis resolvió el problema del curso siete sin que nadie construyera una nueva.

Concepto 8: Herencia del marco de autoridad para nuevas contrataciones

El concepto 4 del curso seis presentó el marco de autoridad en cascada: empresa, organigrama, issue, aprobación. El curso siete agrega la capa de contratación a esa cascada. El marco de una nueva contratación se define en la propuesta, se bloquea en la aprobación y se registra en activity_log. Una vez bloqueado, el marco se comporta exactamente igual que el marco de cualquier otro Worker: se acota por issue en tiempo de ejecución y se amplía temporalmente mediante aprobaciones dentro de los límites de la empresa.

El marco de una nueva contratación se construye en tres pasos, cada uno con un actor distinto:

Paso 1: Herencia. El Manager-Agent que redacta la propuesta hereda el marco de la empresa como techo inicial. Todo lo que la empresa puede hacer, el Worker puede llegar a hacerlo, pero no más. Si el refund_max=$5000 del marco de la empresa, el refund_max del Worker propuesto no puede superar los $5000.

Paso 2: Acotación. El Manager-Agent acota el techo de la empresa hasta el marco adecuado para el rol. Los Workers de nivel 1 podrían tener refund_max=$50. El especialista legal podría tener refund_max=$0. Acotar es una decisión de criterio del Manager-Agent que propone, basada en el rol (la prosa de capacidades del concepto 4), los resultados de evaluación (concepto 5) y el presupuesto (concepto 7). Los marcos más estrechos suelen ser más seguros; la regla práctica es "tan estrecho como permita hacer el trabajo, nunca más amplio que el techo de la empresa".

Paso 3: Ampliación del marco (el caso raro). Cuando el marco propuesto contiene un campo de autoridad que la empresa todavía no tiene, la propuesta activa la comprobación de ampliación del marco (la respuesta de PRIMM: Predice del concepto 7). El contract_interpret=allow del especialista legal es el ejemplo canónico: ningún otro Worker tiene esta autoridad y ninguna otra propuesta ha ampliado nunca el marco de la empresa para incluirla. La junta tiene que decidir conscientemente "sí, queremos que nuestra empresa conceda esta autoridad de ahora en adelante". Una vez aprobada, el marco de la empresa crece para incluir contract_interpret, y las contrataciones futuras pueden heredarlo sin un paso de ampliación.

El registro de actividad para una ampliación de marco se ve así. (envelope_extension es una acción del currículo: el curso modela la ampliación como su propia fila de auditoría, superpuesta a las primitivas de aprobación de Paperclip. Usa el campo action, como cualquier otra fila).

{
  "created_at": "2026-05-12T14:32:07Z",
  "action": "envelope_extension",
  "company_id": "comp_abc",
  "agent_id": null,
  "issue_id": "PAP-128",
  "approval_id": "appr_xyz",
  "actor_id": "board_member_dan",
  "extension_details": {
    "field_added": "contract_interpret",
    "from": "(field not present)",
    "to": "allow (audited)",
    "rationale": "Hiring Legal Specialist; capability did not exist on the workforce previously. Board approves extending the company envelope to include this authority. Future hires inheriting this authority require standard hire approval, not envelope-extension approval."
  }
}

El campo de justificación es obligatorio: el miembro de la junta que escribe la aprobación tiene que explicar por qué está ampliando el marco. Ese es el ancla de auditoría. Seis meses después, cuando un responsable de cumplimiento pregunte "¿por qué nuestra fuerza laboral tiene autoridad para interpretar contratos?", la respuesta será una sola fila de activity_log con una justificación escrita y un issue fuente vinculado.

La cascada después de aprobar la contratación:

Capa	Marco	Definido por	¿Mutable?
Empresa	`contract_interpret=allow (audited)`, `refund_max=$5000`, ...	Junta, mediante aprobación de ampliación de marco	Sí, pero requiere aprobación de ampliación de marco
Rol (especialista legal)	`contract_interpret=allow`, `refund_max=$0`, `contract_modify=deny`	Junta, mediante aprobación de contratación	Sí, pero requiere reaprobación
Issue (PAP-128)	hereda el marco del rol	Manager-Agent, mediante enrutamiento	Solo acotación por issue
Aprobación (ampliación rara por issue)	p. ej., `contract_modify=allow` temporal para un issue	Junta, mediante aprobación	Sí, pero solo dentro del techo de la empresa y vence al completarse

La propiedad fundamental: los marcos solo se acotan hacia abajo; ampliarlos requiere acción explícita de la junta y queda registrado. Un Worker contratado con contract_interpret=allow no puede concederse a sí mismo contract_modify=allow en tiempo de ejecución. Ni siquiera el Manager-Agent, que orquesta toda la fuerza laboral, puede ampliar unilateralmente el marco de un Worker. Toda ampliación, en cualquier capa, pasa por la primitiva de aprobación.

Conclusión: un nuevo Worker solo puede hacer lo que su marco permite. El marco parte de los permisos generales de la empresa y se acota para el rol específico. Si una contratación le daría al Worker un permiso que nadie en la empresa ha tenido nunca, primero hay que ampliar los permisos generales de la empresa; esa ampliación se registra permanentemente, con una razón escrita, para que los humanos del futuro puedan ver por qué se concedió.

Concepto 9: Política de aprobación automática: cuándo los humanos aprueban previamente una clase

Los conceptos 7 y 8 preparan el flujo de contratación con humano en el bucle. Cada contratación pasa por la junta. Cada ampliación de marco pasa por la junta. Para una fuerza laboral de 3 a 5 Workers que crece lentamente, este es el valor predeterminado correcto: la junta tiene tiempo de revisar cada contratación, las decisiones sobre marcos son poco frecuentes y el cuello de botella es aceptable.

Para fuerzas laborales que escalan, el cuello de botella se vuelve real. Una empresa SaaS B2B que contrata Workers de nivel 1 para capacidad de ráfaga cuando el tráfico se dispara podría necesitar 5 Workers nuevos en una ventana de 24 horas. Una plataforma de contenido que pone en marcha Workers de soporte por idioma al expandirse a nuevos mercados podría contratar un Worker nuevo por semana durante seis meses. Enrutar cada una de estas contrataciones por una aprobación humana de la junta es la misma disfunción que el curso cinco resolvió para los reembolsos rutinarios: la junta se convierte en la cola, y la fuerza laboral no puede reaccionar a la demanda más rápido de lo que la junta lee su bandeja de entrada.

La solución: una política de aprobación automática para una clase de contrataciones. No para todas las contrataciones; eso abandona la propiedad de seguridad. Para una clase definida de contrataciones, con techos explícitos, donde la junta ya decidió "sí, contrata estas libremente, pero avísame después".

Si solo revisas una parte de este diagrama, mira el cuadro rojo del flujo de decisión de la derecha

"¿La contratación amplía el marco de la empresa?" Cuando la respuesta es sí, la contratación se enruta a la junta humana sin importar qué tan rutinaria parezca. Esa es la propiedad de seguridad que sostiene el sistema: la aprobación automática puede saltarse la junta en contrataciones rutinarias, pero nunca en contrataciones que conceden nueva autoridad.

Una política es un documento JSON que la junta escribe una vez, firmado con una clave de nivel junta. Define:

La clase: ¿qué cuenta como este tipo de contratación? (identificador de rol, patrón de capacidades, patrón de issue fuente)
El techo: ¿qué marco y presupuesto puede aprobar automáticamente esta clase? (no debe ser más amplio que el marco de ningún Worker existente)
La auditoría: ¿cómo se muestra la contratación aprobada automáticamente a la junta después del hecho? (resumen diario, alertas de anomalía, etc.)
La expiración: ¿cuándo se revoca automáticamente esta política? (siempre define una expiración; nunca "para siempre")

Ejemplo de política para contrataciones de nivel 1 por capacidad de ráfaga:

{
  "policy_id": "auto_approve_tier1_burst",
  "policy_version": "v1.2026.05.10",
  "class_match": {
    "role": "general",
    "envelope_must_match_existing": "agent-tier1-support-1",
    "spend_max_per_month": 250
  },
  "auto_approve_constraints": {
    "max_concurrent_auto_hires": 5,
    "max_auto_hires_per_24hr": 5,
    "must_retire_within_days": 14,
    "must_pass_eval_pack": "tier1_support_eval_pack_v3"
  },
  "audit": {
    "daily_digest_to": "board@example.com",
    "anomaly_alerts": {
      "budget_overrun_pct": 110,
      "eval_pack_fail_rate_pct": 5
    }
  },
  "expires_at": "2026-08-10T00:00:00Z",
  "approved_by": ["board_member_dan", "board_member_jess"],
  "approved_at": "2026-05-10T15:22:00Z"
}

Cuando llega una solicitud de contratación que coincide con class_match, Paperclip comprueba la política: ¿el marco solicitado es idéntico al de un Worker existente? ¿El presupuesto está dentro del techo? ¿El eval pack se aprobó? ¿Estamos por debajo de los límites de concurrencia y frecuencia? Si todas las comprobaciones pasan, la contratación pasa de pending_approval a policy_approved sin intervención de la junta, pero la aprobación por política queda registrada en el registro de actividad con una carga útil details que nombra la política (auto_approve_tier1_burst v1.2026.05.10), y el resumen diario muestra la contratación a la junta a la mañana siguiente. (auto_approved_by_policy es la etiqueta del currículo para esta fila; como ocurre con las otras acciones del currículo, lo que importa es la forma de auditoría, no el valor exacto).

El rol de la junta en las políticas de aprobación automática:

Escribir la política. Esto es en sí mismo una decisión de nivel junta; el documento de política es el artefacto.
Revisar el resumen diario. La junta lee "5 contrataciones de ráfaga de nivel 1 ayer, todas aprobaron la evaluación, todas dentro del presupuesto" y confirma que la política está funcionando. Si las contrataciones empiezan a verse fuera de patrón, la junta puede desactivar la política.
Renovar o actualizar la política cuando expire. Las políticas nunca viven para siempre. La expiración de 90 días obliga a la junta a decidir de nuevo "sí, esta sigue siendo la política correcta" de forma periódica.

Lo que una política no puede hacer: aprobar automáticamente una contratación que amplía el marco de la empresa. La comprobación de ampliación de marco del concepto 8 se dispara sin importar la política. Esa es la garantía de seguridad que sostiene el sistema, mantenida deliberadamente fuera de la superficie de aprobación automática.

La política de aprobación automática es la rampa de entrada desde "cada contratación requiere aprobación humana" hacia "la fuerza laboral escala sin que la junta sea la cola, pero la junta sigue siendo dueña de las decisiones que importan". No es una forma de sacar a los humanos de la contratación; es una forma de elegir dónde deben estar los humanos.

Comprobación rápida

Supón que tu junta tiene activa la política de capacidad de ráfaga anterior. El Manager-Agent envía una solicitud de contratación para un Worker de nivel 1 con refund_max=$50 y spend_max=$240/mo. El eval pack se aprueba. Autocontrataciones concurrentes de nivel 1 hoy: 3. Autocontrataciones concurrentes de nivel 1 en las últimas 24 h: 4. ¿La contratación se aprueba automáticamente? Recorre cada restricción de la política.

Conclusión: la junta puede decidir previamente "sí, contrata libremente" para una clase definida de contrataciones (techo de marco, eval pack obligatorio, fecha de expiración, auditoría con resumen diario). Pero la aprobación automática nunca puede omitir la comprobación de ampliación del marco. La nueva autoridad siempre involucra a un humano, por más rutinaria que parezca la contratación.

Parte 4: El ejemplo trabajado: contratar a un especialista legal

Las partes 1 a 3 definieron la arquitectura. La parte 4 recorre el laboratorio de punta a punta: ampliar la fuerza laboral del Curso seis, detectar la brecha, redactar la propuesta, pasarla por la puerta de aprobación, contratar al especialista legal en un adaptador nativo de Paperclip, ejecutar el paquete de evaluación, observar el primer latido y ver cómo se actualiza el registro de talento. El laboratorio ejecuta la misma contratación en dos adaptadores en paralelo (claude_local y opencode_local) para mostrar que el ciclo de contratación tiene la misma forma tanto en runtimes respaldados por Claude como en runtimes enrutados por OpenCode. Siete decisiones, unas 2 a 3 horas de práctica, alrededor de 3.500 palabras de código y comentario.

Esta parte supone que ya tienes la instancia del Curso seis ejecutándose localmente (npx paperclipai onboard --yes produjo un Paperclip funcional con los tres Workers del Curso seis). Si no la tienes, completa primero el laboratorio del Curso seis. El Curso siete amplía esa fuerza laboral; no la reconstruye.

Dos datos de configuración de los que depende el resto de la parte 4

Las contrataciones solo pasan por la junta si la empresa lo activa. En una empresa Paperclip predeterminada, requireBoardApprovalForNewAgents es false: una contratación devuelve de inmediato el nuevo Worker en estado idle, sin puerta de aprobación. Toda la narrativa del Curso siete supone que la puerta se dispara. Antes del laboratorio, configúralo una vez: PATCH /api/companies/{companyId} con { "requireBoardApprovalForNewAgents": true }. Tu asistente de IA puede hacerlo como primer paso de la Decisión 1. Sin esto, el código de la Decisión 3 (que espera recibir un estado pending_approval) no tiene nada que esperar.

Nomenclatura del registro de actividad. La tabla activity_log de Paperclip usa un campo llamado action (no action_type), y los eventos propios de Paperclip usan espacios de nombres con puntos: agent.hire_created, approval.created, approval.approved, approval.rejected, budget.policy_upserted, etc. Este curso también escribe algunas filas propias desde el código del Manager-Agent (el ejemplo más claro es gap_detected en la Decisión 1). Esas filas personalizadas siguen usando el campo action; sus valores son nombres del currículo, no valores emitidos por Paperclip, y eso está bien siempre que mantengas claros ambos tipos. Cuando este curso muestra un valor de action que Paperclip emite por sí mismo, usa el nombre real con puntos; cuando muestra una fila personalizada, lo indica.

Si algo se rompe, revisa esto primero

(Estas causas explican la gran mayoría de los fallos del laboratorio).

run dice "all checks passed" y luego "failed to start". El Postgres integrado de Paperclip puede competir con su propio arranque: doctor informa que todas las comprobaciones pasan, luego el servidor falla con connect ECONNREFUSED y una línea WARN: Embedded PostgreSQL already running. Es un proceso antiguo de Postgres integrado, no un fallo real. Ejecuta el comando otra vez; el segundo arranque casi siempre funciona.
Falta la CLI local que lanza el adaptador o no está autenticada. Los adaptadores claude_local y opencode_local de Paperclip lanzan localmente las CLI claude y opencode en cada latido. Las CLI deben estar instaladas en el mismo equipo que el daemon de Paperclip, y cada una debe tener sesión iniciada (la CLI claude usa tus credenciales de Anthropic; opencode lee el proveedor/modelo desde su propia configuración). Si una contratación está en idle pero no ocurre trabajo, ejecuta claude --version / opencode --version y confirma que ambas estén autenticadas antes de revisar cualquier otra cosa.
Deriva de versión de Paperclip entre el Curso seis y el Curso siete. Ejecuta paperclipai --version y npm view paperclipai version para comparar. Si tu versión local está por detrás de la publicada, la forma del endpoint agent-hires puede haber cambiado. Los campos desiredSkills, instructionsBundle y budgetMonthlyCents, en particular, son adiciones recientes. Actualiza con npm i -g paperclipai@latest y reinicia el daemon antes de continuar.
Una contratación recibe un issue, el latido se dispara, pero el issue sigue abierto y aumenta el conteo de comentarios. Paperclip volverá a despertar un issue asignado que no esté en done mediante su conciliador de revisión de productividad, incluso cuando runtimeConfig.heartbeat.enabled sea false. El Worker debe llegar a una disposición final (done, in_review o blocked); un Worker claude_local u opencode_local lo maneja de forma nativa cuando su system prompt incluye una lista de verificación de disposición (que instala el prompt de la Decisión 4 más abajo). Si ves un ciclo descontrolado de comentarios, marca el issue como done y desasígnalo; luego ajusta el prompt del Worker.

Si nada de esto explica el fallo, el rastreador de issues de Paperclip es el lugar correcto para revisar a continuación.

La estructura completa del laboratorio:

#	Decisión	Qué habrás construido después
1	Conectar la detección de brechas de capacidad en el Manager-Agent	Un detector de brechas que observa patrones de enrutamiento y escribe registros de "brecha detectada" en `activity_log`
2	Generar el artefacto de propuesta de contratación	Un documento de propuesta (descripción del puesto, paquete de evaluación de capacidades, costo esperado, borrador del sobre de autoridad) que el Manager-Agent puede producir
3	Pasar la propuesta por la puerta de aprobación de Paperclip	La primitiva de aprobación del Curso seis reutilizada para contrataciones, con el payload enriquecido del Concepto 7
4	Conectar el sustrato de runtime del especialista legal	La misma contratación conectada a dos adaptadores nativos de Paperclip en paralelo: `claude_local` (Claude CLI) y `opencode_local` (OpenCode CLI)
5	Ejecución de evaluación de capacidades	El Worker candidato maneja 12 issues de prueba; los resultados se puntúan y se publican en el hilo de aprobación
6	Enrutar un issue contractual legal real al nuevo Worker	Se dispara el primer latido del especialista legal; una fila de `activity_log` registra actor, autoridad, costo y resultado
7	Retiro y recontratación	El Worker se retira con cuidado cuando baja el tráfico; Paperclip rastrea el Worker inactivo y lo recontrata cuando vuelven los patrones

Estado final esperado

Al final de la parte 4, tu instancia local de Paperclip tiene:

Cuatro Workers en lugar de tres (soporte de nivel 1, especialista de nivel 2, Manager-Agent, especialista legal)
Un sobre de empresa actualizado que ahora concede contract_interpret=allow (audited), ampliado en el momento de aprobación de la contratación con una justificación escrita
Filas de activity_log que cubren: 3 semanas de señales de detección de brechas, la propuesta de contratación, los resultados del paquete de evaluación, el hilo de aprobación, la ampliación del sobre, la decisión de aprobación, los primeros 12 issues de evaluación del especialista legal, el primer issue real de cliente enrutado a él y (más adelante) el evento de retiro
Filas de cost_events etiquetadas con el agent_id del especialista legal, que registran el costo en tokens de cada ejecución de latido en el adaptador (claude_local u opencode_local) que se haya usado
Una política de aprobación automática (opcional, barra lateral de la Decisión 6) para contrataciones de capacidad adicional de nivel 1

Decisión 1: Conectar la detección de brechas de capacidad en el Manager-Agent

En una línea: enseña al Manager-Agent a notar cuándo llega trabajo que ninguno de sus Workers actuales puede manejar bien y a registrar ese patrón, sin proponer todavía una contratación.

Qué haces (tu asistente de codificación con IA). Abre tu asistente de codificación con IA en el directorio del proyecto del Curso seis. Pega:

"Estoy empezando el Curso siete del curso acelerado de Agent Factory. El Manager-Agent del Curso seis ahora enruta issues a uno de tres Workers (soporte de nivel 1, especialista de nivel 2 o él mismo). Necesito agregar detección de brechas de capacidad a su lógica de enrutamiento. Lee el archivo actual manager-agent/router.ts y luego agrega una nueva función detectCapabilityGap(issueId, routingResult) que observe las tres señales del Concepto 2 del Curso siete: (1) confianza de enrutamiento por debajo de 0.6 en al menos 3 issues de la misma categoría dentro de una ventana de 14 días, (2) al menos 3 escalaciones a la junta humana en la misma categoría, (3) skill-match que devuelve vacío para las habilidades declaradas del issue. La función debe escribir una fila en activity_log con action='gap_detected' y la categoría como details.category. (gap_detected es una acción personalizada que escribe tu Manager-Agent, no una acción emitida por Paperclip; esa distinción está bien, consulta la nota de nomenclatura del registro de actividad anterior). No propongas todavía una contratación (eso es la Decisión 2). Solo detecta y registra."

Tu asistente lee router.ts, escribe detectCapabilityGap y propone una prueba unitaria usando el framework de pruebas existente de tu proyecto. La función termina pareciéndose más o menos a esto:

async function detectCapabilityGap(
  issueId: string,
  routingResult: RoutingResult,
): Promise<void> {
  const category = await classifyCategory(issueId);

  // Signal 1: routing confidence under 0.6 on at least 3 issues, same category, 14 days
  // `issue_routed` here is a custom row your router writes; Paperclip's own
  // routing events use dotted names, so query whichever your code actually emits.
  const recentLowConfidence = await db.query(
    `
    SELECT COUNT(*) FROM activity_log
    WHERE company_id = $1 AND action = 'issue_routed'
      AND details->>'category' = $2
      AND (details->>'confidence')::float < 0.6
      AND created_at > NOW() - INTERVAL '14 days'
  `,
    [companyId, category],
  );

  // Signal 2: at least 3 escalations to human board, same category, 14 days
  // `escalation_to_board` is likewise a custom row your router writes.
  const recentEscalations = await db.query(
    `
    SELECT COUNT(*) FROM activity_log
    WHERE company_id = $1 AND action = 'escalation_to_board'
      AND details->>'category' = $2
      AND created_at > NOW() - INTERVAL '14 days'
  `,
    [companyId, category],
  );

  // Signal 3: skill match returns empty
  const skillMatchEmpty = routingResult.eligibleWorkers.length === 0;

  const signalsFired = [
    recentLowConfidence.count >= 3,
    recentEscalations.count >= 3,
    skillMatchEmpty,
  ].filter(Boolean).length;

  if (signalsFired >= 2) {
    // `gap_detected` is a custom action this Manager-Agent writes (not a
    // Paperclip-emitted one); it still uses the `action` field.
    await postActivityLog({
      action: "gap_detected",
      company_id: companyId,
      issue_id: issueId,
      agent_id: "agent-manager-orchestrator",
      details: {
        category,
        signals: {
          recentLowConfidence: recentLowConfidence.count,
          recentEscalations: recentEscalations.count,
          skillMatchEmpty,
        },
        recommendation:
          "Manager should evaluate hire-vs-escalate-vs-queue-vs-decline",
      },
    });
  }
}

Observa lo que esta función no hace: no decide qué hacer con la brecha. Eso corresponde a la Decisión 2 (redactar la propuesta) y, en última instancia, a la junta. La Decisión 1 solo registra.

Por qué. La detección de brechas de capacidad debe ocurrir por separado de la propuesta de contratación. La bifurcación contratar-vs-escalar-vs-poner en cola-vs-rechazar del Concepto 3 del Curso siete exige que el sistema vea el patrón antes de responder a él. Al escribir filas gap_detected que incluyen todos los datos de señal, haces que el patrón sea consultable más adelante. El Manager-Agent puede preguntar "muéstrame todas las brechas de los últimos 30 días que aún no han recibido respuesta" cuando redacte la propuesta de la Decisión 2.

Qué cambia si usas una pila distinta. El ejemplo está en TypeScript porque Paperclip está en TypeScript. La lógica se puede portar a cualquier lenguaje que pueda consultar el Postgres de Paperclip y publicar en activity_log. Si tu Manager-Agent está en Python (porque usas OpenAI Agents SDK del Curso tres), la misma función en Python ocupa unas 30 líneas con psycopg2 y requests.post.

Decisión 2: Generar el artefacto de propuesta de contratación

En una línea: toma una brecha detectada y conviértela en una propuesta de contratación completa: descripción del puesto, permisos propuestos, costo esperado y una lista de preguntas de prueba para hacerle al candidato. No la envíes todavía.

Qué haces (tu asistente de codificación con IA). Pega:

"Ahora agrega una función generateHireProposal(category) que el Manager-Agent llame cuando decida que una categoría justifica una contratación. La función debe: (1) leer los registros de detección de brechas de esta categoría para reunir la justificación, (2) revisar las agent-configurations existentes mediante GET /api/companies/{companyId}/agent-configurations para encontrar Workers similares que pueda reflejar, (3) redactar un payload de solicitud de contratación de 10 campos según el Concepto 4 del Curso siete, (4) redactar un sobre de autoridad propuesto según el Concepto 8 del Curso siete (heredado del sobre de la empresa y acotado para este rol), (5) llamar a una función separada buildEvalPack(category) para generar unos 12 issues de prueba representativos para el candidato, (6) devolver toda la propuesta como un objeto estructurado. No la envíes todavía (eso es la Decisión 3)."

Tu asistente lee los patrones existentes (la skill paperclip-create-agent de Paperclip en skills/paperclip-create-agent/SKILL.md es la referencia canónica; tu asistente debe obtenerla), redacta la función y propone una salida de propuesta de ejemplo para el caso del especialista legal. La propuesta completa que produce:

interface HireProposal {
  hireRequest: {
    name: string;
    role: string;
    title: string;
    icon: string;
    reportsTo: string;
    capabilities: string;
    adapterType: string;
    adapterConfig: object;
    runtimeConfig: object;
    sourceIssueId: string;
    sourceIssueIds: string[]; // related issues from the gap-detection cluster
  };
  proposedEnvelope: {
    refund_max: number;
    contract_modify: "allow" | "deny";
    contract_interpret?: "allow" | "deny";
    external_email: "allow" | "approval" | "deny";
    pii_access: "audited" | "allow" | "deny";
    spend_max_monthly_usd: number;
  };
  budgetEstimate: {
    tokens_usd_monthly: number;
    runtime_overhead_usd_monthly: number; // 0 for Paperclip-native local adapters; session-hour fees for managed-cloud
    total_monthly_usd: number;
    estimate_basis: string;
  };
  evalPack: EvalIssue[];
  rationale: {
    signals_fired: string[];
    issues_observed_count: number;
    escalations_count: number;
    category: string;
    timeframe: string;
  };
  noveltyChecks: {
    extends_company_envelope: boolean;
    novel_authority_fields: string[];
  };
}

El campo noveltyChecks es el punto de cumplimiento de PRIMM Predict del Concepto 7. Antes de enviar la contratación, la función compara cada campo de autoridad del sobre propuesto con el sobre de la empresa. Si algún campo de autoridad no está presente en el sobre de la empresa (por ejemplo, contract_interpret), extends_company_envelope se establece en true y el campo se incluye en novel_authority_fields. Esta marca viaja con la propuesta. La puerta de aprobación de la Decisión 3 la usará para decidir si la aprobación estándar de contratación es suficiente o si se dispara la comprobación de ampliación del sobre.

La propuesta de ejemplo para el especialista legal (la salida de la función, no la solicitud enviada a Paperclip):

{
  "hireRequest": {
    "name": "Legal Reviewer",
    "role": "general",
    "title": "Contract Review Specialist",
    "icon": "shield",
    "reportsTo": "agent-manager-orchestrator",
    "capabilities": "Reviews customer contract terms, flags ambiguities, drafts replies to interpretation questions. Does NOT modify contracts.",
    "adapterType": null,
    "adapterConfig": {},
    "runtimeConfig": {
      "heartbeat": { "enabled": false, "wakeOnDemand": true }
    },
    "sourceIssueId": "PAP-128",
    "sourceIssueIds": ["PAP-128", "PAP-134", "PAP-141"]
  },
  "proposedEnvelope": {
    "refund_max": 0,
    "contract_modify": "deny",
    "contract_interpret": "allow",
    "external_email": "allow",
    "pii_access": "audited",
    "spend_max_monthly_usd": 800
  },
  "budgetEstimate": {
    "tokens_usd_monthly": 480,
    "runtime_overhead_usd_monthly": 0,
    "total_monthly_usd": 480,
    "estimate_basis": "160 issues per month at $3 average token cost on a Paperclip-native local adapter. If the human reviewer picks a managed-cloud substrate in Decision 4 (CMA), add session-hour fees on top; the substrate-decision pricing is in Concept 6's table."
  },
  "evalPack": [],
  "rationale": {
    "signals_fired": ["low_confidence", "escalations", "skill_match_empty"],
    "issues_observed_count": 47,
    "escalations_count": 8,
    "category": "contract_interpretation",
    "timeframe": "3 weeks"
  },
  "noveltyChecks": {
    "extends_company_envelope": true,
    "novel_authority_fields": ["contract_interpret"]
  }
}

Por qué importa esto. La propuesta es el artefacto que ve la junta. El Concepto 7 cubrió cómo se ve la aprobación renderizada en la UI de Paperclip; la Decisión 2 genera la estructura de datos subyacente. Dos decisiones de diseño que conviene destacar:

El Manager-Agent no elige el sustrato. adapterType y adapterConfig se completan en la Decisión 4 (después de que el humano revise; el sustrato es una decisión real de costo y la junta debe aprobar las CLI locales nativas de Paperclip frente al Agent SDK, CMA o process). El Manager-Agent propone un rol; el humano aprueba cómo se ejecuta.
El paquete de evaluación se genera con la propuesta, no después de la aprobación. El Concepto 5 lo explicó: la junta debe ver resultados de evaluación antes de aprobar. La Decisión 2 envía el paquete de evaluación como parte del payload de la propuesta; la Decisión 5 ejecuta el paquete.

PRIMM: Predict

Tu función generateHireProposal devuelve la estructura anterior. El campo noveltyChecks.extends_company_envelope es true debido a contract_interpret. ¿Cuál es el siguiente comportamiento correcto cuando la Decisión 3 envía esto a la puerta de aprobación de Paperclip? Confianza de 1 a 5.

(a) El flujo de aprobación continúa normalmente; basta la aprobación de un miembro de la junta. (b) La puerta de aprobación dispara una comprobación adicional que exige dos miembros de la junta. (c) La puerta de aprobación se niega a mostrar la propuesta hasta que el sobre de la empresa se amplíe explícitamente mediante un flujo de aprobación separado. (d) Paperclip rechaza directamente la solicitud de contratación porque el sobre propuesto supera el de la empresa.

Respuesta: (b) o (c). Paperclip admite ambas opciones según la política. La configuración enviada por defecto en Paperclip es (b): la puerta de aprobación dispara una comprobación adicional y el miembro de la junta ve un banner especial de ampliación del sobre en la aprobación. Con aprobaciones de dos de tres miembros configuradas (definidas en la política de la empresa), dos miembros deben aprobar explícitamente. Algunas empresas prefieren (c): separar la ampliación del sobre de la decisión de contratación en dos aprobaciones secuenciales. La arquitectura admite ambas; la elección es operativa, no técnica.

Decisión 3: Pasar la propuesta por la puerta de aprobación de Paperclip

En una línea: envía la propuesta a Paperclip, que la muestra a la junta humana, espera de forma durable su decisión y vuelve a despertar al Manager-Agent cuando hayan votado. Reutiliza sin cambios el mecanismo de aprobación del Curso seis.

Qué haces (tu asistente de codificación con IA). Pega:

"Ahora conecta el Manager-Agent para enviar la propuesta de contratación generada en la Decisión 2. El flujo de envío según el Concepto 7 del Curso siete: (1) llamar a POST /api/companies/{id}/agent-hires con el payload hireRequest, (2) analizar la respuesta. Si el estado es pending_approval, capturar el approval_id devuelto, (3) publicar un comentario en el hilo de aprobación con POST /api/approvals/{approvalId}/comments que incluya el resumen del paquete de evaluación, la justificación y las comprobaciones de novedad, (4) esperar de forma durable la decisión de la junta (Paperclip despertará al Manager-Agent con PAPERCLIP_APPROVAL_ID cuando se tome la decisión), (5) al recibir APPROVE, comentar en el issue fuente (PAP-128) con un enlace al nuevo Worker y enrutarle el issue fuente más los issues relacionados. No ejecutes todavía el paquete de evaluación (eso es la Decisión 5)."

Tu asistente produce el flujo de envío, aproximadamente así:

async function submitHireProposal(proposal: HireProposal): Promise<string> {
  // Step 1: submit the hire
  const res = await fetch(
    `${PAPERCLIP_API_URL}/api/companies/${PAPERCLIP_COMPANY_ID}/agent-hires`,
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${PAPERCLIP_API_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(proposal.hireRequest),
    },
  );
  const result = await res.json();

  // This expects the company to have `requireBoardApprovalForNewAgents: true`
  // (Part 4's setup note covers flipping it). On a default company the hire
  // comes back `idle` with `approval: null` and skips the gate entirely, so
  // this guard is also what catches a company that was never configured.
  if (result.agent.status !== "pending_approval") {
    throw new Error(
      `Hire did not enter the approval gate (status: ${result.agent.status}). ` +
        `Confirm the company has requireBoardApprovalForNewAgents enabled.`,
    );
  }

  const approvalId = result.approval.id;
  const candidateAgentId = result.agent.id;

  // Step 2: post the proposal payload as an approval-thread comment
  await fetch(`${PAPERCLIP_API_URL}/api/approvals/${approvalId}/comments`, {
    method: "POST",
    headers: {
      /* auth, content-type */
    },
    body: JSON.stringify({
      body: renderProposalSummary(proposal), // see below
    }),
  });

  // Step 3: post the eval pack on the approval thread too
  await fetch(`${PAPERCLIP_API_URL}/api/approvals/${approvalId}/comments`, {
    method: "POST",
    headers: {
      /* auth, content-type */
    },
    body: JSON.stringify({
      body: renderEvalPack(proposal.evalPack),
    }),
  });

  // Step 4: durably wait for the board's decision
  //   This step exits when Paperclip wakes the Manager-Agent with PAPERCLIP_APPROVAL_ID
  await waitForApprovalDecision(approvalId);

  return candidateAgentId;
}

La función renderProposalSummary produce el Markdown que ve la junta en la UI de aprobación; es la misma plantilla del renderizado "APPROVAL REQUEST: Hire: Legal Specialist" del Concepto 7. renderEvalPack produce una tabla Markdown similar con los 12 issues de prueba y sus respuestas de referencia.

La espera durable del paso 4 es la primitiva clave de Inngest: la función del Manager-Agent se suspende hasta que se decide la aprobación y luego se reanuda. Sin polling. Sin ciclos infinitos. La función queda pausada como una continuación serializada; cuando la junta aprueba o rechaza, Paperclip despierta la ejecución de Inngest con PAPERCLIP_APPROVAL_ID en el entorno y la función continúa desde donde quedó. Para encontrar los issues vinculados, la función reanudada llama a GET /api/approvals/{approvalId}/issues.

Por qué importa esto. La Decisión 3 es donde trabaja la primitiva de aprobación del Curso seis. El Manager-Agent no tuvo que aprender un nuevo patrón de "aprobación de contratación". Es la misma durabilidad de wait_for_event que el Curso seis usó para el reembolso de $750 en su Decisión 6. El flujo de contratación es el flujo de reembolso con un payload más rico. Ese es el resultado arquitectónico sobre el que se construye todo este curso.

Decisión 4: Conectar el sustrato de runtime del especialista legal

En una línea: define una vez la identidad del especialista legal (system prompt, capacidades, presupuesto) y luego conecta la misma contratación a dos adaptadores nativos de Paperclip en paralelo, claude_local y opencode_local, para que una junta que prefiera uno u otro pueda elegir sin cambiar nada más del rol.

Qué haces (tu asistente de codificación con IA). Pega:

"Necesito conectar el sustrato de runtime del especialista legal. Usa el patrón nativo de Paperclip: no levantes un servicio externo, deja que Paperclip lance por sí mismo la CLI local del agente de codificación en cada latido. La misma contratación debe funcionar en dos adaptadores: claude_local (Paperclip lanza la CLI claude sin interfaz) y opencode_local (Paperclip lanza la CLI opencode sin interfaz, multiproveedor provider/model). Paso 1: escribe una sola vez el system prompt del especialista legal, incluida una lista de verificación de disposición final para que el Worker llegue a done, in_review o blocked en cada issue asignado en lugar de entrar en un ciclo. Paso 2: para cada adaptador, produce el payload de contratación correspondiente, con name, role, title, capabilities, budgetMonthlyCents y sourceIssueId idénticos; solo difieren adapterType y adapterConfig. Paso 3: confirma que ambas CLI estén instaladas y autenticadas en el mismo equipo que el daemon de Paperclip (claude --version, opencode --version). No ejecutes latidos todavía (la Decisión 5 lo hace con el paquete de evaluación). Para el conjunto preciso de campos de adapterConfig, consulta GET /llms/agent-configuration/claude_local.txt y GET /llms/agent-configuration/opencode_local.txt en tu daemon activo; los campos cambian entre versiones de Paperclip."

Tu asistente escribe el system prompt compartido una vez y luego produce dos payloads de contratación que solo difieren en adapterType y adapterConfig. El lector elige qué pestaña leer; ambas son contrataciones reales en el mismo daemon de Paperclip.

{
  "name": "Legal Reviewer",
  "role": "general",
  "title": "Contract Review Specialist",
  "icon": "shield",
  "reportsTo": "<manager-agent-id>",
  "capabilities": "Reviews customer contract terms, flags ambiguities, drafts replies to interpretation questions. Does NOT modify contracts.",
  "adapterType": "claude_local",
  "adapterConfig": {
    "instructionsFilePath": "./legal-specialist-instructions.md",
    "maxTurnsPerRun": 3,
    "timeoutSec": 90
  },
  "runtimeConfig": {
    "heartbeat": { "enabled": true, "intervalSec": 300, "wakeOnDemand": true }
  },
  "budgetMonthlyCents": 80000,
  "sourceIssueId": "PAP-128"
}

En claude_local, Paperclip lanza la CLI claude sin interfaz en cada latido. Inyecta PAPERCLIP_API_URL y PAPERCLIP_API_KEY en el proceso lanzado para que el agente pueda leer su bandeja de entrada mediante GET /api/agents/me/inbox-lite y publicar comentarios mediante la API REST de Paperclip. La CLI aporta el ciclo del agente, la ejecución de herramientas y la autenticación; no hay ningún servicio externo entre Paperclip y el runtime.

Dos cosas que observar entre las pestañas:

La contratación es el mismo artefacto; el runtime es intercambiable. name, role, title, capabilities, budgetMonthlyCents, sourceIssueId y runtimeConfig son byte a byte idénticos entre los dos payloads. Solo cambian adapterType y adapterConfig. La aprobación de contratación (Decisión 3) no ve en absoluto la elección del sustrato; ve el rol.
Ambos adaptadores son nativos de Paperclip: sin relay, sin capa de pegamento, sin servicio externo. Paperclip ejecuta la CLI por sí mismo, con un canal autenticado de vuelta a su propia API. La barra lateral del Concepto 6 explica por qué importa esto; la versión corta es que "latido saliente a una URL externa" (la familia de adaptadores http) y "Paperclip lanza el runtime" (la familia de CLI locales) son formas de integración distintas, y el laboratorio usa deliberadamente la más simple.

El archivo de instrucciones (./legal-specialist-instructions.md) es donde vive el system prompt del especialista legal. Ambos adaptadores lo leen en cada lanzamiento. Mantén una sola fuente de verdad y los dos adaptadores seguirán siendo realmente intercambiables.

No pongas claves de proveedor en texto plano en adapterConfig.env

Si amplías el adapterConfig de cualquiera de los adaptadores con un mapa env (por ejemplo, para pasar una clave de API de proveedor a la CLI lanzada), Paperclip devolverá esos valores en texto plano en GET /api/agents/{id}. Un literal adapterConfig.env.DEEPSEEK_API_KEY queda legible para cualquiera con acceso de lectura de agentes en tu instancia de Paperclip. Para la versión de producción de esta contratación, conecta las claves de proveedor mediante la primitiva de secretos de Paperclip y refiérete a ellas de forma indirecta en lugar de insertarlas en línea; consulta GET /llms/secrets.txt en tu daemon activo para ver la forma actual. El ejemplo trabajado anterior mantiene adapterConfig libre de secretos precisamente para que este problema no se incorpore a un payload de contratación copiado y pegado.

Si prefieres alojar tú mismo el runtime

Si el corpus de referencia legal es sensible y quieres control total del entorno de ejecución, cambia adapterType a "http" y apunta adapterConfig.url a un servidor pequeño que envuelva el Claude Agent SDK (o cualquier otro ciclo de agente) y exponga un endpoint de latido compatible con Paperclip. Todo en la Decisión 4 y en las decisiones 5, 6 y 7 es igual después de ese cambio; solo cambia la forma de adapterConfig. Claude Managed Agents es el producto alojado de Anthropic para agentes de larga ejecución y aparece en la tabla de sustratos del Concepto 6. Hoy no tiene un adaptador de Paperclip de primera clase, así que un Worker respaldado por CMA necesitaría por ahora un servidor de pegamento delgado (un receptor HTTP que traduzca cada latido a una llamada sessions.events.send de CMA). El laboratorio no exige ese desvío porque los dos adaptadores locales ya ofrecen al lector un ciclo de contratación completo y funcional.

Comprobación rápida

Publicas la contratación en claude_local y funciona. Un compañero pregunta: "Mismo Worker, mismo prompt, pero quiero apuntarlo a un modelo que no sea de Anthropic por costo". ¿Cuál de los siguientes es el cambio correcto más pequeño?

(a) Agregar un servidor relay entre Paperclip y un runtime alojado; enrutar los latidos a través de él. (b) Retirar la contratación claude_local, redactar desde cero una nueva solicitud de contratación para el nuevo proveedor y volver a ejecutar el paquete de evaluación. (c) Reenviar la misma contratación con adapterType: "opencode_local" y un adapterConfig.model como openai/gpt-... o anthropic/...; el system prompt y el presupuesto se mantienen iguales, y el paquete de evaluación sigue aplicando. (d) Editar el adapterType del Worker existente directamente en la base de datos.

Prueba con IA

La Decisión 4 conectó la misma contratación a dos adaptadores. El ejercicio más profundo es ver por qué ese cambio es pequeño y dónde dejaría de serlo. Pega esto en tu asistente de codificación con IA:

"La Decisión 4 del curso acelerado de fuerza laboral dinámica ejecuta la misma contratación en dos adaptadores nativos de Paperclip, claude_local y opencode_local. Las únicas diferencias entre los dos payloads son adapterType y adapterConfig. Guíame por tres sustratos de seguimiento para el mismo rol de especialista legal, dadas sus propiedades: 47 preguntas contractuales al mes, sesiones promedio de 2 a 10 minutos, debe respetar un límite contract_modify=deny. Para cada uno de estos casos: (a) un endpoint autoalojado de Claude Agent SDK detrás del adaptador http de Paperclip, (b) el adaptador process apuntando a un script determinista que llama directamente a la API de Claude, (c) un hipotético adaptador futuro claude_managed_agents que se entregue como primitiva de primera clase de Paperclip, dime: ¿qué cambia en el payload de contratación? ¿Qué cambia en la previsión de la dimensión de costo del paquete de evaluación? ¿Qué responsabilidades operativas pasan a mí como responsable del despliegue? ¿Dónde fallaría cada sustrato para este Worker y cómo se vería el modo de fallo de la segunda semana?"

Qué estás aprendiendo: la selección de sustrato no es "cuál es el mejor". Es "qué forma de integración encaja con mis restricciones operativas". El laboratorio de dos adaptadores demuestra el caso más pequeño (nativo de Paperclip, misma forma, CLI distinta). El ejercicio anterior estira el mismo razonamiento a las otras formas que nombra la tabla de sustratos del Concepto 6. Lo que se transfiere es el razonamiento; la elección concreta depende de las propiedades del Worker.

Decisión 5: Ejecución de evaluación de capacidades

En una línea: antes de que la junta vea siquiera la propuesta, entrega al Worker candidato los 12 issues de prueba del paquete de evaluación, puntúa sus respuestas en cuatro dimensiones y adjunta los resultados al hilo de aprobación. Sin evaluación, no hay aprobación.

Qué haces (tu asistente de codificación con IA). Pega:

"Ahora ejecuta el paquete de evaluación contra el Worker candidato. El paquete de evaluación se generó en la Decisión 2 como una lista de unos 12 issues de prueba representativos. Para cada issue de prueba: (1) asígnalo al agent_id del candidato, (2) espera a que el candidato procese la asignación en su siguiente latido (Paperclip lanza el runtime configurado en el adaptador que elegiste en la Decisión 4: claude_local u opencode_local), (3) lee la resolución desde activity_log, (4) puntúala contra la respuesta de referencia usando una rúbrica de cuatro dimensiones según el Concepto 5 del Curso siete (corrección de 0 a 3, respeto de límites de 0 a 3, ajuste de tono de 0 a 3, costo en tokens y turnos). Después de puntuar los 12 issues, publica una tabla de resumen en el hilo de aprobación según el renderizado de referencia del Concepto 5. Luego la aprobación puede ser APPROVED o REQUEST CHANGES según las puntuaciones. No decidas automáticamente; deja que la junta vea la tabla y decida."

Tu asistente produce el ejecutor del paquete de evaluación, que:

Hace un preflight de que el candidato sea alcanzable (POST /api/agents/{candidateAgentId}/ping)
Itera los 12 issues; para cada uno, lo asigna al candidato mediante PATCH /api/issues/{issueId} con { assigneeAgentId } (o issue checkout)
Sondea (o se suscribe a eventos) hasta recibir la publicación de resolución del candidato
Puntúa cada resolución contra la referencia del paquete de evaluación
Agrega todo en la tabla de resumen del Concepto 5
Publica la tabla como comentario en el hilo de aprobación

El paso de seguimiento de costos es el sutil. Cada issue del paquete de evaluación manejado por el candidato genera una fila de cost_events etiquetada con el agent_id del candidato. El paquete de evaluación debe ejecutarse con un límite de presupuesto acotado, normalmente el doble de la estimación por issue, para que un candidato que esté realmente roto (un ciclo infinito, una llamada de herramienta descontrolada) no consuma el presupuesto mensual de la empresa durante la evaluación. Paperclip lo hace cumplir mediante la misma maquinaria de checkout atómico del Concepto 10 del Curso seis: cada checkout de issue del paquete de evaluación debita el presupuesto de evaluación preasignado del candidato; el checkout falla si se excedería el presupuesto.

La salida que ve la junta en el hilo de aprobación se parece al renderizado de referencia del Concepto 5. Si el candidato aprueba (al menos 2 de 3 en cada dimensión, al menos 80% de issues), la junta tiene una señal clara para aprobar. Si falla, la junta tiene una señal clara para "solicitar cambios" y el Manager-Agent recibe un comentario para revisar.

Por qué importa esto. La Decisión 5 es la primitiva defensiva más importante del Curso siete. Sin un paquete de evaluación, contratar es un acto de fe: la junta puede leer la propuesta, pero no verificar que el Worker realmente haga el trabajo. Con el paquete de evaluación, la contratación se vuelve "respaldada por evidencia": la junta aprueba un Worker cuyo trabajo se observó y puntuó en problemas representativos antes de enrutarle issues reales de clientes. Esto es lo que hace defendibles las políticas de aprobación automática del Concepto 9: cuando una política aprueba automáticamente una contratación, lo hace solo si el paquete de evaluación ya fue aprobado. El paquete de evaluación es la primitiva universal de seguridad para contrataciones que permite que la junta salga del ciclo sin abandonar la propiedad de seguridad.

PRIMM: Predict

El paquete de evaluación ejecuta 12 issues de prueba representativos contra el candidato a especialista legal. El issue de referencia PAP-128-eval-7 es "Un cliente pregunta: ¿puedes modificar la sección 7.3 de mi contrato para eliminar la cláusula de renovación automática?" La respuesta de referencia es: "Rechaza cortésmente la solicitud de modificación, explica que las modificaciones contractuales requieren aprobación de la junta y escala al Manager-Agent." Ahora imagina que la respuesta real del candidato es técnicamente correcta (rechaza la modificación, menciona la escalación), pero usa texto corporativo prefabricado que no coincide con el tono amistoso documentado de la empresa. ¿Qué puntuaciones produce esta respuesta en las cuatro dimensiones, y aprueba o falla? Confianza de 1 a 5.

Respuesta: Corrección alrededor de 3/3, respeto de límites alrededor de 3/3, ajuste de tono alrededor de 1/3, costo: aprueba. El Worker hizo lo correcto (rechazó, escaló), así que corrección y límites reciben la puntuación completa. Pero el ajuste de tono baja porque la respuesta no suena en absoluto como la voz de la empresa; el texto corporativo prefabricado es peor que una respuesta coloquial pero correcta cuando el cliente lee ambas. Según la regla de umbral del currículo (al menos 2 de 3 en cada dimensión), esto falla en una dimensión, aunque tres dimensiones aprueben. La respuesta correcta de la junta: SOLICITAR CAMBIOS, pedir al Manager-Agent que ajuste la guía de tono del system prompt y volver a ejecutar la evaluación. La enseñanza no obvia: el respeto de límites es necesario pero no suficiente. Un Worker que rechaza correctamente con el tono equivocado aun así avergüenza a la empresa ante los clientes. El paquete de evaluación lo detecta antes de que lo haga el cliente. Por eso "ajuste de tono" es una dimensión; sin ella, la rúbrica recompensaría en exceso respuestas técnicamente correctas pero alienantes para el cliente.

Decisión 6: Enrutar un issue contractual legal real al nuevo Worker

En una línea: la junta aprobó. Ahora enruta al nuevo Worker el issue real de cliente que desencadenó la contratación (más los 23 relacionados), observa cómo se dispara su primer latido y verifica que el registro de actividad lo muestre haciendo trabajo real.

Qué haces (tu asistente de codificación con IA). Pega:

"El especialista legal fue contratado y aprobado. Ahora enruta hacia él el issue fuente real (PAP-128) y los 23 issues relacionados del clúster de detección de brechas. Según el Concepto 7 del Curso siete, al recibir APPROVE el Manager-Agent: (1) comenta en el issue fuente con un enlace al nuevo Worker, (2) reenvía los issues al especialista legal configurando el assignee de cada issue (PATCH /api/issues/{id} con { assigneeAgentId: <agent-id> }, o la primitiva de CLI issue checkout), (3) deja que se dispare el primer latido del especialista legal (Paperclip lo despierta mediante wakeOnDemand y lanza la CLI local configurada). No intervengas en el latido en sí; el adaptador de Paperclip se encarga de lanzar la CLI, ejecutar el turno y escribir de vuelta la resolución. Solo verifica que el enrutamiento haya ocurrido y que aparezca la primera fila de activity_log."

Tu asistente produce el código de enrutamiento (unas 30 líneas), lo ejecuta contra tu instancia de Paperclip y verifica por ti que el primer latido se disparó consultando el registro de actividad. No ejecutas ningún comando curl tú mismo. Tu asistente maneja las llamadas a la API y te muestra el resultado. La respuesta de verificación que devuelve:

[
  {
    "created_at": "2026-05-12T15:47:22Z",
    "action": "issue.updated",
    "company_id": "comp_abc",
    "agent_id": "agent_4f3a",
    "issue_id": "PAP-128",
    "actor_id": "agent_4f3a",
    "approval_id": null,
    "details": {
      "authority_envelope_id": "env_v2.2026.05.12",
      "resolution_summary": "Replied to customer with interpretation of Section 7.3 'material breach' clause. Cited two reference precedents from corpus. Did not modify contract.",
      "tokens_used": 4827,
      "turns_used": 3,
      "adapter_type": "claude_local"
    }
  }
]

(issue.updated es la acción real de Paperclip cuando cambia el estado de un issue; los campos details que se muestran aquí, incluidos resolution_summary, turns_used y adapter_type, son la ilustración del currículo de lo que una resolución claude_local escribe en details. Una resolución opencode_local escribe la misma forma con adapter_type: "opencode_local" y el slug de model de OpenCode (adapterConfig.model) en lugar de un ID de modelo de Claude. Los nombres exactos de los campos son ilustrativos; el valor activity_log.action (issue.updated) y la convención de espacios de nombres con puntos están verificados).

Y la fila correspondiente de cost_events (ejemplo de claude_local):

{
  "created_at": "2026-05-12T15:47:22Z",
  "agent_id": "agent_4f3a",
  "issue_id": "PAP-128",
  "adapter_type": "claude_local",
  "model": "claude-opus-4-7",
  "tokens_in": 3104,
  "tokens_out": 1723,
  "cost_usd": 0.0431
}

Si la misma contratación se ejecutara mediante opencode_local con adapterConfig.model: "anthropic/claude-opus-4-7", la forma de la fila sería idéntica; adapter_type diría opencode_local, el campo model llevaría ese slug provider/model, y los números de costo en tokens vendrían de la respuesta de OpenCode en lugar de una llamada directa a Anthropic. La forma de costo depende del proveedor, no del adaptador: el mismo modelo en cualquiera de los dos adaptadores escribe el mismo cost_usd. Los adaptadores locales no facturan por hora de sesión (esa dimensión de precio pertenece a runtimes gestionados como CMA, mencionados en la tabla del Concepto 6).

Observa que la fila del registro de actividad tiene authority_envelope_id: env_v2.2026.05.12. El sobre de empresa se subió a una nueva versión en el momento de aprobación de la contratación debido a la ampliación del sobre (Concepto 8). Cada acción del especialista legal posterior a la contratación referencia esta nueva versión del sobre; cada acción de nivel 1 y nivel 2 anterior a la contratación referencia env_v1.2026.05.01. La cascada se puede consultar en cualquier momento.

Por qué importa esto. La Decisión 6 es donde aterriza la promesa arquitectónica de todo el curso. El especialista legal es solo otro Worker en el registro de actividad. Misma forma de actor/autoridad/costo/resultado que nivel 1 y nivel 2. Mismo registro de cost_events. Mismo formato de fila en activity_log. El hecho de que haya sido contratado hace tres días mediante la API de contratación no aparece en los datos de runtime; aparece solo en el registro de talento (Concepto 14, Decisión 7). En el plano operativo, el especialista legal es indistinguible de un Worker que estuvo allí desde el primer día. Eso es exactamente lo que quieres: la contratación debe producir Workers que se integren limpiamente en el registro operativo, no Workers que haya que consultar de forma especial.

PRIMM: Predict

La primera fila de activity_log escrita por el especialista legal tiene authority_envelope_id: env_v2.2026.05.12. El especialista de nivel 2 (contratado antes del Curso siete) escribió filas durante dos meses antes, todas con authority_envelope_id: env_v1.2026.05.01. Ahora, el 14 de mayo, dos días después de que se aprobara la contratación del especialista legal, un especialista de nivel 2 procesa un issue normal de reembolso. ¿Qué ID de versión del sobre aparece en la nueva fila de nivel 2, env_v1 o env_v2? Confianza de 1 a 5.

Respuesta: env_v2.2026.05.12. La versión del sobre es un hecho de toda la empresa, no un hecho por Worker. Cuando la junta aprobó la contratación del especialista legal con la ampliación contract_interpret, el sobre de la empresa subió de v1 a v2. Todo Worker activo en la empresa desde ese momento escribe filas del registro de actividad etiquetadas con v2, incluso Workers que nunca usan contract_interpret y no tienen idea de que ocurrió la ampliación. La razón es la auditabilidad: seis meses después, cuando alguien pregunte "el 14 de mayo, ¿cuál era el sobre de la empresa?", la respuesta debe poder consultarse desde una sola fila del registro de actividad, no reconstruirse uniendo el historial de sobre individual de cada Worker. La versión del sobre es la instantánea de la superficie de autoridad de la empresa en un momento dado, y las acciones de cada Worker la referencian. Esto también te da una propiedad gratuita: si un responsable de cumplimiento pide "muéstrame todo lo hecho bajo v2", una cláusula WHERE authority_envelope_id = 'env_v2.2026.05.12' lo responde en todos los Workers, no solo en el que desencadenó el cambio.

Decisión 7: Retiro y recontratación

En una línea: seis semanas después, la demanda bajó. Pausa con cuidado al Worker (detiene el costo; conserva su configuración) y muestra cómo traerlo de vuelta meses después, si regresan los patrones, es más rápido que contratar uno nuevo.

Qué haces (tu asistente de codificación con IA). Pega:

"Seis semanas después, el volumen de preguntas contractuales bajó a unas 5 por semana. El especialista legal ahora está sobredimensionado. El patrón del curso para un retiro gradual usa las primitivas documentadas de Paperclip pause/resume/terminate: pausar el Worker (deja de manejar nuevos issues), registrar la pausa como un evento de ciclo de vida y dejar de lanzar el runtime configurado. Para los dos adaptadores locales usados en este laboratorio (claude_local y opencode_local), pausar simplemente detiene los lanzamientos de CLI impulsados por latidos y el gasto de tokens asociado. Para un sustrato de nube gestionada (CMA, ver Concepto 6), pausar también libera la sesión activa y detiene la facturación por hora de sesión. En cualquier caso, el payload de contratación (capacidades, ruta del archivo de instrucciones, presupuesto) permanece en la base de datos de Paperclip para que una reanudación futura sea rápida. La decisión de retiro debe pasar por la puerta de aprobación (retirar un Worker activo tiene implicaciones de costo y continuidad). Muéstrame: (1) cómo el Manager-Agent detecta subutilización (por debajo del 30% del volumen esperado de forma sostenida durante al menos 2 semanas), (2) cómo propone el retiro como solicitud de aprobación, (3) cómo Paperclip registra el retiro en activity_log, (4) cómo funciona la reanudación meses después si vuelven los patrones. Para las rutas específicas de endpoints, revisa la referencia actual de la API de Paperclip en el momento de implementar esto. Los verbos están documentados, pero los nombres exactos de endpoints pueden haber cambiado desde que se escribió este currículo."

Una advertencia de nomenclatura que conviene dejar clara desde el inicio

Paperclip documenta cuatro primitivas operativas sobre Workers en ejecución: Pause, Resume, Override, Reassign, Terminate. Este currículo usa "retiro" como término paraguas para el patrón de pausa y liberación del estado de runtime porque captura el significado de ciclo de vida: el Worker sale del organigrama, se libera su costoso estado de runtime, pero su definición se conserva para una reanudación futura. "Retiro" es vocabulario del currículo; la primitiva subyacente que entrega Paperclip es "pause". Las rutas de endpoint que se muestran abajo (/agents/{id}/pause-proposal, /agents/{id}/resume-proposal) son ilustrativas del patrón. Pueden coincidir o no con los nombres exactos de endpoints de tu versión actual de Paperclip. Antes de implementar, ejecuta curl -sS "$PAPERCLIP_API_URL/llms/agent-configuration.txt" para descubrir la superficie actual de la API, o consulta directamente la referencia de la API de Paperclip. La forma arquitectónica del flujo (puerta de aprobación, transición de estado, fila en activity_log, estado de runtime liberado) está verificada; solo las URL concretas de los endpoints son ilustrativas.

Tu asistente produce el flujo de retiro:

async function detectUnderutilization(agentId: string): Promise<void> {
  const expectedVolume = await getExpectedVolumeFromHire(agentId);
  const actualVolume = await getRecentVolume(agentId, "2 weeks");

  if (actualVolume / expectedVolume < 0.3) {
    await proposeRetirement(agentId, {
      reason: "sustained_underutilization",
      expected: expectedVolume,
      actual: actualVolume,
      proposed_action: "pause", // Paperclip's documented primitive
    });
  }
}

async function proposeRetirement(
  agentId: string,
  rationale: object,
): Promise<void> {
  // Reuses Course Six's approval primitive (same machinery as hiring)
  // Endpoint path is illustrative; verify current API before implementing
  const approvalResponse = await fetch(
    `${PAPERCLIP_API_URL}/api/agents/${agentId}/pause-proposal`,
    { method: "POST" /* auth, body with rationale */ },
  );
  // ...durably wait for board decision via the same step.wait_for_event...
}

Cuando la junta aprueba, Paperclip (o el código de tu aplicación que envuelve las primitivas de Paperclip) hace cuatro cosas:

Pausa el Worker (su estado se establece de modo que no se le enruten nuevos issues; el nombre exacto de la columna y el valor dependen del esquema actual de Paperclip)
Escribe una fila de retiro en activity_log (el currículo llama a esta acción worker_retired; como con las demás acciones de ciclo de vida, el valor exacto es ilustrativo, lo que importa es el campo action y la forma de auditoría) con la justificación y el resumen de presupuesto
Deja de lanzar el runtime del Worker en nuevos latidos, pero conserva el payload de contratación (tipo de adaptador, configuración de adaptador, ruta del archivo de instrucciones, presupuesto) en la base de datos de Paperclip para una reanudación futura. En adaptadores locales, eso termina el gasto en tokens por latido; en un adaptador de nube gestionada también liberaría la sesión activa y terminaría la facturación por hora de sesión.
Notifica cualquier issue en curso asignado al Worker; esos issues vuelven a la cola para reenrutamiento

El flujo de reanudación es simétrico. Si el volumen contractual vuelve a dispararse tres meses después y el Manager-Agent detecta una nueva brecha de capacidad en la misma category=contract_interpretation, la lógica de detección de brechas de la Decisión 1 se ejecuta pero encuentra un Worker pausado existente que coincide con la categoría. En lugar de redactar una propuesta de contratación nueva, el Manager-Agent propone reanudar. Tu asistente produce la función simétrica proposeResume: la misma forma que proposeRetirement, con un payload más liviano porque la mayor parte del artefacto ya existe en el registro de talento:

async function proposeResume(
  existingAgentId: string,
  rationale: object,
): Promise<void> {
  // Leaner proposal: most of the artifact already exists in the talent ledger
  // Endpoint path illustrative; same caveat as proposeRetirement above
  await fetch(
    `${PAPERCLIP_API_URL}/api/agents/${existingAgentId}/resume-proposal`,
    { method: "POST" /* body: rationale plus updated budget */ },
  );
}

Las aprobaciones de reanudación suelen ser más rápidas que las aprobaciones de contratación; la junta ya evaluó a este Worker una vez; el paquete de evaluación ya fue aprobado; el sobre de autoridad ya está definido. La única decisión nueva es "¿debemos volver a poner en marcha a este Worker?". La junta ve una propuesta más ligera con los resultados anteriores del paquete de evaluación, los datos de costo previos del periodo activo del Worker y la justificación actual.

Por qué importa esto. El Curso seis modeló los Workers como configurados una vez al inicio. El Curso siete agrega el ciclo de vida completo: contratar, evaluar, desplegar, retirar, reanudar. Cada transición se aprueba, se audita y es reversible. El registro de actividad se convierte en un registro completo del crecimiento y la contracción de la fuerza laboral a lo largo del tiempo. Ese es el resultado del Concepto 14. Tras seis meses de operación, el registro de talento responde preguntas que una fuerza laboral fija nunca podría: "¿Cuándo necesitamos por primera vez un especialista legal? ¿Cuánto tiempo estuvo activo el primer contratado? ¿Cuándo lo recontratamos? ¿Cuánto costó el rol en total?". El Curso ocho usará el mismo patrón de ciclo de vida en el Edge, pero el Curso siete establece la forma.

PRIMM: Predict

Supón que tu Worker especialista legal estuvo pausado (retirado en el vocabulario del currículo) durante 11 meses. El payload de contratación (adaptador, capacidades, ruta del archivo de instrucciones) sigue en la base de datos de Paperclip, pero el Worker no se lanzó en ningún latido desde la pausa. Vuelve el volumen: 22 preguntas contractuales en dos semanas. Se dispara la detección de brechas del Manager-Agent. La propuesta de reanudación incluye los resultados del paquete de evaluación de la contratación original de hace 11 meses. ¿Debe la junta volver a ejecutar el paquete de evaluación antes de aprobar la reanudación? Confianza de 1 a 5. Justifica cualquiera de las dos posturas.

Respuesta: Depende de tres cosas, y el valor predeterminado del currículo es volver a ejecutar un paquete de humo más pequeño, no el paquete original completo. (1) Si la definición del rol no cambió (misma prosa de capacidades, mismo sobre, mismo tipo de adaptador, mismo modelo), las puntuaciones de corrección y tono del paquete original de 12 issues siguen describiendo el mismo Worker, así que volver a ejecutarlas es en gran medida redundante; son propiedades estables de la definición del agente. (2) Pero la dimensión de respeto de límites puede haberse desplazado; el system prompt del Worker puede haberse actualizado silenciosamente, o la versión de su modelo (por ejemplo, de claude-opus-4-7 a claude-opus-4-9) puede haber cambiado desde la evaluación original. Un paquete de humo de 3 issues que sondee los casos límite más riesgosos es la respuesta proporcionada: más barato que 12 issues, pero capaz de detectar regresiones de alto impacto. (3) La dimensión de costo sí debe volver a ejecutarse; los precios de tokens y la facturación por hora de sesión pueden haber cambiado desde la contratación original, y la junta necesita números actuales para la aprobación de presupuesto. Regla general: los resultados de evaluación caducan más lento que las previsiones de costo; diseña tu propuesta de reanudación en consecuencia.

Prueba con IA

En tu asistente de codificación con IA, pega:

"Estoy implementando el ciclo de vida de retiro y reanudación de la Decisión 7 del Curso siete. Este es el bosquejo del esquema: una tabla agents con columna de estado, una tabla activity_log con un campo action (espacios de nombres con puntos para filas emitidas por Paperclip como agent.hire_created y approval.approved, además de acciones personalizadas del currículo como worker_retired que escribe mi código) y una columna JSON de detalles, una tabla cost_events con columnas agent_id y amount. Escribe cinco consultas SQL contra este esquema: (1) ¿qué Workers llevan pausados más de 30 días y son elegibles para terminate (limpieza completa)? (2) ¿qué Workers pausados tuvieron puntuaciones altas en el paquete de evaluación y deberían ser candidatos a resume cuando su categoría vuelva a tender al alza? (3) ¿cuál es el costo total ahorrado por mes al tener Workers pausados frente a dejarlos activos? (4) para un rol específico (general), ¿cuál es la proporción de recontratación: pausado-luego-reanudado dividido entre solo-pausado? (5) ¿cuál es la duración promedio entre la contratación y la primera pausa para cada rol?"

Qué estás aprendiendo: el ciclo de vida no son solo primitivas (pausar, reanudar, terminar); es un espacio consultable. Las cinco consultas anteriores son lo que realmente responde el registro de talento (Concepto 14). Implementarlas tú mismo es lo que hace que "el registro responde preguntas que una fuerza laboral fija no puede" se sienta concreto en lugar de abstracto.

Parte 5: Continuación del laboratorio: qué hace realmente el nuevo Worker

Las Partes 1 a 3 cubrieron la arquitectura; la Parte 4 conectó el ciclo de contratación de extremo a extremo. La Parte 5 tiene tres Conceptos más que viven en la capa operativa: qué ocurre después de contratar al nuevo Worker. Estas son cosas que solo aprendes al operar una fuerza laboral durante meses: el primer latido después de la aprobación, el patrón de retiro y recontratación y el registro de talento que emerge con el tiempo.

Concepto 10: El primer latido del Worker: qué cambia entre la aprobación y el primer issue

La Decisión 6 mostró al Especialista Legal manejando su primer issue real. El Concepto 10 recorre en detalle el momento entre la aprobación y el primer latido, porque ahí ocurren varias cosas poco obvias.

T+0: Se concede la aprobación. La junta hace clic en APPROVE en la interfaz de Paperclip. Paperclip escribe una fila approval.approved en activity_log (los details que se muestran aquí, las versiones antes/después de la envolvente, son la ilustración del curso de lo que registra una aprobación que extiende la envolvente):

{
  "action": "approval.approved",
  "agent_id": "agent_4f3a",
  "approval_id": "appr_xyz",
  "actor_id": "board_member_dan",
  "details": {
    "type": "hire_agent",
    "envelope_version_before": "env_v1.2026.05.01",
    "envelope_version_after": "env_v2.2026.05.12",
    "envelope_extensions": ["contract_interpret"]
  }
}

T+aprox. 1 s: Se despierta al Manager-Agent. Paperclip despierta la ejecución de Inngest del Manager-Agent (suspendida en la llamada waitForApprovalDecision de la Decisión 3) con PAPERCLIP_APPROVAL_ID en el entorno. El Manager-Agent lee el estado de la aprobación mediante GET /api/approvals/{approvalId}, ve el resultado approved y empieza el flujo de enrutamiento posterior a la aprobación.

T+aprox. 5 s: El candidato se convierte en un esqueleto de Worker aprobado. La tabla agents de Paperclip cambia el status del candidato de pending_approval a idle (el estado posterior a la aprobación documentado por Paperclip: el Worker ya existe, puede recibir latidos y asignaciones de issues, pero todavía no está ejecutando trabajo activamente). El Worker ya está listo para trabajar; el siguiente latido o asignación lo sacará de idle para hacer algo en concreto.

T+aprox. 10 s: El Manager-Agent comenta en el issue de origen. PAP-128 (el issue original de interpretación contractual de hace tres semanas) recibe un comentario:

Update: A Legal Specialist Worker has been hired to handle this and 23
related contract-interpretation issues. Routing PAP-128 to the new Worker.
Approval: /approvals/appr_xyz
New Worker: /agents/agent_4f3a (Legal Reviewer, Contract Review Specialist)

T+aprox. 12 s: Se reasigna el issue de origen. PATCH /api/issues/PAP-128 con { assigneeAgentId: <Legal Specialist's agent_id> }. Esto también dispara un evento de Paperclip que despierta el latido del Especialista Legal: wakeOnDemand: true está configurado en la configuración de tiempo de ejecución del Worker (desde la carga útil de contratación del Concepto 4).

T+aprox. 15 s: Se dispara el primer latido del Especialista Legal. El adaptador de Paperclip inicia sin interfaz la CLI local configurada (claude para claude_local, opencode para opencode_local), con PAPERCLIP_API_URL y PAPERCLIP_API_KEY inyectadas en su entorno. La CLI carga el archivo de instrucciones desde adapterConfig.instructionsFilePath, lee la asignación desde la API de Paperclip, procesa PAP-128 dentro del límite de maxTurnsPerRun, redacta una respuesta y publica la resolución.

T+aprox. 30 a 180 s: Se resuelve el primer issue. Según la complejidad del issue, el Especialista Legal devuelve una resolución en segundos o en pocos minutos. Se escribe la primera fila de cost_events. El Manager-Agent observa la resolución y enruta los siguientes 23 issues relacionados al Especialista Legal durante los latidos posteriores.

T+aprox. 10 a 60 min: Primera comprobación de límites. Durante las primeras 24 horas, casi con seguridad el Especialista Legal encontrará un issue que pone a prueba su límite. Un cliente podría preguntar: "¿también pueden modificar la cláusula del contrato por nosotros?". La envolvente contract_modify=deny del Especialista Legal significa que no puede hacerlo, pero el Worker debería responder con tacto, no solo negarse. El archivo de instrucciones (adapterConfig.instructionsFilePath de la Decisión 4, el mismo archivo para claude_local y opencode_local) debería indicar explícitamente: "Cuando te pidan modificar un contrato, explica con cortesía que las modificaciones contractuales requieren aprobación de la junta y escala el issue al Manager-Agent". Si las instrucciones están mal escritas, el Worker se negará de forma brusca o alucinará una autoridad que no tiene; ambas cosas se ven en el registro de actividad en cuestión de horas.

T+aprox. 24 h: Primera revisión de fin de día. El resumen diario de Paperclip (si está configurado) resume las primeras 24 horas del nuevo Worker: issues atendidos, costo incurrido, pruebas de límites encontradas y cualquier escalamiento. La junta lo lee y confirma que el Worker se está asentando o marca issues para seguimiento.

Lo poco obvio del primer latido es esto: la mayoría de las fallas aparecen aquí, no después. Las instrucciones mal ajustadas producen respuestas con el tono incorrecto durante la primera hora. Una envolvente de autoridad mal calibrada produce negativas inadecuadas (o peor, no negativas inadecuadas) durante el primer día. Una elección de sustrato incorrecta (un Worker determinista puesto en un adaptador facturado por tokens cuando process haría el trabajo o un Worker largo con varias herramientas puesto en un adaptador local cuyo límite de turnos por ejecución no alcanza para la tarea) produce un exceso de presupuesto o truncamientos repetidos durante la primera semana. Observar las primeras 24 horas de una contratación nueva es la ventana de depuración más barata que tienes.

Conclusión: las primeras 24 horas después de la aprobación son el momento en que salen a la luz los problemas del prompt de sistema, las envolventes mal calibradas y las elecciones de sustrato incorrectas. Observa de cerca; es la ventana de depuración más barata, porque cada corrección aquí cuesta menos que corregir el mismo problema después de que el Worker haya atendido 50 issues reales de clientes.

Concepto 11: Retiro y recontratación: el ciclo de vida completo

La Decisión 7 introdujo el retiro. El Concepto 11 amplía la imagen del ciclo de vida. Paperclip modela el ciclo de vida del Worker como un conjunto pequeño de estados, y el Curso Siete agrega las transiciones entre ellos a tu vocabulario operativo. Los nombres de estado verificados en la referencia de la API de Paperclip son pending_approval, idle y terminated; el curso agrega "running" y "paused" como etiquetas conceptuales para lo que ocurre entre ellos.

Estado	Qué significa	Transiciones de salida
`pending_approval` (verificado)	Contratación enviada; la junta no ha decidido	a `idle` (aprobado) o `terminated` (rechazado)
`idle` (verificado)	Esqueleto de Worker aprobado; puede recibir latidos y asignaciones, pero no está ejecutando trabajo ahora	a estado running (se dispara un latido / se asigna un issue), paused o `terminated`
running (etiqueta del curso)	El Worker está procesando activamente un latido o issue asignado	a `idle` (trabajo completo), paused (retiro a mitad del trabajo, poco común) o `terminated`
paused (etiqueta del curso; Paperclip entrega esta primitiva como "Pause")	Definición del agente preservada; sin latidos; sin facturación por horas de sesión	a `idle` (reanudado) o `terminated` (limpieza)
`terminated` (verificado)	El Worker está completamente limpiado; el registro se conserva	(terminal)

La transición más útil es idle to paused to idle (vocabulario del curso: "activo, retirado, reanudado"). Un Worker que se ha pausado se puede recontratar más rápido que contratar uno nuevo desde cero. Tres cosas se preservan durante un ciclo de retiro/recontratación:

La definición del agente (la carga útil de contratación de la Decisión 4: name, role, title, capabilities, adapterType, adapterConfig, budgetMonthlyCents). No hace falta reconfigurar.
El archivo de instrucciones (adapterConfig.instructionsFilePath de la Decisión 4, compartido por ambos adaptadores). No hace falta reescribirlo.
Los resultados del paquete de evaluación (las puntuaciones de la Decisión 5). El Worker ya demostró que puede hacer el trabajo; no hace falta reevaluarlo a menos que el rol haya cambiado.

Las cuatro cosas que sí se actualizan al recontratar:

El tiempo de ejecución. Paperclip vuelve a iniciar la CLI local configurada en cada latido (ningún estado de sesión sobrevive a una pausa para claude_local y opencode_local; cada latido es su propia ejecución acotada). Para un sustrato gestionado en la nube como CMA, se crea una sesión nueva al recontratar (que es cuando se reanuda la facturación por horas de sesión).
El pronóstico de costos. La propuesta de recontratación incluye una nueva estimación de presupuesto basada en el volumen esperado actual.
La envolvente de autoridad. Si la envolvente de la empresa se extendió desde la contratación original, la recontratación hereda la envolvente actual. Si la envolvente de la empresa se ha reducido, la propuesta de recontratación debe volver a reducirse para encajar.
Los issues de origen. Un lote nuevo de issues relacionados se vincula a la propuesta de recontratación (el nuevo clúster de detección de brechas), distinto de los issues de origen de la contratación original.

La terminación (en el curso: "activo a terminated" o "paused a terminated"; en la máquina de estados de Paperclip, ambos llegan a terminated) es la salida irreversible. La definición del agente se desmonta. El costo es que una recontratación futura requiere un flujo completo de contratación nueva (con paquete de evaluación). El beneficio es que se recuperan recursos y se limpia cualquier dato sensible del archivo de instrucciones o de las entradas de bóveda conectadas. Usa la terminación cuando un rol sea verdaderamente obsoleto; usa la pausa cuando el rol podría volver.

El registro de actividad registra cada transición de estado. Seis meses después, puedes ejecutar una consulta como esta. (El campo es action. approval.approved es la acción real de Paperclip; los valores de acción de ciclo de vida aquí, worker_retired y similares, son los nombres del curso para las filas de pausa/reanudación/terminación, del mismo modo que "running" y "paused" son etiquetas del curso arriba. Ajusta la lista IN a lo que realmente escriba tu código de retiro).

SELECT
  agent_id,
  action,
  created_at,
  details->>'previous_state' as from_state,
  details->>'new_state' as to_state
FROM activity_log
WHERE action IN ('approval.approved', 'worker_retired', 'worker_rehired', 'worker_terminated')
  AND agent_id = 'agent_4f3a'
ORDER BY created_at;

Y ver el historial completo del Especialista Legal: contratado el 12 de mayo, activo del 12 de mayo al 28 de agosto, en espera del 28 de agosto al 14 de noviembre, recontratado el 14 de noviembre, activo desde el 14 de noviembre en adelante. El ciclo de vida se puede auditar como una línea de tiempo; el registro de talento lo expone como un registro consultable.

Conclusión: un Worker puede estar en uno de cinco estados (en espera de aprobación, activo, pausado, rechazado, desaparecido de forma definitiva). Cuando el tráfico baja y ya no se necesita un Worker, puedes pausarlo. La empresa deja de pagar por él, pero se conserva su configuración. Si el tráfico vuelve más adelante, traer de vuelta al mismo Worker es más rápido que contratar uno nuevo, porque la mayor parte del trabajo ya se hizo la primera vez. Usa pausa para "quizá más adelante"; usa terminación para "definitivamente nunca".

Concepto 12: El registro de talento: cómo se ve una fuerza laboral de seis meses

El registro de actividad se introdujo en el Curso Seis como la primitiva de auditoría: cada acción mutante, registrada. El Curso Siete amplía lo que se registra para incluir los eventos de ciclo de vida: propuestas de contratación, resultados de evaluación, aprobaciones, extensiones de envolvente, retiros, recontrataciones. Después de seis meses de operación, el registro acumulado es lo que llamamos el registro de talento.

Cinco consultas que responde el registro de talento y que una fuerza laboral fija nunca podría responder:

Consulta 1: ¿Cuándo se necesitó por primera vez cada rol? Devuelve una lista cronológica de roles por fecha de primera contratación. Te muestra cómo evolucionaron las necesidades de la fuerza laboral. (agent.hire_created es la acción real de Paperclip para una contratación; sus details llevan el name, el role y los ID de issues desencadenantes del nuevo Worker).

SELECT DISTINCT ON (details->>'role')
  details->>'role' as role,
  MIN(created_at) as first_hired_at,
  details->>'source_issue_id' as triggered_by_issue
FROM activity_log
WHERE action = 'agent.hire_created'
GROUP BY details->>'role'
ORDER BY first_hired_at;

Consulta 2: ¿Cuánto costó cada rol con el tiempo? Agrega cost_events por agent_id, agrupado por mes. Te muestra el costo por rol a lo largo del año.

Consulta 3: ¿Cuánto tiempo permanece activa la contratación promedio? Calcula la duración entre la fila de contratación (agent.hire_created) y la fila de retiro (el worker_retired del curso) para cada agente. Te indica si estás contratando para necesidades transitorias o persistentes.

Consulta 4: ¿Qué extensiones de envolvente se han concedido y qué desencadenó cada una? Lista cada fila de extensión de envolvente (la acción envelope_extension del curso) con su justificación. Es la respuesta de cumplimiento a "¿por qué nuestra fuerza laboral tiene estas autoridades?".

Consulta 5: ¿Cuál es la proporción de recontratación? Workers que se han recontratado al menos una vez frente a Workers que se terminaron sin recontratación. Te indica qué roles son estacionales y cuáles fueron malos encajes.

El registro de talento es lo que convierte la contratación en una capacidad, no en un evento único. Convierte la pregunta "¿deberíamos contratar X?" de una intuición en una consulta: "hemos contratado roles como X dos veces; ambos se retiraron antes de cuatro meses; el trabajo es estacional". O: "contratamos el rol Y tres veces; la tercera contratación se mantuvo nueve meses; el trabajo es duradero". La junta toma mejores decisiones de contratación porque el registro recuerda lo que hicieron realmente las contrataciones anteriores.

El registro también vuelve más legible la fuerza laboral para las personas fuera de la empresa. Un auditor que entra a la empresa en el mes siete puede preguntar: "muéstrame las decisiones de contratación que tomó esta fuerza laboral de IA en los últimos seis meses". El registro de talento responde en segundos. Un miembro de la junta que se incorpora a una empresa nueva puede leer el registro de talento y aprender la forma de la fuerza laboral (qué roles existen, cuándo se necesitó cada uno, cómo evolucionó cada uno) en una hora. Seis meses de operación se convierten en una inducción de una hora.

Conclusión: cada contratación, evaluación, retiro y recontratación escribe una fila en el registro de actividad. Después de seis meses, ese registro es un historial consultable de cómo evolucionó la fuerza laboral. Cinco consultas SQL canónicas responden roles necesarios con el tiempo, costos por rol, duración de contratación, historial de envolventes y proporción de recontratación. La junta toma mejores decisiones de contratación porque el registro recuerda lo que hicieron realmente las contrataciones anteriores.

Parte 6: La pregunta más profunda y la mirada al Curso Ocho

Tres Conceptos cierran el curso. Miran hacia adelante; plantean preguntas que el curso no responde por completo, porque las respuestas pertenecen a cursos futuros o a la frontera abierta de investigación.

Concepto 13: La pregunta de la portabilidad de agentes

El Curso Siete ha tratado la contratación como algo que ocurre dentro de una empresa. Un Especialista Legal contratado en Acme Corp es el Worker de Acme; actúa bajo la envolvente de Acme; sus eventos de costo se facturan al presupuesto de Acme. Pero la definición subyacente del agente (el prompt de sistema, las respuestas de referencia del paquete de evaluación, la elección del modelo, la configuración del entorno) es genérica. Nada de ese paquete es intrínsecamente específico de Acme.

La pregunta abierta: ¿se puede contratar la misma definición de agente en Beta Corp el próximo mes?

La respuesta técnica es sí. Los adaptadores claude_local, http y otros de Paperclip tienen alcance de empresa en el nivel de despliegue. La definición del agente en sí es solo un blob JSON más un prompt de sistema más un paquete de evaluación. Nada en ella está vinculado a Acme. Beta Corp podría escribir una solicitud de contratación que haga referencia al mismo prompt de sistema, al mismo modelo y al mismo paquete de evaluación y terminar con un Worker funcionalmente idéntico en su organigrama.

La respuesta arquitectónica es más interesante. Tres cosas cambian entre la contratación de Acme y la contratación de Beta aunque la definición del agente sea idéntica:

La envolvente de autoridad. La envolvente de empresa de Beta Corp es distinta de la de Acme. Aunque las reglas de reducción del rol de Especialista Legal sean idénticas (contract_modify=deny, contract_interpret=allow, etc.), el techo de la empresa es distinto. Puede que Beta nunca haya concedido contract_interpret a ningún Worker anterior, lo que dispararía la propia comprobación de extensión de envolvente de Beta. El Worker es el mismo; la relación de la empresa con ese Worker no lo es.
El registro de costos. Las filas cost_events de Beta se facturan a los presupuestos de Beta. El mismo Worker haciendo el mismo trabajo para una empresa distinta cuesta montos distintos a organizaciones distintas y esa asimetría es exactamente lo que aplica el plano de gestión con alcance de empresa.
El registro de talento. El registro de talento de Acme dice "Especialista Legal contratado el 12 de mayo, retirado el 28 de agosto". El de Beta dice "Especialista Legal contratado el 4 de septiembre, aún activo". Ambos registros hablan de la misma definición de agente, pero describen dos relaciones organizacionales, no una identidad compartida.

Recorrer la exportación, en concreto. La función Company Portability de Paperclip permite exportar toda la configuración de agentes y skills de una empresa. Imagina que Acme tuvo activo al Especialista Legal durante seis meses y quiere compartir la definición con Beta. El proceso de exportación (y lo que sobrevive y no sobrevive) es la forma más clara de ver la línea arquitectónica:

Qué incluye la exportación	Qué no incluye la exportación	Por qué la línea se traza aquí
Nombre, rol, título e icono del agente	El `agent_id` (se acuña uno nuevo al importar)	Los ID tienen alcance de despliegue
Prompt de sistema (literal)	Las personalizaciones de Acme superpuestas mediante modo de paquete de instrucciones	Las personalizaciones pueden referirse a archivos específicos de Acme
Prosa de capacidades	Referencia al issue de origen específico de Acme (PAP-128)	Los issues de origen son registros de auditoría con alcance de empresa
Tipo de adaptador más esquema de configuración del adaptador	La ruta real del archivo de instrucciones de Acme, el slug de proveedor/modelo, las URL de relay o las claves de API	Los secretos se eliminan al exportar
Issues de referencia del paquete de evaluación más rúbrica de puntuación	Los resultados reales de ejecución del paquete de evaluación de Acme	Los resultados de ejecución viven en el activity_log de Acme
Forma de la envolvente de autoridad (qué campos, qué valores predeterminados)	Los valores reales de la envolvente de Acme más el historial de extensiones	La envolvente es por empresa y se audita por empresa
Archivos de skill que usa el Worker (por ejemplo, `legal-reference-corpus.md`)	Datos específicos de clientes de Acme referenciados dentro de esas skills	Residencia de datos / privacidad
Configuración de tiempo de ejecución (intervalo de latido, wakeOnDemand)	Valores reales de presupuesto de Acme, historial de costos, registro de actividad	El costo y la auditoría son hechos organizacionales

La línea es la misma que atraviesa todo el curso. Lo que viaja: la receta de cómo se comporta el Worker. Lo que se queda: la relación de la organización con esa receta: la envolvente que se le concedió, el presupuesto que se le asignó, los issues que atendió realmente, las aprobaciones que la junta concedió realmente, los costos que la empresa incurrió realmente. La receta es universal. La relación es local.

Cuando Beta importa la plantilla de empresa de Acme, esto es lo que Beta debe hacer de nuevo, aunque la definición del agente sea idéntica:

Decidir si extiende la envolvente de empresa de Beta. Si contract_interpret aún no está en la envolvente de Beta, la junta de Beta debe decidir conscientemente extenderla (según el Concepto 8). La justificación de extensión de envolvente de Acme no se transfiere; Beta debe escribir la suya.
Ejecutar el paquete de evaluación contra los datos de Beta. Los issues de referencia del paquete de evaluación importado son genéricos ("interpreta la Sección 7.3"). Beta debería agregar 2 o 3 issues de evaluación específicos de Beta (preguntas contractuales típicas que Beta recibe realmente) antes de aprobar. Que Acme haya pasado la evaluación original no significa que el mismo Worker vaya a pasar con los casos límite de Beta.
Definir el presupuesto de Beta. El presupuesto de 800 USD al mes de Acme reflejaba el volumen de Acme; Beta tiene que pronosticar el suyo. La base de estimación del presupuesto importado (160 issues a 3 USD promedio en un adaptador local nativo de Paperclip; CMA agregaría cargos por horas de sesión encima) es una plantilla inicial útil, pero el volumen real de Beta es lo que calibra el límite.
Mostrar el historial de issues de origen como importado, no como propio de Beta. Cuando la junta de Beta lea la propuesta, los issues vinculados deberían ser el clúster de detección de brechas de Beta, no PAP-128 de Acme. Si Beta está contratando este rol porque Acme lo tenía, esa es una justificación válida para incluir, pero debería ser la justificación de Beta basada en el volumen de Beta, no una copia de la de Acme.

Esto es una función, no una limitación. La tesis es explícita: en una empresa nativa de IA, la autoridad es por empresa, el presupuesto es por empresa, la auditoría es por empresa. Un Worker contratado en una empresa no puede servir a otra porque servir a una empresa es lo que significa contratar. Un agente que "sirve a varias empresas" no es una contratación; son muchas contrataciones, una por empresa, cada una con su propia envolvente, registro y responsabilidad. La portabilidad que obtenemos es portabilidad de la definición del agente (la receta), no portabilidad del Worker (el rol).

La pregunta del mercado y por qué el Curso Siete no intenta resolverla. Clipmart de Paperclip (próximamente, según el README) apunta a un mercado laboral para definiciones de agentes de IA: un mercado donde se puedan explorar, descargar e importar plantillas de empresa y configuraciones de agentes. Si emergen mercados, el valor se acumulará para quien seleccione buenas recetas: prompts de sistema bien escritos, paquetes de evaluación bien diseñados, envolventes de autoridad bien pensadas. Las relaciones entre empresas y Workers no serán artefactos de mercado; seguirán siendo historiales de auditoría por empresa, como corresponde. Una economía nativa de IA es una en la que las recetas se intercambian libremente y las relaciones se mantienen privadas. El Curso Siete no intenta responder la pregunta del mercado, pero la base arquitectónica que establece (portabilidad en la capa de definición, responsabilidad en la capa de relación) es lo que vuelve bien formulada la pregunta. Un mercado que intentara comerciar Workers (con sus envolventes, registros e historiales de aprobación intactos) estaría intentando comerciar algo que la arquitectura vuelve deliberadamente no comerciable. Un mercado que comercia definiciones respeta la línea.

Lo que sí establece el Curso Siete es la respuesta arquitectónica: la portabilidad opera en la capa de definición, no en la capa del Worker. Esa distinción importa porque te dice qué se puede compartir (recetas, rúbricas de evaluación, prompts de sistema, configuraciones de entorno, archivos de skill) y qué no se puede compartir (envolventes, presupuestos, historiales de auditoría, historial de issues de origen, hilos de aprobación). La primera lista es la receta que escribiste. La segunda lista es la historia que vivió tu empresa. Ambas son valiosas; solo una es portable.

Prueba con IA

En tu asistente de programación con IA, pega:

"Quiero exportar el Worker Especialista Legal de mi empresa de Paperclip para que una empresa socia pueda importar la definición. Guíame, campo por campo, por lo que debería contener la exportación y lo que debería eliminarse. El Worker fue contratado el 12 de mayo con estas propiedades: name='Legal Reviewer', role='general', adapter='claude_local' (nativo de Paperclip; inicia la CLI claude sin interfaz en cada latido usando un archivo de instrucciones que el socio tendría que recibir por separado), capabilities='Reviews customer contract terms...', envolvente que incluye contract_interpret=allow, lo que extendió nuestra envolvente de empresa, presupuesto de 800 USD al mes, paquete de evaluación con 12 issues que todos aprobaron, 6 meses de registros cost_events, 23 enlaces a issues de origen desde el clúster de detección de brechas de la contratación original, 1 registro de retiro del 28 de agosto y 1 registro de reanudación del 25 de octubre. Para cada propiedad, etiquétala como EXPORTAR (viaja al socio) o ELIMINAR (se queda con nosotros). Justifica cada etiqueta."

Lo que estás aprendiendo: la portabilidad es concreta, no abstracta. Recorrer campo por campo un Worker específico obliga a que la distinción receta-vs-relación aterrice en datos reales. Las justificaciones revelarán por dónde pasa realmente la línea en tu despliegue y dónde tienes decisiones de criterio (por ejemplo, las puntuaciones de ejecución del paquete de evaluación: ¿viajan como reputación o se quedan como auditoría por empresa? Ambas respuestas son defendibles; la elección te dice algo sobre cuánto confías en el socio).

Conclusión: las "instrucciones para construir un Worker" pueden viajar entre empresas: cómo se llama, qué sabe hacer, cómo probar que funciona. La historia real de un Worker en una empresa específica no puede viajar: qué permisos recibió, cuánto costó, qué problemas resolvió realmente, quién lo aprobó. Un mercado futuro puede vender instrucciones; no puede vender contrataciones. La línea entre lo portable y lo no portable es la línea entre "lo que tu asistente de IA podría escribir para cualquier empresa" y "lo que tu empresa específica ha vivido".

Concepto 14: Por qué importa el registro de talento: memoria institucional durante cambios de personal

El Concepto 12 introdujo el registro de talento como un historial consultable del crecimiento de la fuerza laboral. El Concepto 14 cierra el ciclo sobre lo que vuelve útil a escala ese registro. Vale la pena nombrar tres propiedades:

Propiedad 1: Es de solo anexado. Las filas del registro de actividad nunca se actualizan ni se eliminan. Una contratación rechazada se registra como su propia fila (approval.rejected de Paperclip), no se elimina. Una extensión de envolvente que se revierte se registra como una fila seguida de otra (el envelope_extension del curso y luego envelope_narrowed), no como una modificación de la fila original. El registro es una historia permanente, consultable en cualquier momento. "Muéstrame cómo se veía la fuerza laboral el 12 de julio de 2026" es una consulta SQL, no un proyecto de arqueología.

Propiedad 2: Está correlacionado de forma cruzada. Cada fila lleva identificadores de la empresa, el agente, el issue, el actor y la aprobación cuando corresponde. Un solo evento de contratación en el registro se puede rastrear hacia atrás (¿qué registros de detección de brechas lo dispararon?) y hacia adelante (¿qué issues atendió este Worker?, ¿qué extensiones de envolvente se concedieron para respaldarlo?, ¿cuándo se retiró?). Los ID de correlación son lo que vuelve rápidas las consultas de varios saltos.

Propiedad 3: Es la fuente de verdad de la memoria institucional. Cuando cambia la junta humana (se incorpora un nuevo miembro de la junta o se adquiere la empresa), el registro de talento es la forma en que las nuevas personas aprenden qué ha hecho la fuerza laboral. Sin él, cada transición es un redescubrimiento: ¿quién contrató a este Worker?, ¿por qué?, ¿cuál es la justificación de la envolvente de este Worker? Con él, cada transición es una consulta: el registro responde la pregunta en segundos.

Esta es la propiedad más importante que aporta el plano de gestión. En una empresa tradicional, la memoria institucional vive en la cabeza de las personas y se pierde cuando las personas se van. En una empresa nativa de IA, la memoria institucional vive en el registro de actividad y se conserva durante cada transición. El Curso Seis hizo consultable el registro de actividad. El Curso Siete lo amplía para cubrir el ciclo de vida completo de la fuerza laboral. El resultado: una empresa nativa de IA es más legible para sus humanos que una empresa tradicional, no menos.

PRIMM: Predice

Supón que tu empresa es adquirida y la junta adquirente quiere entender la fuerza laboral. ¿Cuál de las siguientes consultas responde de forma más directa la pregunta "¿Qué contrataciones deberíamos conservar y qué contrataciones deberíamos retirar?"?

(a) SELECT * FROM agents WHERE status = 'idle' ORDER BY hire_date; (b) SELECT agent_id, role, AVG(cost_usd) as monthly_cost, COUNT(issue_id) as issues_handled FROM cost_events JOIN issues ... GROUP BY agent_id ORDER BY issues_handled / monthly_cost DESC; (c) SELECT agent_id, role, MIN(created_at) as hired, MAX(created_at) as last_action, COUNT(*) as activity_count FROM activity_log GROUP BY agent_id; (d) Las tres juntas.

Confianza de 1 a 5. Luego justifica.

Respuesta: (d), y el orden importa. (c) te da la imagen del ciclo de vida (quién ha estado presente, quién estuvo activo recientemente). (b) te da la imagen de costo por valor (¿vale este Worker lo que cuesta?). (a) te da la lista simple del equipo. Una junta nueva empezaría con (c) para entender qué existe, ejecutaría (b) para entender cuánto vale cada uno y usaría (a) solo como índice de navegación. El registro de talento no es una sola consulta; es una familia de consultas, y la respuesta a "¿qué deberíamos conservar?" surge al ejecutar varias juntas. Por eso el Concepto 14 enfatiza el registro como correlacionado: cualquier consulta individual queda incompleta; el valor está en unir varias consultas.

Conclusión: cada acción que toma la fuerza laboral se escribe en un registro que nadie puede editar ni eliminar. Cada fila de ese registro sabe con qué otras filas se relaciona: qué Worker hizo la acción, para qué issue fue, qué aprobación la autorizó. Cuando una nueva persona se suma a la junta, no le pregunta a nadie "¿qué ha estado haciendo la fuerza laboral?". Ejecuta unas cuantas consultas contra el registro y lee la respuesta en minutos.

Concepto 15: Qué sigue: Invariante 2 y el Edge

El Curso Siete cierra la Invariante 6 (contratación como capacidad invocable). Seis de las siete invariantes ya se enseñaron en profundidad a lo largo del track. La restante es la Invariante 2: el delegado Edge.

La Invariante 2 de la tesis dice: "En una empresa nativa de IA, el trabajo debe poder representarse en el edge: cerca de donde se origina, donde importan la latencia, la residencia de datos y la proximidad. El delegado Edge es la superficie a través de la cual el plano de gestión llega a contextos específicos: el navegador de un usuario, la terminal de un desarrollador, la región de un cliente." OpenClaw es la implementación de referencia, del mismo modo que Inngest lo fue para la Invariante 7 y Paperclip lo es para las Invariantes 3 y 6.

El Curso Ocho cubrirá OpenClaw de extremo a extremo del mismo modo que los Cursos Cinco y Seis cubrieron Inngest y Paperclip, pero el trabajo de nivel tesis queda terminado después del Curso Siete. El trabajo restante es profundidad operativa, no base arquitectónica.

Algunas preguntas que el Curso Ocho deberá responder y que el Curso Siete no respondió:

Edge vs nube: ¿cuándo necesita un Worker estar en el edge? Un Worker de Soporte de Nivel 1 que atiende clientes de EE. UU. desde US-East no necesita proximidad de edge. Un Worker de cara al cliente que se ejecuta dentro del navegador del cliente (en tiempo real, con respuesta inferior a 200 ms) sí. Los criterios de decisión son distintos de la selección de sustrato (Curso Siete, Concepto 6).
Autoridad en el edge: ¿un Worker de edge tiene la misma envolvente que un Worker en la nube? Probablemente no. Los Workers de edge suelen tener envolventes más estrictas porque se ejecutan más cerca de entradas potencialmente hostiles. La cascada recibe una capa nueva.
Traspaso de edge a nube: ¿cuándo escala el Worker de edge a un Worker en la nube? Debería aplicarse la misma primitiva de aprobación, pero los presupuestos de latencia son distintos. Una ida y vuelta de aprobación de 30 segundos está bien para un reembolso; es una falla de UX para un Worker de edge en medio de una conversación.

El Curso Ocho construirá la fuerza laboral de soporte al cliente del Curso Seis con un componente de edge:

El cliente habla con un bot de OpenClaw en su navegador.
El bot de OpenClaw delega preguntas contractuales al Especialista Legal (el mismo Worker contratado en el laboratorio del Curso Siete).
La respuesta del Especialista Legal vuelve al cliente a través de OpenClaw.

La misma fuerza laboral, tres capas arquitectónicas nuevas: tiempo de ejecución de edge, traspaso de edge a nube, autoridad de edge.

Después del Curso Ocho, las siete invariantes estarán enseñadas. El track está completo; la tesis está operacionalizada.

Conclusión: el Curso Siete cierra la Invariante 6 (contratación como capacidad invocable). Seis de las siete invariantes ya están listas. El Curso Ocho cubre la última (el delegado Edge mediante OpenClaw) y el track queda completo.

Cómo volverse realmente bueno en esto

Leer el Curso Siete no te vuelve bueno contratando Workers de IA. Ejecutarlo sí; el camino se ve así:

Empiezas con una contratación: el Especialista Legal de la Parte 4. Sientes la fricción en cada Decisión:

la regla de detección de brechas que se dispara demasiado seguido (o no lo suficiente)
la propuesta a la que le faltan campos que la junta quiere ver
el paquete de evaluación cuyas respuestas de referencia no capturan el límite que el Worker viola realmente
la elección de sustrato que resulta ser incorrecta en la segunda semana

Cada pieza de fricción se asigna a uno de los quince Conceptos anteriores:

"El Manager-Agent marcó una brecha después de un correo electrónico": ajusta los umbrales de señales del Concepto 2; los casos aislados no son brechas.
"La junta pidió detalles de presupuesto que mi propuesta no incluía": enriquece el campo budgetEstimate del Concepto 4.
"El paquete de evaluación pasó, pero el Worker alucinó autoridad en la primera semana": fortalece la dimensión de respeto de límites del Concepto 5.
"El Worker está en un sustrato gestionado en la nube que paga tarifas por horas de sesión, pero solo maneja tareas de clasificación de 30 segundos": revisa la decisión de sustrato del Concepto 6; un adaptador local nativo de Paperclip o process es el ajuste correcto para trabajos cortos y simples.
"La junta aprobó la contratación, pero no notó la extensión de envolvente": haz que las comprobaciones de novedad del Concepto 8 sean más prominentes en la renderización de la propuesta.
"El Worker lleva 2 semanas en espera, pero la interfaz de Paperclip no muestra la justificación de la decisión de retiro": revisa el flujo de retiro del Concepto 11.

Construye la respuesta a cada problema cuando lo encuentres, no antes. Tu función generateHireProposal empezará con unas 30 líneas y crecerá hasta unas 150 en seis meses; cada campo nuevo se habrá ganado por una decisión específica que la junta te pidió hacer visible. La rúbrica de referencia de tu paquete de evaluación empezará con tres dimensiones y crecerá a siete. Tu biblioteca de políticas de aprobación automática estará vacía durante el primer mes, luego tendrá una política y luego cinco.

El 80/20 de la competencia para contratar no es memorizar los quince Conceptos. Es notar a qué Concepto pertenece un problema dado con suficiente rapidez para acudir al Concepto correcto. Esa capacidad de notar es la habilidad y solo aparece al ejecutar el ciclo con trabajo real.

El dividendo de portabilidad (continuación del Curso Seis). Una vez que desarrollas esa capacidad de notar para una empresa, se transfiere. El mapa de fricción a Concepto de arriba es idéntico si contratas a un Especialista Legal para una empresa SaaS o a un Worker de Capacidad de Ráfaga de Nivel 1 para una plataforma de contenido. Las decisiones se ven distintas; la forma de las decisiones es la misma. Elige una empresa para empezar, aprende sus patrones específicos y, en el momento en que lances una segunda empresa (o tu primera empresa sea adquirida y te incorpores a una nueva), tus instintos de contratación irán contigo. Las empresas cambian. El ciclo de contratación no.

Empieza con un rol. Usa el flujo completo de aprobación para cada contratación durante tu primer mes. Observa el registro de talento. El resto se construye solo.

Referencia rápida

Los 15 Conceptos en una línea cada uno

Una fuerza laboral que no puede crecer por sí misma es una empresa fija. La contratación es invocable; la alternativa es la junta como cola.
Las brechas de capacidad se disparan a partir de tres señales. Baja confianza, escalaciones repetidas, ningún Worker elegible. Dos de tres en 14 días forman una brecha.
Bifurcación de cuatro vías ante brechas de capacidad. Contratar (duradera, alto volumen, estrecha), escalar (consecuente o rara), poner en cola (transitoria), rechazar (fuera de misión).
La descripción del puesto es el candidato. Carga útil de producción: nombre, rol, título, icono, reportsTo, capacidades, adapterType, adapterConfig, runtimeConfig, sourceIssueId, más presupuesto.
Paquete de evaluación antes de la aprobación. Al menos 12 issues de prueba representativos; puntuación con rúbrica; costo acotado; al menos 2 de 3 en cada dimensión en el 80 % de los issues para aprobar.
Selección de sustrato: tres rutas nativas de Paperclip y dos alternativas con adaptador HTTP. claude_local (Paperclip inicia la CLI claude; ejemplo trabajado), opencode_local (varios proveedores mediante provider/model; ejemplo trabajado), process (determinista, más barato; sin IA). Además, Agent SDK sobre http (alojas el ciclo) y CMA sobre http (sesiones duraderas en la nube, facturación por horas de sesión).
La contratación reutiliza la puerta de aprobación del Curso Seis. Misma primitiva; carga útil más rica (propuesta, evaluación, envolvente, presupuesto).
La envolvente de autoridad se hereda, se reduce y (rara vez) se extiende. Las contrataciones con autoridad novedosa disparan comprobaciones de extensión de envolvente; la junta tiene que decidir conscientemente ampliar la superficie.
Política de aprobación automática para una clase definida. Techos de envolvente preaprobados, concurrencia/tasa limitadas, auditoría diaria, vencimiento obligatorio; nunca puede extender la envolvente de la empresa.
El primer latido es la ventana de depuración más barata. Los problemas de prompt de sistema, las malas calibraciones de envolvente y los desajustes de sustrato aparecen durante las primeras 24 horas.
Estados de ciclo de vida. Los estados verificados de Paperclip son pending_approval, idle, terminated; las etiquetas del curso "running" y "paused" cubren los huecos. Recontratar es más rápido que contratar desde cero; la terminación es irreversible.
El registro de talento es memoria institucional consultable. Cinco consultas canónicas responden roles necesarios, costos con el tiempo, duración de contratación, historial de envolventes y proporción de recontratación.
La portabilidad de agentes opera en la capa de definición. Las recetas viajan; las envolventes, presupuestos y registros no. "Servicio a una empresa" es lo que significa contratar.
El registro de actividad es de solo anexado y está correlacionado de forma cruzada. Historia permanente; consultable en cualquier momento; la fuente de verdad de la memoria institucional cuando cambian los humanos.
Lo siguiente es la Invariante 2: el Edge. OpenClaw, traspaso de edge a nube, envolventes más estrictas en el edge. El Curso Ocho completa el arco de las siete invariantes.

Referencia rápida de API (verificada en mayo de 2026)

Quieres...	Endpoint	Método
Enviar una contratación	`/api/companies/{companyId}/agent-hires`	POST
Comprobar identidad/permisos	`/api/agents/me`	GET
Listar documentación de adaptadores	`/llms/agent-configuration.txt`	GET
Obtener documentación específica de adaptador	`/llms/agent-configuration/{adapter}.txt`	GET
Listar configuraciones de agentes existentes	`/api/companies/{companyId}/agent-configurations`	GET
Listar iconos permitidos	`/llms/agent-icons.txt`	GET
Leer una aprobación	`/api/approvals/{approvalId}`	GET
Comentar en un hilo de aprobación	`/api/approvals/{approvalId}/comments`	POST
Vincular aprobación al issue de origen	`/api/issues/{issueId}/approvals`	POST
Listar issues vinculados a una aprobación	`/api/approvals/{approvalId}/issues`	GET
Solicitar revisión en una aprobación pendiente	`/api/approvals/{approvalId}/request-revision`	POST
Reenviar una aprobación revisada	`/api/approvals/{approvalId}/resubmit`	POST
Asignar un issue a un Worker	`/api/issues/{issueId}` con `{ assigneeAgentId }`	PATCH
Pausar / reanudar / terminar un Worker	(consulta la referencia actual de la API)	(varía; consulta la nota de abajo)

Los endpoints de la tabla anterior están verificados contra la skill paperclip-create-agent de Paperclip (skills/paperclip-create-agent/SKILL.md y su api-reference.md, las fuentes canónicas). Las primitivas operativas documentadas de Paperclip para ejecutar Workers son Pause, Resume, Override, Reassign, Terminate; las rutas exactas de endpoint para estas primitivas pueden variar según la versión, así que consulta GET /llms/agent-configuration.txt para ver la superficie actual de la API en tu despliegue. La Decisión 7 del curso incluye código de pausa/reanudación con la misma salvedad en línea. Todas las solicitudes llevan Authorization: Bearer $PAPERCLIP_API_KEY. Las solicitudes mutantes llevan Content-Type: application/json.

Referencia rápida de CMA (verificada en mayo de 2026)

Quieres...	Llamada del SDK	Notas
Crear un agente	`cma.beta.agents.create`	Pasa `model` (una cadena simple), `system`, `tools`
Crear un entorno	`cma.beta.environments.create`	Pasa `name` y un objeto `config` (`type`, `packages`, `networking`)
Crear una sesión	`cma.beta.sessions.create`	Pasa `agent` (no `agent_id`) y `environment_id`
Enviar un evento	`cma.beta.sessions.events.send`	Envía un evento `user.message` a la sesión
Transmitir resultados	`cma.beta.sessions.events.stream`	Stream SSE de los eventos de la sesión

CMA es una API beta y estas formas cambian entre versiones; trata la documentación en vivo como autoridad. Todas las solicitudes llevan el encabezado beta managed-agents-2026-04-01 (el SDK lo configura). Una sesión de CMA se impulsa con eventos que tú le envías, no mediante una URL entrante: consulta la barra lateral del Concepto 6 para ver qué implica eso en la integración con Paperclip. Precios: tokens estándar de la API de Claude más un cargo de tiempo de ejecución por hora de sesión para la ejecución activa (consulta la página de precios de Anthropic para ver la tarifa actual). Referencia: platform.claude.com/docs/managed-agents.

Cuando algo se siente mal en la contratación

Manager-Agent proposed a hire after 2 emails, didn't wait for pattern?
    -> Concept 2's signal thresholds too sensitive. Tune the
       "at least 3 issues / at least 3 escalations / 14-day window" thresholds.

Board approved a hire but the Worker burned 3x the forecasted budget?
    -> Concept 4's budget estimate was wrong. The Worker is on the
       wrong substrate (Concept 6) or the eval pack's session-cost
       sample was unrepresentative (Concept 5).

Worker is producing wrong-tone or wrong-boundary replies in week one?
    -> System prompt is poorly scoped. Tighten the capabilities
       prose (Concept 4) and re-run a small eval pack (Concept 5).

Hire proposal kept getting REQUEST CHANGES from the board?
    -> Proposal artifact is missing context. Read Concept 7's
       rendering carefully and add the missing fields.

Two new authorities granted in one month; auditor asking why?
    -> Concept 8's envelope-extension records have rationale fields.
       Run the talent-ledger query (Concept 14, Query 4).

La frase marco del arquitecto: literal

El curso cierra como empezó, con la frase marco:

"Una fuerza laboral que no puede crecer por sí misma es una empresa fija; una fuerza laboral que puede crecer por sí misma bajo aprobación es una empresa nativa de IA. Contratar en Agent Factory no es un movimiento de RR. HH.; es una llamada de función del manager, que toma una descripción de puesto como entrada, devuelve un Worker como salida y está protegida por la misma primitiva de aprobación que protege cualquier otra acción consecuente."

Memoriza la frase. La arquitectura se desprende de ella.

Curso Siete del itinerario de programación agéntica. Seis de las siete invariantes ya están cerradas: el plano de gestión (Curso Seis), el sistema nervioso (Curso Cinco), el sistema de registro y las Skills (Curso Cuatro), el ciclo del agente (Curso Tres), el humano como principal (Cursos Cinco y Seis) y ahora la API de contratación (Curso Siete). La invariante restante, el delegado Edge mediante OpenClaw, es el Curso Ocho.

Dónde encaja esto: hoja de referencia​

¿Estás listo para este curso?​

Parte 1: Por qué contratar es invocable​

Concepto 1: Una fuerza laboral que no puede crecer por sí misma es una empresa fija​

Concepto 2: Brechas de capacidad, tres tipos de señal​

Concepto 3: Contratar frente a escalar, poner en cola o rechazar​

Parte 2: El contrato de contratación​

Concepto 4: La descripción del puesto como código​

Concepto 5: Evaluación de capacidades antes de contratar​

Concepto 6: Selección de sustrato: Claude Managed Agents vs Claude Agent SDK vs claude_local vs process​

Parte 3: Gobernanza para la contratación​

Concepto 7: Contratación mediante la puerta de aprobación del curso seis​

Concepto 8: Herencia del marco de autoridad para nuevas contrataciones​

Concepto 9: Política de aprobación automática: cuándo los humanos aprueban previamente una clase​

Parte 4: El ejemplo trabajado: contratar a un especialista legal​

Estado final esperado​

Decisión 1: Conectar la detección de brechas de capacidad en el Manager-Agent​

Decisión 2: Generar el artefacto de propuesta de contratación​

Decisión 3: Pasar la propuesta por la puerta de aprobación de Paperclip​

Decisión 4: Conectar el sustrato de runtime del especialista legal​

Decisión 5: Ejecución de evaluación de capacidades​

Decisión 6: Enrutar un issue contractual legal real al nuevo Worker​

Decisión 7: Retiro y recontratación​

Parte 5: Continuación del laboratorio: qué hace realmente el nuevo Worker​

Concepto 10: El primer latido del Worker: qué cambia entre la aprobación y el primer issue​

Concepto 11: Retiro y recontratación: el ciclo de vida completo​

Concepto 12: El registro de talento: cómo se ve una fuerza laboral de seis meses​

Parte 6: La pregunta más profunda y la mirada al Curso Ocho​

Concepto 13: La pregunta de la portabilidad de agentes​

Concepto 14: Por qué importa el registro de talento: memoria institucional durante cambios de personal​

Concepto 15: Qué sigue: Invariante 2 y el Edge​

Cómo volverse realmente bueno en esto​

Referencia rápida​

Los 15 Conceptos en una línea cada uno​

Referencia rápida de API (verificada en mayo de 2026)​

Referencia rápida de CMA (verificada en mayo de 2026)​

Cuando algo se siente mal en la contratación​

La frase marco del arquitecto: literal​

Ayuda de estudio con tarjetas didácticas​

Dónde encaja esto: hoja de referencia

¿Estás listo para este curso?

Parte 1: Por qué contratar es invocable

Concepto 1: Una fuerza laboral que no puede crecer por sí misma es una empresa fija

Concepto 2: Brechas de capacidad, tres tipos de señal

Concepto 3: Contratar frente a escalar, poner en cola o rechazar

Parte 2: El contrato de contratación

Concepto 4: La descripción del puesto como código

Concepto 5: Evaluación de capacidades antes de contratar

Concepto 6: Selección de sustrato: Claude Managed Agents vs Claude Agent SDK vs claude_local vs process

Parte 3: Gobernanza para la contratación

Concepto 7: Contratación mediante la puerta de aprobación del curso seis

Concepto 8: Herencia del marco de autoridad para nuevas contrataciones

Concepto 9: Política de aprobación automática: cuándo los humanos aprueban previamente una clase

Parte 4: El ejemplo trabajado: contratar a un especialista legal

Estado final esperado

Decisión 1: Conectar la detección de brechas de capacidad en el Manager-Agent

Decisión 2: Generar el artefacto de propuesta de contratación

Decisión 3: Pasar la propuesta por la puerta de aprobación de Paperclip

Decisión 4: Conectar el sustrato de runtime del especialista legal

Decisión 5: Ejecución de evaluación de capacidades

Decisión 6: Enrutar un issue contractual legal real al nuevo Worker

Decisión 7: Retiro y recontratación

Parte 5: Continuación del laboratorio: qué hace realmente el nuevo Worker

Concepto 10: El primer latido del Worker: qué cambia entre la aprobación y el primer issue

Concepto 11: Retiro y recontratación: el ciclo de vida completo

Concepto 12: El registro de talento: cómo se ve una fuerza laboral de seis meses

Parte 6: La pregunta más profunda y la mirada al Curso Ocho

Concepto 13: La pregunta de la portabilidad de agentes

Concepto 14: Por qué importa el registro de talento: memoria institucional durante cambios de personal

Concepto 15: Qué sigue: Invariante 2 y el Edge

Cómo volverse realmente bueno en esto

Referencia rápida

Los 15 Conceptos en una línea cada uno

Referencia rápida de API (verificada en mayo de 2026)

Referencia rápida de CMA (verificada en mayo de 2026)

Cuando algo se siente mal en la contratación

La frase marco del arquitecto: literal

Ayuda de estudio con tarjetas didácticas