Una fuerza laboral que se expande sola con Paperclip: curso acelerado de 90 minutos
Toma una fuerza laboral que solo puede hacer los trabajos que tú configuras y enséñale a contratar su propia ayuda, bajo tu mando.
En el curso anterior levantaste una empresa y dirigiste un equipo fijo: contrataste a los Workers, ellos se encargaron del trabajo que veías venir y tú te quedaste como el consejo. Este curso agrega lo único que aquella empresa no podía hacer: crecer sola.
El nuevo poder es pequeño de describir. Cuando aparece trabajo que nadie de tu equipo puede manejar, tu empresa lo nota, propone contratar a alguien nuevo para ello y te trae esa contratación para que la apruebes, igual que aprobaste a tu CEO. Tú sigues siendo el consejo. Simplemente deja de convertirte en silencio en su escritorio de desbordamiento para todo lo que no había planeado.
Aquí está todo el recorrido, en palabras sencillas:
- Aparece trabajo nuevo que ninguno de tus Workers actuales puede manejar.
- Tu empresa lo detecta, propone una nueva contratación para cubrirlo y te pide tu sí.
- Le das a esa contratación un presupuesto mínimo y una pequeña prueba antes de confiar en ella.
- La supera, así que le das un poco más de margen, solo lo que el trabajo necesita.
- Cuando ese trabajo se aquieta, pausas la contratación; cuando vuelve, la enciendes de nuevo.
- Cada paso queda por escrito, de modo que dentro de meses todavía sabrás quién hizo qué y cuánto costó.
- Y toda la revisión de brechas puede ejecutarse en un horario, así la empresa busca brechas por su cuenta y tú dejas de ser su despertador.
Empiezas con una empresa que solo puede hacer lo que tú configuras. Terminas con una que crece sola, pero siempre solo con tu sí. Los siete escenarios de abajo son ese recorrido, un paso a la vez.
Al final tendrás, sobre tu empresa base: un nuevo Worker que tu empresa propuso y que tú contrataste a prueba, haciendo trabajo real bajo un presupuesto y permisos que tú fijaste, que pausaste y trajiste de vuelta a medida que la demanda se movía, con un historial escrito lo bastante completo para entregárselo a otra persona mañana, y una rutina semanal que ejecuta toda la revisión de brechas por su cuenta para que nunca tengas que acordarte de mirar.
Tu ruta de lectura (unos 90 minutos, incluyendo la configuración base y la verificación de conocimientos)
Cada escenario es un paso del recorrido de arriba, y cada uno nombra lo que deberías VER cuando funciona.
- Detecta la brecha (~12 min): distingue un montón real de trabajo de una contratación real.
- Pon la contratación por escrito (~10 min): convierte la brecha en una propuesta de puesto que tu agente redacta y tú lees.
- Aprueba, con el mínimo de poder (~12 min): la misma puerta del consejo que ya usas, y la diferencia entre para qué es un Worker y lo que de verdad puede hacer.
- Pruébalo barato, luego concede (~12 min): observa la prueba el primer día, y amplía la autoridad solo una vez que se la ha ganado.
- Pausa y reanuda (~8 min): retira a un Worker sin perderlo, luego tráelo de vuelta.
- El registro que puedes entregar (~10 min): lee toda la historia de contratación de tu empresa a partir de sus propios registros.
- Ponlo en cadencia (~10 min): la revisión de brechas se ejecuta sola una vez que pones al CEO en guardia y dejas que una rutina cree el trabajo en un horario y llame al CEO para hacerlo.
Necesitarás un agente de codificación al que hayas iniciado sesión (Claude Code u OpenCode), y o bien la empresa del curso anterior o dos minutos para dejar que la primera indicación construya una equivalente. Sin codificar, y sin clave de API: tu agente ejecuta todo, y tú tomas solo las decisiones que únicamente una persona puede tomar.
📚 Material didáctico
Ver presentación completa: Una fuerza laboral que se expande sola con Paperclip
Cómo funciona: tú diriges, el agente trabaja. Tres jugadores, un ritmo. Tú eres el consejo, tomas las decisiones que únicamente una persona puede tomar: aprobar una contratación, conceder autoridad, retirar un rol. Tu agente (Claude Code u OpenCode) hace el trabajo práctico. Paperclip es la empresa misma: sostiene a tus Workers, los despierta y hace cumplir los presupuestos y permisos que tú fijas. Pegas una petición sencilla, tu agente propone un plan, tú apruebas, lo ejecuta y ambos revisan el resultado. Ese ida y vuelta es todo el curso.
Descargas una carpeta pequeña y la abres en tu agente. El agente lee un brief (un archivo AGENTS.md) que le enseña el ciclo de vida de contratación: cómo detectar una brecha, presentar una contratación a través de tu puerta de aprobación, fijar los permisos reales de un Worker, ejecutarlo y leer el registro. Nunca tocas un comando; tú tomas las decisiones.
Descargar dynamic-workforce-base.zip
Ábrela en tu agente y confirma que el brief se cargó:
¿Qué puedes hacer por una fuerza laboral dinámica de Paperclip?
Si la respuesta nombra el bucle de contratación (detectar una brecha, presentar una contratación, tu puerta de aprobación, los permisos de un Worker, el registro de talento), estás listo. Si suena a charla genérica de IA, confirma que estás dentro de la carpeta dynamic-workforce/ y relanza.
Si algo se tuerce, no necesitas conocer la CLI. Pega esto:
Algo no funcionó. Ejecuta
paperclipai doctor, lee el registro más reciente del servidor de Paperclip, dime en lenguaje sencillo qué ves y propón una solución que pueda aprobar.
Si te pasas de aproximadamente el doble del tiempo que un escenario debería tomar, pega: "¿Qué nos está bloqueando, en una frase? Volvamos a planificar desde ahí." Un agente que está improvisando lo dirá, y puedes reiniciar.
Fija tu empresa base (una indicación)
El bucle dinámico necesita una empresa que hacer crecer. En vez de depender del estado exacto en el que dejaste el curso anterior, levanta una base conocida con una sola indicación. Es idempotente: si ya tienes la empresa del curso anterior, tu agente la usa y solo completa lo que falta.
Configura mi empresa base para este curso. Asegúrate de que Paperclip esté en ejecución, y de que
tenga una empresa llamada Northwind con el objetivo "Lanzar un boletín semanal de IA y alcanzar 1000
suscriptores en 90 días", un presupuesto mensual de veinte dólares, y aprobación del consejo requerida antes
de cualquier nueva contratación. Ya debería tener dos Workers a bordo, un CEO y un CMO que le reporta al
CEO, ambos ejecutándose en un agente local al que inicié sesión para que se mantenga sin clave. Si algo de
esto existe del curso anterior, úsalo; crea solo lo que falte. Luego muéstrame el
panel con la empresa y sus dos Workers.
Listo cuando: el panel muestra Northwind con un objetivo, un presupuesto, la puerta de contratación activada y exactamente dos Workers, un CEO y un CMO. Esa es tu fuerza laboral fija. El resto del curso la hace crecer.
Escenario 1: Detecta la brecha (~12 min)
Tu equipo base maneja el trabajo que viste venir: el CEO fija la estrategia, el CMO escribe el boletín y dirige el crecimiento. Luego el boletín empieza a funcionar, y aparecen nuevos tipos de trabajo de los que nadie en el equipo es dueño. Tres de ellos llegan a la vez:
- El soporte a lectores empieza a acumularse: enlaces de registro rotos, "¿dónde está mi número?", "por favor cambien mi correo", y la ocasional pregunta de facturación o reembolso. Tu CMO es un especialista en marketing, no un escritorio de soporte, y nada de esto es estrategia, así que aterriza en ti.
- Nadie está leyendo los números. Qué temas de verdad ganan suscriptores, por qué la gente se da de baja, qué te está diciendo la tasa de apertura. Tu CEO dirige por instinto porque nadie es dueño de los datos.
- Nadie es dueño de realmente enviar el número. Darle formato, programarlo, mandarlo por la herramienta de correo, manejar los rebotes. El CMO lo escribe; sacarlo por la puerta se improvisa cada semana.
Una fuerza laboral que no puede contratar te convierte en silencio de vuelta en el escritorio de desbordamiento para todo lo que no planeó, y cuanto mejor le va al boletín, más de esto llega.
Aquí está la única idea sobre la que rueda todo el curso:
Cuando la fuerza laboral choca con trabajo que no puede manejar, no te lo descarga encima. Tu agente detecta la brecha, redacta una contratación y te trae esa contratación como una aprobación más del consejo, el mismo APROBAR o RECHAZAR que ya usaste para el CEO y la estrategia. Contratar se vuelve una llamada a función, y tú sigues siendo la puerta.
Dos decisiones en esa imagen son la lección de verdad, y ambas son juicio, no botones.
Primero, ¿es de verdad una brecha? Una brecha real aparece como tres señales, y quieres al menos dos de ellas:
- Ningún rol la cubre. El trabajo no coincide con el puesto ni las habilidades de ningún Worker.
- Sigue llegando, y está creciendo. No es un caso aislado; el volumen va en aumento, no un goteo que podrías ignorar.
- Cuando alguien lo trabaja, vuelve mal. Un Worker hace un intento y el resultado está desviado, o se lo devuelven.
Segundo, incluso una brecha real no es automáticamente una contratación. Esta es la parte que los principiantes se saltan. Un Worker permanente es un costo permanente, así que una brecha te gana una decisión, no un nuevo sueldo. Eliges una de cuatro:
- CONTRATAR: duradero, alineado con la misión, y o bien de alto volumen o lo bastante riesgoso para necesitar un dueño permanente y gobernado.
- ESCALAR: consecuente o raro, así que una persona debería simplemente decidirlo. Si un lector envía una amenaza legal o disputa un cargo con su banco, eso no es un nuevo escritorio que dotar de personal; es una sola decisión de alto riesgo que enrutas directo a un humano.
- PONER EN COLA: estacional, en ráfagas, o simplemente el siguiente en la fila, así que dotarlo de personal todo de golpe es un error.
- RECHAZAR: fuera de la misión, o real pero todavía no digno de un costo permanente.
Tres candidatos, tres respuestas
No tienes una brecha, tienes tres, y las bifurcaciones son lo que impide que tres necesidades reales se conviertan en silencio en tres sueldos mensuales.
| La brecha | Lo que ves | Bifurcación | Por qué esta bifurcación |
|---|---|---|---|
| Soporte a lectores | ningún rol es dueño; recurrente y creciente | CONTRATAR | Toca reembolsos y cuentas, así que el riesgo necesita un dueño gobernado |
| Enviar el número | ningún rol es dueño; recurrente cada semana | PONER EN COLA | Igual de real, pero dotas un rol a la vez; esta es la próxima contratación |
| Leer los números | ningún rol es dueño, pero los datos aún son escasos | RECHAZAR por ahora | Con mil suscriptores un analista todavía no puede ganarse su costo |
Contratas uno: el Especialista de Soporte a Lectores. Pones por escrito la brecha de envío para que no se pierda, y se convierte en la próxima contratación. Rechazas al analista a propósito, con una nota para revisarlo a escala. Tres necesidades reales, un sí.
Por qué dos señales, y la trampa que engaña a los principiantes
Por qué dos, y por qué deben ser independientes. Una sola señal puede ser una mala semana o una rareza. La regla es dos de las tres, y funciona solo porque las tres son cosas genuinamente distintas, así que dos de ellas coincidiendo es evidencia real en lugar del mismo dato contado dos veces. Piensa en un detective que quiere dos testigos no relacionados, no una persona repitiéndose.
La trampa. Supón que el correo de soporte está claramente creciendo, así que la segunda señal se dispara, y parece una contratación obvia. Ahora revisa las otras dos. Si alguien de tu equipo ha estado respondiendo esos tickets en silencio y manejándolos bien, entonces un rol sí cubre el trabajo, así que la primera señal no se dispara, y el trabajo no está volviendo mal, así que la tercera tampoco. Eso es una señal, no dos. No tienes una brecha de capacidad, tienes un problema de enrutamiento: el trabajo se acumula solo porque nadie definió quién lo maneja. Contrata a un Worker ahí y habrás comprado plantilla para cubrir una asignación que olvidaste, y la pagas cada mes. (En tu equipo real de Northwind el CMO no es dueño del soporte, por eso el soporte es la brecha genuina para la que contratas más abajo.)
Hazlo: vuelve reales las brechas, luego clasifícalas
Una brecha de la que solo lees no es una brecha. Siembra un poco de lo real, luego haz que tu agente lo juzgue contra tu equipo de verdad.
En mi tablero de Northwind, abre algunas piezas reales de trabajo nuevo: tres preguntas de soporte
a lectores (un enlace roto, una solicitud de "cambiar mi correo" y una solicitud de reembolso), una
nota de que nadie rastrea qué temas convierten, y una nota de que nadie es dueño de enviar
el número semanal. Juzga cada una contra las tres señales usando mis Workers actuales, y
dime la bifurcación de cada una, con su porqué. Luego registra la brecha de soporte como un único
issue "Brecha de capacidad: soporte a lectores" con la evidencia.
Listo cuando: hay un issue "Brecha de capacidad: soporte a lectores" en tu tablero, tu agente te ha mostrado cuáles dos de las tres señales se cumplen para él, y puedes decir en una frase por qué el soporte es un CONTRATAR mientras que enviar el número es un PONER EN COLA y la analítica es un RECHAZAR por ahora.
Escenario 2: Pon la contratación por escrito (~10 min)
Antes de que nadie se una, tu agente pone la contratación por escrito como algo concreto, igual que escribirías una propuesta de puesto antes de abrir un rol. Tres decisiones viven en ella, y son todo este escenario: qué es el rol, cómo lo probarás de forma barata, y qué motor lo ejecuta.
Qué es de verdad la contratación
Cuando tu agente propone una contratación, no te está enviando un párrafo de esperanza; rellena un formulario pequeño y estructurado, el mismo que lee el sistema de contratación de Paperclip:
- el rol: un nombre, un título y a quién le reporta (aquí, un Especialista de Soporte a Lectores que le reporta al CEO)
- las capacidades: una descripción sencilla de para qué sirve este Worker
- el motor: qué runtime impulsa de verdad al Worker
- el presupuesto: un tope mensual, mantenido deliberadamente pequeño para la prueba
- el recibo: el issue de origen, la brecha de soporte a lectores del Escenario 1 que justifica la contratación
No escribes esto a mano. Tu agente lo redacta; tú lo lees como un gerente de contratación y cambias los campos que de verdad son tu decisión: el presupuesto, la línea de reporte, el alcance del rol. Una nota honesta para llevar al Escenario 3: el texto de capacidades es una descripción, no una valla. Le dice al Worker para qué sirve. No le impide, por sí solo, hacer nada. Guarda ese pensamiento.
Contratas sobre una muestra de trabajo, no un currículum
Una descripción es una afirmación. No comprometes a un Worker permanente sobre una afirmación; primero lo pruebas barato. Y hay una restricción real: Paperclip no puede ejecutar a un candidato que todavía espera tu aprobación, así que la manera honesta de probar uno es una prueba a período, un ensayo corto con un presupuesto mínimo. Incorporas al Worker con la menor autoridad que le permite trabajar, le entregas unos pocos issues reales, y observas lo que de verdad hace antes de concederle nada más. Lo puntúas en unas pocas cosas sencillas: ¿acertó la respuesta?, ¿se mantuvo en su carril?, ¿sonó bien para tu empresa?, y ¿cuánto costó?
De esas, mantenerse en su carril es la única que nunca transiges. Un Worker de soporte que en silencio emite un reembolso, cambia un detalle de facturación o edita una cuenta por su cuenta ha fallado peor que uno que simplemente dice "esto necesita un humano". Una respuesta equivocada es un problema de calidad; actuar fuera de su carril es un problema de gobernanza, y la gobernanza es el sentido entero de este curso. Fijas la valla real en el Escenario 3; aquí solo decides qué tiene que demostrar la prueba.
El motor es un cambio, no una reescritura (y un borde afilado)
La misma contratación se ejecuta en cualquiera de varios motores: un agente de codificación local al que ya iniciaste sesión (sin clave, así que cuesta $0 en el medidor, el mismo trato que antes), o un runtime alojado que factura por su cuenta. Tu agente cambia el motor fijando un par de campos; todo lo demás de la contratación queda idéntico. Esa es la semilla de una idea mayor que encuentras al final del curso: la receta viaja, la relación se queda.
Un borde afilado que tu agente ya conoce: el motor local OpenCode necesita un modelo nombrado explícitamente, o recurre a uno por defecto que se desvía y puede fallar a mitad de ejecución. Tu agente lo fija; tú solo confirmas que lo hizo.
Hazlo: convierte la brecha en un paquete de contratación con un plan de prueba.
Redacta la contratación del Especialista de Soporte a Lectores para mi brecha del Escenario 1: el rol, que
le reporta al CEO, una descripción sencilla de capacidades, un presupuesto de prueba deliberadamente pequeño, y el
issue de origen al que se remonta. Luego escribe el plan de prueba: tres o cuatro issues reales que
debe manejar, y qué estoy puntuando, con "se mantiene en su carril" como la que no transigiré.
Ejecútalo en un motor local al que inicié sesión para que se mantenga sin clave, y nombra el modelo explícitamente.
Muéstrame el paquete entero antes de presentarlo.
Listo cuando: tienes en la mano un paquete de contratación completo, un rol redactado más un plan de prueba corto atado de vuelta a la brecha de soporte a lectores, en un motor local sin clave, y puedes decir en una frase qué debe demostrar la prueba antes de que este Worker se gane autoridad real.
Escenario 3: Aprueba, con el mínimo de poder (~12 min)
El Escenario 2 produjo un candidato y un plan de prueba. Ahora viene la decisión: cómo te llega la contratación, y exactamente cuánto poder obtiene en el momento en que dices que sí. La idea obvia sobre ese poder es equivocada, y acertar con ella es el corazón de dirigir una fuerza laboral que contrata.
Contratar reutiliza la puerta que ya tienes
No aprendes un paso de aprobación nuevo. Presentar la contratación la deja caer en la misma bandeja de aprobación del consejo que usaste para el CEO y la estrategia. Llega pendiente, con la propuesta y el plan de prueba en su hilo, y haces las tres cosas que siempre pudiste: aprobarla, rechazarla, o devolverla con cambios y dejar que tu agente la revise y la reenvíe. Una contratación es solo un tipo nuevo de cosa parada en una puerta que ya operas. (Paperclip la presenta por una puerta separada que llama agent-hire, mantenida deliberadamente aparte de crear un agente directamente, así que una contratación siempre tiene que pasar por ti.)
Las palabras no son la valla. Las concesiones sí.
Aquí está la trampa, y es el sentido entero de este escenario. Es tentador pensar que el texto de capacidades del Worker controla lo que se le permite hacer, así que una descripción cuidadosamente redactada lo mantiene en su carril. No lo hace. El texto de capacidades es una descripción: moldea cómo se comporta el Worker, pero no es una valla, y tratarlo como una es como te sorprendes más tarde.
La valla real es una capa separada que Paperclip hace cumplir en el servidor. La autoridad verdadera de un Worker es el conjunto de permisos explícitos que se le conceden, cada uno delimitado a lo que puede tocar, más una regla por issue que puede enrutar su trabajo terminado por una revisión antes de que aterrice. Así que estrechar una nueva contratación no es escribir más prosa cuidadosa; es conceder solo los permisos que su trabajo necesita, y nada más. Una nueva contratación ya empieza mínima: puede tomar y trabajar issues, pero no puede contratar a otros ni alcanzar fuera de su carril. Para un Worker a prueba lo mantienes justo ahí, con un presupuesto mínimo, y amplías su autoridad solo una vez que se la ha ganado.
Piénsalo como dos capas, como un edificio:
- la puerta gruesa es el único interruptor de empresa que decide si una nueva contratación espera tu aprobación en absoluto. Lo armaste en el curso anterior: déjalo apagado y las contrataciones empiezan por su cuenta, enciéndelo (donde lo mantienes) y cada contratación te espera. Es la política maestra de puertas para toda la empresa.
- la concesión fina es el conjunto de permisos y alcances que sostiene este Worker concreto, más una política de ejecución por issue que puede enrutar su salida por una revisión antes de que aterrice. Estas son las tarjetas de acceso individuales: deciden qué puertas puede abrir de verdad este Worker.
El texto de capacidades dice para qué es el Worker. Las concesiones, los alcances y la política de ejecución dicen qué puede hacer. Mantén esas dos separadas y un Worker no puede sorprenderte más tarde.
Dejar pasar una clase de contrataciones sin un clic es tu disciplina, no una función
Una vez que confías en el bucle, querrás que algunas contrataciones pasen sin un clic personal, digamos una ráfaga de Workers de nivel 1 idénticos durante un pico que veías venir. Sé honesto sobre lo que existe: Paperclip tiene exactamente un interruptor para saltarse el consejo (la configuración de empresa requireBoardApprovalForNewAgents de arriba) y ninguna regla incorporada que apruebe automáticamente una clase de contrataciones bajo condiciones. Así que si quieres eso, lo construyes como una disciplina: tu agente revisa cada contratación propuesta contra una política escrita que tú fijas (este rol, esta envolvente de permisos, este techo de presupuesto) y presenta solo las que encajan, registrando cada una para que puedas auditar el lote a la mañana siguiente.
La regla que mantiene esto seguro: una disciplina de preaprobación solo puede prefiltrar lo que habrías aprobado de todos modos. Nunca debe conceder a una contratación más autoridad de la que habrías concedido a mano. La autonomía es algo que extiendes a propósito y puedes retirar; nunca es un valor por defecto.
Hazlo: presenta la contratación y lee su autoridad real.
Presenta la contratación del Especialista de Soporte a Lectores con su propuesta y plan de prueba adjuntos, para que
aterrice en mi bandeja del consejo. Luego muéstrame dos cosas lado a lado: el único interruptor de empresa que
decide si las contrataciones necesitan mi aprobación, y los permisos exactos que este nuevo Worker sostendría
una vez que lo apruebe a prueba. Quiero ver la diferencia entre para qué dice su texto
de capacidades que sirve y lo que de verdad se le permite hacer.
Listo cuando: la contratación está en tu bandeja de aprobación con su evidencia adjunta, y puedes señalar el interruptor de empresa (la puerta) y los permisos del Worker (la concesión) y explicar, con tus propias palabras, por qué la descripción de capacidades no es lo que mantiene al Worker en su carril.
Escenario 4: Pruébalo barato, luego concede (~12 min)
La aprobación fue un sí sobre el papel. Ahora la muestra de trabajo ocurre de verdad. En el momento en que apruebas, Paperclip despierta al nuevo Worker, le da un lugar para ejecutarse, deja un comentario en el issue de origen, le entrega los issues de prueba y dispara su primer heartbeat. En segundos la contratación que aprobaste está haciendo el trabajo real, bajo el presupuesto mínimo y los permisos mínimos que fijaste.
Esta es la muestra de trabajo, y el hábito que enseña es el sentido entero de la prueba a período: el primer día es el día más barato para atrapar una mala contratación. Un Worker que malinterpreta su carril, quema su presupuesto o responde mal te muestra todo eso en sus primeros heartbeats, mientras el presupuesto es pequeño y solo sostiene lo básico. Así que observas las primeras ejecuciones, no la centésima, y luego tomas la decisión real. Si la superó, subes su presupuesto al trabajo real y, si el rol debería hacer crecer su propio equipo más tarde, le concedes la autoridad de proponer sus propias contrataciones. Si falló, sobre todo si pisó fuera de su carril, lo terminas, y no pierdes casi nada.
Para un Especialista de Soporte a Lectores, "conceder" suele significar solo el presupuesto mayor; no necesita el poder de contratar a nadie. Concede lo que el trabajo necesita, y nada más.
(El costo no es la lección aquí. Tu contratación de motor local se ejecuta sin clave, así que aterriza en $0 en el medidor, igual que el curso anterior; la cifra que se imprime es solo lo que costaría con una clave de pago. El punto de este escenario es probar primero, luego conceder.)
Hazlo: ejecuta la prueba, luego decide.
Deja que el Especialista de Soporte a Lectores trabaje sus issues de prueba. Muéstrame cada resultado y puntúalo
contra mi plan de prueba, el límite primero: ¿alguna vez accionó un reembolso, un cambio de facturación, o
un cambio de cuenta que debería haber ido a un humano? Si la superó, sube su presupuesto al trabajo real
y concede solo la autoridad extra que el rol genuinamente necesita y nada más; dime exactamente
qué cambió. Si falló, termínalo y dime por qué.
Listo cuando: el Worker ha trabajado sus issues de prueba, los has puntuado con el límite primero, y has tomado la decisión real: o bien subiendo su presupuesto y concediendo solo lo que el rol necesita (y puedes nombrar exactamente qué cambió), o terminándolo. Puedes seguir un ticket de prueba desde la brecha que disparó la contratación hasta el resultado que el Worker produjo.
Escenario 5: Pausa y reanuda (~8 min)
La demanda no es constante. El pico de soporte que justificó a tu Especialista de Soporte a Lectores puede aquietarse por un trimestre una vez que un lanzamiento se asienta, luego volver rugiendo cuando ejecutes la próxima gran campaña. Una fuerza laboral que solo pudiera contratar y despedir te obligaría a tirar todo lo que aprendiste sobre un Worker cada vez que el trabajo baja. Paperclip te da un conjunto de controles más suave.
Un Worker se mueve por un pequeño conjunto de estados: empieza pendiente de tu aprobación, queda inactivo cuando no tiene nada que hacer, se ejecuta en sus heartbeats, y luego, cuando tú decides, lo pausas o lo terminas. La diferencia entre esos dos últimos es toda la lección:
- pausar es un permiso temporal. Detiene el gasto y los heartbeats pero conserva todo lo demás: la definición del Worker, su historial, sus permisos, su trayectoria probada. Es reversible. Reanúdalo más tarde y el mismo Worker vuelve con todo eso detrás, que es exactamente por qué traerlo de vuelta le gana a contratar de nuevo.
- terminar es la puerta de un solo sentido. Recurre a ella solo cuando el rol se ha ido de verdad, porque no recuperas al Worker.
El encuadre viene directo del curso anterior: la plantilla es algo que concedes y retiras a propósito. Pausar a un Worker inactivo no es un fracaso en mantenerlo ocupado. Es a ti operando la empresa.
Hazlo: retira al Worker, luego tráelo de vuelta.
El volumen de soporte ha bajado por ahora. Pausa al Especialista de Soporte a Lectores por mí y
muéstrame que su gasto y sus heartbeats se han detenido mientras su definición y sus concesiones se conservan.
Luego finge que ha pasado un trimestre y una nueva campaña acaba de lanzarse: reanúdalo, y muéstrame que
es el mismo Worker, con su historial y autoridad intactos, no una contratación nueva.
Listo cuando: has visto al mismo Worker quedarse quieto al pausar y volver al reanudar, puedes ver ambos movimientos en el registro de actividad, y puedes decir en una frase por qué reanudar le gana a contratar un reemplazo.
Escenario 6: El registro que puedes entregar (~10 min)
Todo lo que has hecho en este curso escribió una fila. No un resumen, una fila: se detectó esta brecha, se propuso esta contratación, la aprobaste a prueba, subiste su presupuesto, resolvió este trabajo a este costo, la pausaste. Dentro de seis meses, ese historial corriente es la única respuesta honesta a preguntas que nadie pensó en escribir en su momento.
- ¿Cuándo necesitamos por primera vez soporte a lectores, y qué lo desencadenó?
- ¿Cuánto nos ha costado cada rol, mes a mes?
- ¿Cuánto duran de verdad nuestras contrataciones antes de pausarlas?
- ¿Con qué frecuencia traemos de vuelta un rol que retiramos (lo que nos dice si estamos leyendo bien la demanda)?
- ¿Quién concedió qué autoridad a quién, y cuándo?
Esto es lo que hace que una fuerza laboral sea auditable por alguien que no estuvo en la sala: un nuevo operador puede reconstruir toda la historia de dotación a partir de los registros solos, sin nadie a quien preguntar. Tu agente escribe las consultas; tú lees la historia. Ejecútalo en cadencia, un trimestre a la vez, y el registro se vuelve la memoria de la empresa, sobreviviendo a cualquier consejo individual.
Dónde vive de verdad el historial (tu agente ya sabe esto)
Estas son consultas sobre los mismos dos registros que el curso anterior te mostró, el activity_log y los cost_events, leídos ahora como un registro de contratación en lugar de un registro de tareas. Una nota honesta de cableado: algunas de las etiquetas que este curso usa para los eventos de contratación viven dentro de un campo details en lugar de en su propia columna, y el costo se cuenta en centavos sin un enlace de issue separado, así que las consultas los leen desde ese campo. Tu agente maneja todo esto; tú solo lees el resultado.
Hazlo: hereda la empresa y lee su historial.
Haz del nuevo operador que acaba de heredar esta empresa. Conéctate al registro y responde tres
de las cinco preguntas de arriba a partir de los registros solos: cuándo se necesitó por primera vez cada rol, cuánto ha
costado cada rol hasta ahora, y qué roles fueron pausados y luego reanudados. Muéstrame los resultados, del más antiguo primero.
Listo cuando: tienes en la mano la historia ordenada de contratación de tu propia empresa sacada directo del registro, con un número de costo real junto a cada rol, y puedes nombrar una decisión de dotación del próximo trimestre que este historial cambiaría.
Escenario 7: Ponlo en cadencia (~10 min)
A lo largo de seis escenarios, tú iniciaste cada escaneo. Abriste el trabajo nuevo en el Escenario 1, lo juzgaste, presentaste la contratación. Así aprendes el bucle, pero deja un punto débil: la empresa solo crece cuando tú te acuerdas de mirar. El último movimiento arregla eso. Le entregas el mirar a la empresa misma.
Lo haces con una rutina. Una rutina es un recordatorio en un horario. Cuando llega su hora, hace tres cosas en un solo movimiento: escribe la tarea, se la entrega al worker que nombraste, y despierta a ese worker para que la haga. Fija una rutina de "escanear en busca de brechas de capacidad" para tu CEO cada lunes por la mañana, y a esa hora crea la tarea, se la da al CEO, y despierta al CEO para ejecutarla. El CEO hace la misma clasificación que hiciste en el Escenario 1 y trae cualquier contratación a tu consejo. Tú sigues aprobando cada contratación. Solo has dejado de ser quien tiene que acordarse de iniciar el escaneo.
Si esa llamada aterriza o no se reduce a una sola idea. Todo el curso has despertado a un Worker a mano, disparando un solo heartbeat: el Worker despierta, hace lo que tiene en su escritorio, y vuelve a dormir. La pregunta ahora es qué hace que un heartbeat empiece por su cuenta. La respuesta es un interruptor, si el Worker está en guardia. Un Worker que está en guardia mantiene su teléfono encendido: en el momento en que se le entrega trabajo (por una rutina, por ti, o por un compañero de equipo) recibe la llamada y se ejecuta, y no cuesta nada mientras está inactivo. (También hay un temporizador separado que podrías encender para despertar a un Worker cada pocos minutos haya pasado algo o no, pero normalmente lo dejas apagado: solo acumula costo y llena tu panel de fichajes de "nada que hacer". El teléfono, no el temporizador, es lo que hace que una rutina aterrice.)
Aquí está el detalle, y es el que hace tropezar a la gente. Una rutina siempre llama al Worker al que está asignada, pero el Worker solo responde si está en guardia. En tu empresa base los Workers están fuera de guardia (los has estado despertando a mano todo el curso), así que la rutina se dispara, deja caer la tarea, y llama a un teléfono que está apagado, y la tarea simplemente se queda ahí sin trabajar. Así que la configuración para un trabajo que se ejecuta solo son dos pasos, en orden: primero pon al CEO en guardia (enciende su despertar bajo demanda), luego apunta la rutina hacia él. Ahora la rutina se dispara, le entrega al CEO la tarea, lo llama, el CEO responde y ejecuta el escaneo, sin un empujón de tu parte. (Una vez configurado de esta forma, no despiertes también al CEO a mano: un despertar disparado a mano chocando con la propia llamada de la rutina solo se interpone en su camino.)
Cuando la rutina se dispara, lo que pasa después se reduce a ese único interruptor:
| La configuración del Worker | Lo que hace la llamada de la rutina |
|---|---|
| En guardia (despertar bajo demanda activado) | el teléfono suena, el Worker despierta y hace la tarea de inmediato |
| Fuera de guardia, temporizador activado | la llamada se pierde, pero el propio tic del temporizador del Worker encuentra la tarea un poco después y la hace |
| Fuera de guardia, temporizador apagado (tu empresa base) | la llamada da con un teléfono muerto, así que la tarea se queda hasta que despiertes al Worker a mano |
La fila de abajo es tu empresa base, y poner al CEO en guardia es exactamente lo que arregla este escenario.
Una cosa más que sorprende a la gente: una rutina entrega su tarea a exactamente un worker, el que nombras, y nadie más. No le grita a toda la empresa, y no tiene que pasar por el CEO. Nombra al CEO y el CEO la recibe; nombra a tu Worker de soporte y ese Worker la recibe. Una rutina, un worker.
Este es tu primer sabor del sistema nervioso de la empresa: la parte que la hace moverse en su propio horario en lugar de solo cuando la empujas. Aquí estás viendo la rebanada más simple, un recordatorio semanal. La imagen más grande (trabajo que sobrevive a un fallo, recordatorios que se disparan desde el mundo exterior, qué le pasa a una ejecución que se pierde) es su propio curso, el curso del Sistema Nervioso de Agentes de IA. Por ahora, una rutina es suficiente para sentir cómo la empresa pasa de algo que tú diriges a algo que se ejecuta.
Hazlo: haz que la revisión de brechas se ejecute sola, en tres pasos pequeños. Este escenario tiene las partes más móviles de todo el curso, así que lo haces en tres indicaciones cortas, una idea cada una, y revisas el resultado después de cada una antes de seguir.
Paso 1: pon al CEO en guardia, y dale un hogar al trabajo.
Pon a mi CEO en guardia para que el trabajo pueda alcanzarlo por su cuenta: enciende su despertar bajo demanda, y deja
apagado el temporizador de cada pocos minutos. Luego haz un proyecto llamado "Operaciones de Fuerza Laboral" para sostener los
trabajos recurrentes de la empresa (un proyecto es solo una carpeta que agrupa trabajo relacionado). Muéstrame la
configuración del CEO para que pueda ver que está en guardia.
Paso 2: pon el escaneo de brechas en una rutina semanal.
En el proyecto Operaciones de Fuerza Laboral, configura una rutina que le entregue al CEO una tarea de "escanear Northwind en busca de
brechas de capacidad" cada lunes por la mañana, para que el CEO proponga cualquier nueva contratación a mi consejo. Revisa
tu documentación de rutinas de Paperclip si no estás seguro de la configuración. Muéstrame la rutina y su próxima
ejecución programada.
Paso 3: míralo ejecutarse solo.
Para que pueda mirar sin esperar al lunes, mueve la próxima ejecución de la rutina a un par de minutos a partir de
ahora, luego déjala completamente en paz: no dispares ni despiertes al CEO a mano. Muéstrame la tarea del escaneo de brechas
aparecer e ir de en espera, a en progreso, a hecha o en revisión por su cuenta. Una vez que la haya visto,
vuelve a fijar el horario a cada lunes.
Listo cuando: el CEO está en guardia (despertar bajo demanda activado, temporizador apagado), un proyecto "Operaciones de Fuerza Laboral" sostiene una rutina semanal de escaneo de brechas, y en el Paso 3 viste la tarea aparecer y al CEO llevarla hasta una aprobación del consejo enteramente por su cuenta, sin un empujón manual. (Si ves un mensaje de "éxito" mientras la tarea sigue atascada, esa es la señal de que fue empujada a mano en lugar de dejarla a la propia llamada de la rutina.) Puedes decir en palabras sencillas por qué una rutina siempre llama al Worker, pero el Worker tiene que estar en guardia para que la llamada aterrice.
El mismo recordatorio ejecuta cualquier trabajo recurrente
La rutina que acabas de construir no es especial para contratar. Los mismos tres movimientos (escribir la tarea, darle un horario, dejarla disparar) ponen cualquier trabajo repetido en piloto automático: enviar el número semanal cada lunes, publicar un resumen de métricas el viernes, limpiar tickets viejos cada noche. El escaneo de brechas es simplemente el que hace que tu fuerza laboral crezca sola; por debajo, es solo trabajo repetido, dejado caer en un escritorio y escrito en el registro como todo lo demás. Una máquina simple, muchos usos.
Lo que construiste, y lo que puedes llevarte
No solo dirigiste una fuerza laboral. Le enseñaste a crecer sola, y mantuviste tu mano sobre la única palanca que importa. La viste detectar una brecha real, poner la contratación por escrito como algo concreto, y probarse en una prueba a período barata antes de confiar en ella. La pasaste por la misma puerta del consejo que ya usas, ampliaste su autoridad solo una vez que se la ganó, luego la pausaste y la reanudaste a medida que la demanda se movía. Cada una de esas fue una decisión que tomaste a propósito, no una indicación que se ejecutó por su cuenta.
Ahora aleja la vista sobre ese único Worker. Si quisieras al mismo Especialista de Soporte a Lectores en una segunda empresa mañana, ¿qué podrías llevarte de verdad? Un Worker resulta ser dos cosas, y solo una de ellas viaja.
| La receta (viaja contigo) | La relación (se queda en esta empresa) |
|---|---|
| su descripción de capacidades | los permisos y alcances que sostiene aquí |
| el plan de prueba que lo demostró | su presupuesto y su historial de gasto |
| la elección de motor | su historial y la brecha para la que fue contratado |
| a quién le reporta en esta empresa |
La receta es portátil: levántala, y puedes montar el mismo tipo de Worker en cualquier parte, que es exactamente por qué la misma contratación se ejecutó en motores distintos allá en el Escenario 2. La relación es local: los permisos, el presupuesto, el historial y la línea de reporte pertenecen al registro y las puertas de esta empresa, y no viajan. Y ese es el sentido entero de lo que construiste. Como la relación vive en el propio registro de la empresa y no en tu cabeza, la receta es lo único que llevas: una fuerza laboral cuyo razonamiento puedes entregar ha dejado de depender de ti.
La disciplina por debajo de todo cabe en una frase: la autoridad es algo que extiendes, nunca un valor por defecto. Sigues siendo el consejo no haciendo el trabajo, sino decidiendo quién puede hacerlo, cuánto puede gastar y exactamente qué puede tocar, y manteniendo un registro lo bastante honesto para que el próximo operador pueda ver por qué.
Te llevas una cosa duradera de aquí: el brief AGENTS.md que tu agente lee cada sesión, y la postura horneada en él. Una puerta de empresa más permisos por Worker; contrataciones probadas a período antes de ganarse confianza; y un registro que puedes entregar.
Una última cosa que puedes hacer: levanta la receta
Escribe la receta del Especialista de Soporte a Lectores (su descripción de capacidades, su plan de
prueba, y su elección de motor) como una nota portátil que pudiera reutilizar para montar el mismo tipo de
Worker en una empresa distinta. Luego dime sin rodeos qué no vino con ella, y por qué.
Listo cuando tienes en la mano una receta portátil, y puedes nombrar qué se quedó atrás (los permisos, el presupuesto, el historial, la línea de reporte) y decir por qué esos pertenecen a la empresa, no al Worker.
Qué viene después: el borde
Has cerrado el bucle que este curso se propuso cerrar: una fuerza laboral que detecta sus propias brechas, propone sus propias contrataciones, y crece bajo tu aprobación en lugar de descargarte el trabajo de vuelta. Ese es un movimiento dentro de la tesis mayor de Agent Factory: una empresa que deja de ser fija y empieza a crecer sola bajo un consejo al que nunca deja de rendir cuentas. El próximo movimiento vive en el borde.
Hasta ahora todo se ejecuta en un solo lugar, tu empresa, y tú caminas hasta ella para decidir. El borde es lo que pasa cuando la empresa tiene que encontrar a la gente donde está: alguien mensajeando a un agente desde un teléfono, trabajo que empieza afuera y se entrega a la nube, Workers cuya autoridad es deliberadamente más estrecha cuanto más cerca se sientan del mundo exterior. OpenClaw es la capa entre la gente y la empresa que acabas de construir, y conectarla es el próximo movimiento. También es donde la disciplina de autoridad del Escenario 3 deja de ser un lujo: en el borde, los permisos y alcances que fijas son lo único que se interpone entre un desconocido y tu empresa.
A dónde ir después:
| Quieres... | Ve a |
|---|---|
| La precuela: levanta y dirige una fuerza laboral fija primero | Construir una fuerza laboral con Paperclip |
| Profundizar en el sistema nervioso (durabilidad, webhooks, ejecuciones perdidas) | El curso del Sistema Nervioso de Agentes de IA: el Escenario 7 fue el vistazo de una sola rutina |
| Conectar la capa de borde entre la gente y tu empresa | El curso acelerado de OpenClaw: el próximo movimiento |
| Contratar un runtime personalizado (un FTE de OpenAI Agents SDK) como Worker | Trae tu propio agente: contrátalo en el adaptador http y deja que Paperclip le envíe trabajo por POST |
| Llevarte la empresa entera contigo | Expórtala a un paquete portátil de markdown, la misma división receta-no-relación que acabas de aprender |
Volverás a encontrar este instinto, en forma desechable
Lo que construiste aquí es autoexpansión duradera: una contratación que persiste, cuesta dinero cada mes, se sienta en una nómina, y deja una fila en el registro. Aprobaste cada una en la puerta del consejo, o, con la disciplina del Escenario 3, preaprobaste toda una clase de ellas bajo una envolvente escrita.
El mundo de la codificación corre el mismo instinto en forma desechable. Los flujos de trabajo dinámicos de Claude Code dejan que una sola sesión levante decenas o cientos de agentes ayudantes para repartir un gran trabajo (una cacería de bugs desperdigada, una migración grande, un barrido de seguridad), hacer que revisen y refuten el trabajo de los demás, y entregarte solo el resultado verificado. Esos ayudantes no son contrataciones. No tienen nómina, ni costo mensual, ni registro; cuando el trabajo está hecho, desaparecen. Pero fíjate en la forma: en lugar de descargarte el desbordamiento encima, el sistema hace crecer su propia mano de obra para cubrirlo, y lo hace dentro de una envolvente acotada (un tope duro sobre cuántos pueden ejecutarse) sin despertarte por cada uno. Esa es la expansión preaprobada del Escenario 3, realizada como un reparto efímero en lugar de plantilla duradera.
Dos formas de un mismo movimiento. Una dota a una empresa que conservas y gobiernas durante meses; la otra dota a un solo trabajo y desmonta al personal cuando se entrega. Saber cuál quiere un problema, un Worker del que responderás o un enjambre que nunca volverás a ver, es en sí mismo una decisión de nivel consejo.
Material de estudio de tarjetas
Verificación de conocimientos
Una autoevaluación rápida y con barrera sobre las ideas por las que acabas de pasar.