Dejar atrás el portátil: curso acelerado sobre entornos de ejecución
12 conceptos · De un bucle que muere al cerrar la tapa a un trabajador con un hogar propio
Tu sistema está terminado y atrapado. El bucle que diseñaste se ejecuta cada mañana a las 9. El harness bloquea las acciones peligrosas. La suite de evaluaciones le da al revisor una cifra que puedes defender. Hiciste todo bien, pero todo se detiene en cuanto cierras el portátil, pierdes la conexión Wi-Fi o abordas un vuelo. Al trabajador más fiable que has construido le queda un único punto de fallo: el equipo de tu escritorio.
Este curso responde la última pregunta abierta de la sección: la decisión del entorno de ejecución. No se trata de qué hace el agente, porque tres cursos ya resolvieron eso, sino de dónde vive y quién lo mantiene activo: el lugar y quien lo cuida, no el comportamiento. Parece un detalle de infraestructura, pero no lo es. Esta pregunta decide si eres un operador con una herramienta excelente o el propietario de un trabajador que se presenta aunque tú no lo hagas. También es la misma pregunta que volverás a responder, a escala empresarial, cuando construyas tu primer Digital FTE. Apréndela aquí, a un tamaño que permita ver todas las piezas.
Una promesa antes de empezar: este curso no te convertirá en profesional de DevOps. Cada traslado utiliza recursos que ya tienes: los archivos de configuración del curso de programación con agentes, los comandos no interactivos del curso de evaluaciones, los horarios del curso de bucles y la suite que demuestra que el traslado funcionó. El único elemento realmente nuevo, un entorno de ejecución que otra persona opera por ti, se presenta con honestidad, su precio y sus ventajas e inconvenientes a la vista.
Primero necesitas Confiar en el verificador. Ese curso te dio la suite de evaluaciones, de la que este depende mucho: trasladarse a otro entorno de ejecución es exactamente el tipo de cambio que exige volver a ejecutar la suite antes de confiar. Se presupone toda la trilogía de la etapa 3: Ingeniería de bucles (pulsos, columna vertebral y puerta humana), Ingeniería del harness (los cinco verbos y el trinquete) y el curso de evaluaciones (conjunto dorado, líneas base y deriva). Si estos términos son nuevos para ti, completa primero esos cursos. Este traslada la maquinaria que construyeron.
¿Acabas de llegar? Repaso de 2 minutos sobre lo que ya debes saber
- Un pulso: una ejecución completa de un bucle programado. El bucle de clasificación matutina realiza un pulso cada día laborable.
- El harness: la capa que decide qué puede hacer el agente, qué debe saber, cómo se demuestra su trabajo y qué ocurre cuando algo sale mal.
- El conjunto dorado: la carpeta de casos de evaluación, creada a partir de fallos reales detectados y ejecutada de nuevo con cada cambio.
- La línea base: la tasa de aprobación registrada con la que comparas las ejecuciones nuevas. Una caída respecto de ella activa la alarma.
- La deriva: un cambio de comportamiento sin cambios de tu parte, normalmente porque se actualizó el modelo subyacente.
- La puerta humana: el trabajo arriesgado o fallido se envía a una persona. Nada sin supervisión llega a
main. - El modo no interactivo: ejecutar el agente sin una sesión interactiva (
claude -pen Claude Code yopencode runen OpenCode), de modo que un script o un horario puedan dirigirlo.
Si alguno de estos conceptos es nuevo, completa primero los tres cursos de la etapa 3. Este curso traslada la maquinaria que esos cursos construyeron y probaron.
Palabras clave en lenguaje sencillo
| Término | Significado sencillo |
|---|---|
| Entorno de ejecución | El equipo y el software alrededor de tu agente que lo ejecutan: lo inician, le proporcionan entradas y lo reinician si falla. |
| Hogar | El término de este curso para una opción de ejecución: tu sesión, un horario en la nube, un entorno administrado o tu propio proceso. |
| Plano de control | La mitad del entorno que opera el bucle del agente: sesiones, programación, flujos de eventos y reinicios. |
| Plano de ejecución | La mitad donde se realiza el trabajo: el entorno aislado donde funcionan las herramientas y los datos que tocan. Los dos planos pueden tener propietarios distintos. |
| Custodia | Quién conserva y controla los datos: en qué equipos viven y quién puede acceder a ellos. |
| No interactivo | Ejecutar el agente mediante un comando, sin sesión interactiva. Es el puente que cruza cada traslado. |
| Horario | Algo que inicia el bucle a una hora fijada sin ti: una Routine de Claude Code, una Scheduled Task de Cowork o un trabajo programado de GitHub Actions. |
| Ejecución administrada | Un servicio al que envías la definición del agente y cuyo proveedor opera el plano de control y, de forma predeterminada aunque no obligatoria, también el entorno aislado. |
| Definición del agente | Todo lo que describe al agente sin ejecutarlo: el modelo, el prompt de sistema, las herramientas, las reglas y las salvaguardas. |
| Sesión alojada | Una unidad de trabajo continua dentro de un entorno administrado, con su propio estado conservado y registro de eventos. |
| Entorno aislado | El entorno separado donde se ejecutan las acciones del agente. En algunos hogares está junto al modelo; en otros, está separado. |
| Portabilidad | Cuánto de tu sistema sobrevive al traslado a otro hogar sin tener que reconstruirse. |
| Dependencia del hogar | El costo de abandonar un hogar, medido por todo lo que tendrías que reconstruir. Una portabilidad baja implica una dependencia alta. |
| Radio de impacto | Hasta dónde puede llegar una mala noche en un hogar. Es la pregunta de presupuesto del curso del harness, aplicada a los entornos de ejecución. |
| Guardia | La alarma que despierta a un ingeniero cuando un sistema falla por la noche. «Estar de guardia» significa ser la persona responsable. |
| Recalcular la línea base | Registrar una tasa de aprobación específica del entorno después de que el hogar nuevo supere los límites de aceptación existentes, conservando la línea anterior para compararla. |
| Periodo de prueba | Una etapa de prueba: se observa de cerca el hogar nuevo y se mantiene disponible el anterior antes de confiar plenamente en él. |
De dónde procede este enfoque
Durante gran parte de la historia del sector, «despliegue» era una palabra de desarrolladores: se escribía código y después se enviaba a servidores. En 2025 y 2026 cambió algo: los operadores, personas que no escribieron el agente sino que lo configuraron y demostraron su funcionamiento, de pronto tuvieron algo digno de desplegar. Un bucle configurado con un historial medido es un activo, y uno que solo existe mientras el portátil está abierto está mal almacenado. Los proveedores lo advirtieron. Anthropic lanzó ejecución en la nube para sus herramientas de consumo y después un entorno alojado para definiciones de agentes. El ecosistema de código abierto adoptó los programadores de CI como alternativa de bajo costo. El resultado es que la decisión del entorno de ejecución, antes reservada a ingenieros al final de un proyecto, llega mucho antes y alcanza a personas que nunca escribirán un servidor. Este curso es para ellas. (Las fuentes aparecen al final.)
El cambio de mentalidad en una imagen
Este curso enseña dos herramientas juntas, como hizo toda la trilogía. El criterio, es decir, qué hogar elegir, cuándo trasladarse y cómo demostrar el traslado, es idéntico en ambas. La mecánica difiere más aquí que en cualquier curso anterior, y explicamos la razón con honestidad: el proveedor de una herramienta opera una nube para ella; el «proveedor» de la otra eres tú. Esa asimetría no es una nota al pie, sino una de las cuestiones que resuelve la decisión del entorno de ejecución.
Esto es cierto a mediados de julio de 2026. Todo lo que pertenece a la capa mecánica del curso, como nombres de productos, endpoints, precios y opciones, cambia más rápido que en cualquier otro curso de esta sección. Antes de cualquier traslado, ejecuta claude update u opencode upgrade y consulta la documentación vigente (code.claude.com/docs, docs.claude.com y opencode.ai/docs) antes de confiar en un nombre o una cifra.
Contenido del curso
| Parte | Tema | Lo que aprenderás |
|---|---|---|
| 1 | La última dependencia | Por qué un bucle probado en un portátil es un activo mal almacenado y la pregunta que clasifica opciones |
| 2 | El modo no interactivo es el puente | La invocación compartida por todos los hogares y el primer traslado: el horario en la nube |
| 3 | El entorno administrado | Definiciones, entornos y sesiones: qué entregas, qué recibes y cuánto cuesta |
| 4 | El traslado | Qué viaja, qué se reconstruye y por qué el historial debe ganarse de nuevo |
| 5 | Cómo elegir un hogar | Las cuatro preguntas, la combinación intencional de hogares y un traslado completo |
| 6 | Cómo mantener la honestidad | Dependencia, deriva de la propiedad, límites de cada hogar y puente al modo 2 |
| En vivo | Práctica interna | Dónde viven los bucles del libro y por qué |
| Práctica | Proyectos | Ocho traslados, del más fácil al más difícil |
¿Quieres aprender mediante la práctica? Lee primero la parte 5 para ver un traslado completo. Después vuelve al resto. ¿Es la primera vez? Lee las partes 1 a 5 en orden y omite las notas marcadas como «Profundización». Esa lectura lleva unos noventa minutos. Después completa los proyectos 1 a 3, que tardan más. Al terminar, tu bucle se ejecutará según un horario que no necesita el portátil y podrás afirmar, con una cifra, que sigue funcionando. Segunda lectura, después del primer mes de noches sin supervisión: toda la parte 6, las notas de profundización y los proyectos 4 a 8. La dependencia de un hogar solo se entiende por completo cuando tienes algo que no deseas reconstruir. ¿Lees en español como segundo idioma? Cada término figurado del curso tiene cerca una versión sencilla. Los recuadros «En términos sencillos» y el glosario anterior transmiten el mismo significado con frases breves y literales. Si una frase parece decorativa, el recuadro cercano dice lo mismo de manera directa. Hay dos capas que envejecen a ritmos distintos. Recuerda la primera y consulta la segunda.Dos formas de leer este curso
Qué recordar y qué consultar
📚 Material didáctico
Ver la presentación completa: Dejar atrás el portátil: curso acelerado sobre entornos de ejecución
Parte 1: La última dependencia
1. Un bucle probado en un portátil es un activo mal almacenado
Haz inventario de lo que construiste en tres cursos. Un bucle que clasifica la cola de la mañana antes de que te sientes. Un harness que impide los errores peligrosos y convierte cada fallo detectado en una regla permanente. Una suite de evaluaciones que le da al revisor central una cifra defendible. En términos aproximados: un colega principiante con descripción escrita del puesto, supervisor e historial de rendimiento.
Ahora cuenta sus dependencias. El portátil debe estar abierto, la sesión iniciada y el equipo despierto a las 9, con alimentación y conexión de red. Si falta una sola condición, el pulso no se ejecuta y nadie lo advierte. El curso de bucles ya mostró el costo: la cola crece, las escalaciones se acumulan y tu yo del lunes paga por la tapa cerrada del viernes.
Hay una forma más precisa de expresarlo. La trilogía te enseñó a eliminar puntos únicos de fallo uno a uno: separar al creador del verificador eliminó la única opinión sin revisar; el harness eliminó la única acción sin protección; las evaluaciones eliminaron al único verificador sin comprobar. Queda uno, y eres tú. No se trata de tu criterio, que la puerta humana conserva correctamente, sino de tu hardware. El sistema es más fiable que el equipo en el que se ejecuta. Esa es la señal de que ha superado su hogar.
Capacitaste a un buen trabajador y luego le exigiste trabajar solo en tu sala de estar y solo cuando estás en casa. El trabajador funciona bien. El problema es la disposición.
2. Una pregunta clasifica todas las opciones: ¿quién opera el bucle y dónde se ejecuta el trabajo?
En cuanto buscas un hogar nuevo, se multiplican las opciones y el vocabulario se vuelve ruidoso: sesiones en la nube, agentes alojados, entornos administrados, SDK, servicios sin servidor y orquestación. Atraviesa todo ese ruido con una sola pregunta. Observa sus dos mitades: ¿quién opera el bucle del agente y dónde se ejecuta su trabajo?
Conviene aprender ahora los nombres de ambas mitades porque los entornos modernos pueden separarlas. El plano de control es el bucle: inicia sesiones, alimenta al modelo, transmite eventos y reinicia lo que falla a las 3 de la mañana. El plano de ejecución es donde aterrizan las acciones: el entorno aislado donde funcionan las herramientas y los datos que tocan. En tu portátil, ambos planos comparten una máquina, así que nunca necesitaste distinguirlos. Los hogares siguientes pueden separarlos, y el más interesante lo hace de forma deliberada.
Cada opción pertenece a uno de cuatro hogares, clasificados por esas dos mitades y representados en la imagen anterior:
- Hogar 1: tu sesión. Lo posees todo: la configuración, el entorno y la disponibilidad. Aquí tuvo lugar la trilogía y sigue siendo el hogar correcto para construir y demostrar. Es el hogar equivocado para depender de él.
- Hogar 2: el horario en la nube. Aún posees la configuración, con el mismo archivo de reglas, las habilidades y los subagentes, pero el reloj se traslada al equipo de otra persona. Una Routine de Claude Code ejecuta el bucle en la nube de Anthropic. Un trabajo programado de GitHub Actions ejecuta el bucle de OpenCode en los runners de GitHub. Es el traslado más pequeño y ofrece el beneficio inmediato más grande.
- Hogar 3: el entorno administrado. Entregas la definición del agente, con modelo, prompt, herramientas y salvaguardas, y el servicio de un proveedor opera el plano de control: el bucle, las sesiones y la recuperación de fallos. El plano de ejecución es una elección: el entorno aislado del proveedor de forma predeterminada o, cuando la custodia lo exige, uno en infraestructura que tú controlas. Dejas de operar el bucle y sigues operando el negocio que lo rodea.
- Hogar 4: tu propio proceso. El harness se convierte en una biblioteca dentro del software que escribes y los servidores que operas. Lo posees todo y asumes toda la responsabilidad. Este es el Agent SDK y el territorio del modo 2. El curso te muestra la puerta, pero no la cruza.
La separación en dos planos, mostrada de forma directa. Hay cinco filas porque el hogar 3 en realidad son dos:
| Hogar | Plano de control | Plano de ejecución | A quién despierta un fallo |
|---|---|---|---|
| 1 · Tu sesión | Tú | Tu portátil | A ti |
| 2 · Horario en la nube | Tú, mediante un programador | Un runner en la nube | Responsabilidad compartida |
| 3 · Administrado, entorno aislado en nube | El proveedor | El proveedor | La infraestructura es suya; el resultado, tuyo |
| 3 · Administrado, entorno autoalojado | El proveedor | Tú | Se divide por plano |
| 4 · Tu propio proceso | Tú | Tú | A ti, de forma deliberada |
Observa de qué trata realmente la pregunta. No es técnica. Es la misma que toda empresa plantea para cada función: ¿la realizamos nosotros o pagamos a alguien para que la haga? Ya sabes pensar de esa manera. El resto del curso aplica ese razonamiento al equipo que está debajo del agente.
Hay cuatro hogares entre los que elegir, no una escalera que subir: tu portátil, donde lo posees todo; un horario, donde posees la configuración; un entorno administrado, donde posees la definición y el entorno aislado puede estar en su nube o en la tuya cuando la custodia lo exige; o tus propios servidores, donde vuelves a poseerlo todo de forma deliberada y a escala de producto. La regla que reaparece durante el curso es poseer solo lo que debes, no lo que deseas. La mayoría de los lectores permanece en los tres primeros y a menudo utiliza varios al mismo tiempo, uno por bucle. El cuarto hogar es donde comienza el modo 2.
Ayesha vive en Lahore y ejecuta en su portátil un bucle para las facturas de su trabajo independiente. Los cortes de electricidad interrumpen el suministro casi todas las tardes y acaba de conseguir un cliente que espera recibir las facturas todos los días a las 18:00, sin fallos. ¿Qué hogar necesita primero y por qué el hogar 3 supera sus necesidades hoy? El hogar 2, el horario en la nube. Su problema es exactamente el reloj: el bucle está probado y la configuración funciona, pero el equipo no puede prometer las 18:00. Trasladar el horario a un runner en la nube elimina el corte eléctrico de la ruta crítica sin cambiar nada que deba demostrar de nuevo, salvo el propio hogar. Las palabras del cliente exigen una observación honesta: la mayoría de los programadores, incluidos los de CI, prometen ejecutar cerca de una hora, no exactamente a esa hora. Bajo carga se retrasan y en ocasiones omiten una ejecución programada. Por eso «sin fallos» no es una función del programador, sino una suite mínima para el funcionamiento sin supervisión: detector de ejecuciones ausentes, reintento que no pueda enviar la misma factura dos veces y alarma si no hay éxito registrado a las 18:30. El hogar 3 resuelve problemas que aún no existen, como atender a otros usuarios, conservar sesiones durante trabajos largos y operar a escala, y cobra por ello. Las cuatro preguntas de la parte 5 lo convertirán en una prueba explícita: ¿quién es el usuario? Hoy es Ayesha. El hogar 2, con la suite mínima, basta.Mostrar la respuesta
Parte 2: El modo no interactivo es el puente
3. Todos los hogares hablan el lenguaje no interactivo
Este es el hecho discreto que hace posibles todos los traslados del curso: ya cruzaste el puente durante el curso de evaluaciones, aunque nadie lo llamara así. El runner de evaluación invocaba claude -p y opencode run: el agente como comando, no como conversación. No hay ventana abierta ni sesión que vigilar: entra un prompt, se realiza el trabajo, sale el resultado y termina el proceso.
Eso es el modo no interactivo y la idea sobre la que descansa todo el curso. Cualquier sistema capaz de ejecutar un comando puede ejecutar ahora tu agente. Puede hacerlo un script de shell, un trabajo cron, un runner de CI o un programador en la nube. Debajo de la superficie, todos los hogares a partir del 2 solo responden de manera distinta a una pregunta: «¿El equipo de quién ejecuta el comando no interactivo y según el reloj de quién?».
La mecánica del curso de evaluaciones se conserva: --output-format json para resultados legibles por máquinas en Claude Code, el flujo de eventos JSON en OpenCode y el verificador escribiendo su veredicto en un archivo para que nadie tenga que analizar prosa. Añade un hábito ahora que no hay una persona observando: las ejecuciones no interactivas deben fallar con una alerta visible. En una sesión ves el error. En un runner, un código de salida que nadie comprueba es un pulso que no ocurrió y nadie advirtió: el mismo fallo del concepto 1 reconstruido en la nube. Todos los wrappers de este curso comprueban el código de salida y emiten una alerta al fallar, el quinto verbo del curso de bucles. El silencio debe significar éxito, y esa es una regla que aplicas, no un valor predeterminado que heredas.
En el modo interactivo hablas con el agente. En el modo no interactivo, cualquier persona o sistema, como un script, un horario o un servidor, le entrega una nota y recoge el resultado. Cuando el agente acepta notas, puede trabajar en cualquier lugar al que se puedan enviar.
4. Hogar 2, el horario en la nube: el reloj sale primero
El primer traslado es deliberadamente el más pequeño: conserva todo lo construido y traslada solo el reloj. Tu configuración, con archivo de reglas, habilidades, subagentes y hooks, permanece igual. Lo único que cambia es quién inicia el pulso.
La ruta del proveedor es el horario prometido por el curso de bucles y conserva su nombre: una Routine. En Claude Code, el comando /schedule, cuyo alias es /routines, crea una mediante conversación. Guarda una configuración con su prompt, repositorios, conectores y entorno. Esa configuración se ejecuta en la infraestructura en la nube administrada por Anthropic aunque el portátil esté cerrado. Tu bucle asociado al repositorio, «cada día laborable a las 9, ejecuta la habilidad de clasificación matutina y escala todo lo que supere el riesgo medio», se convierte exactamente en esto.
Tres observaciones honestas tomadas de la documentación vigente, todas familiares:
- Routines está en vista previa de investigación. Es la capa más mecánica de todas, así que verifica antes de depender de ella.
- Una ejecución programada puede empezar unos minutos después de la hora por diseño, algo que la documentación llama stagger. La promesa real es «cerca de las 9». Es el argumento de este curso sobre todos los programadores, expresado por el propio proveedor.
- Un estado verde solo significa que la sesión terminó sin un error de infraestructura. No significa que la tarea haya tenido éxito. La regla de alerta visible del concepto 3 sigue siendo tu responsabilidad, dentro del prompt y de las comprobaciones que ejecuta.
Una trampa tiene un nombre amistoso. Si eliges Local en la aplicación de escritorio, se crea una tarea programada de escritorio que se ejecuta en tu equipo. Eso es el hogar 1 con un temporizador, no un traslado.
En Claude Cowork, la misma idea aplicada al trabajo de conocimiento es una Scheduled Task. La describes una vez y se ejecuta de forma remota según el horario con tus conectores, habilidades y plugins. Los resultados esperan hasta que los consultes. La misma documentación señala una salvedad: una tarea que necesita archivos locales o aplicaciones de escritorio se ejecuta de forma local, por lo que vuelve a necesitar el portátil. Elige según lo que toca el bucle: para trabajo de repositorio, una Routine de Claude Code; para conectores y documentos, una Scheduled Task de Cowork. En ambos casos, la única función restante del portátil es ser el lugar donde lees los resultados.
Dos observaciones más sobre la capa mecánica. Primero, un runner en la nube no es tu equipo. Su acceso a repositorios, conectores y credenciales se configura, no se hereda. La primera ejecución de una Routine sirve en parte para descubrir qué puede ver el hogar nuevo. Segundo, el harness viaja según la configuración, pero debes verificar que lo hizo. Los límites de permisos y hooks son archivos, y solo protegen las ejecuciones que los cargan. Consulta en la documentación vigente cómo obtiene Routines tu configuración y considera obligatorio el periodo de prueba del concepto 8.
Para los bucles asociados a un repositorio existe una segunda versión del hogar 2, independiente del proveedor, que ya construyó el curso de bucles: un flujo de trabajo de GitHub Actions con un disparador schedule:. Ejecuta claude -p en modo no interactivo sobre un runner de CI, junto con la configuración extraída del repositorio. Es el mismo hogar alquilado a otra empresa, con una advertencia que publica GitHub: los flujos programados funcionan según el mejor esfuerzo. Pueden comenzar tarde bajo carga, se omiten en ocasiones y solo se ejecutan desde la rama predeterminada. Para un bucle matutino, el contrato real es «cerca de las 9». Todo plazo estricto exige la suite mínima siguiente y, quizá, un programador más fuerte.
OpenCode no tiene un plano de control alojado propio, y este curso no fingirá lo contrario, porque la versión honesta enseña más. Con OpenCode, el hogar 2 utiliza un programador que tú eliges. Para bucles asociados a repositorios, usa el patrón de GitHub Actions del curso de bucles: ejecuta opencode run con un disparador schedule: y extrae la configuración .opencode/. Para lo demás, utiliza cualquier equipo capaz de ejecutar cron: un servidor en la nube económico, un equipo doméstico siempre encendido o un runner programado en cualquier lugar.
Obtienes exactamente lo que prometía la herramienta: no hay un proveedor entre el bucle y tú; eliges el modelo y el proveedor. Aceptas que ahora tú eres el proveedor: debes administrar la disponibilidad, las credenciales y las actualizaciones del runner. Para un bucle de repositorio en Actions, la carga es pequeña y corresponde sobre todo a GitHub. Con un equipo pequeño bajo el escritorio, reconstruiste el hogar 1 con más trabajo. Por eso la versión de Actions es la recomendación predeterminada de este curso para OpenCode.
La diferencia entre las dos pestañas es la lección, no un defecto: una herramienta abierta expone toda la decisión del entorno sin ocultar nada. Volverás a encontrar la misma elección en la sección Harnesses de agentes personales, donde poseer el entorno es precisamente el objetivo.
Elijas la versión que elijas, la definición de éxito es igual y medible: al menos un ciclo operativo completo y diez pulsos exitosos como mínimo con el portátil cerrado y el silencio indicando la línea base. No basta con que «se ejecutó una vez en la nube», porque el curso de evaluaciones ya enseñó cuánto vale una ejecución verde, ni es una prueba de disponibilidad a largo plazo. Llámalo evidencia operativa inicial y amplía la muestra para bucles más arriesgados o poco frecuentes. Son pulsos programados, cada uno comparado con la línea base, y alarmas probadas una vez de forma intencional. Ese es el hogar 2 ya ocupado.
La suite mínima para operar sin supervisión. El curso prometió no convertirte en profesional de DevOps y cumple la promesa con una tabla en lugar de una disciplina completa. Contiene seis controles, todos obligatorios cuando nadie observa la ejecución. Cada uno es pequeño y existe porque su ausencia produjo un fallo conocido.
| Control | Regla | Fallo que evita |
|---|---|---|
| Idempotencia | Debe ser seguro repetir un pulso reintentado | La factura enviada dos veces o la incidencia duplicada |
| Detección de ejecución ausente | Un segundo sistema advierte cuando el primero nunca comenzó | Un proceso que no se ejecutó no puede avisar de su ausencia |
| Bloqueo de concurrencia | Un pulso a la vez; el de las 9 espera si el de las 8 sigue activo | Dos agentes editando los mismos archivos en una cola |
| Disciplina de credenciales | Credenciales de servicio limitadas, privilegio mínimo, rotación y nunca tu inicio personal | Un runner en la nube que posee toda tu identidad |
| Semántica temporal | Zona horaria escrita y reglas de horario de verano y recuperación decididas de antemano | La factura de las 18:00 que cambia una hora dos veces al año |
| Límites de costo y ejecución | Duración, turnos, reintentos y gasto máximos por pulso, con conducta de terminación | La ejecución errante que consume el presupuesto mensual |
La suite es el costo de entrada al hogar 2 y viaja contigo: todos los hogares posteriores exigen los mismos seis controles, a veces como opciones del servicio en vez de scripts. Cuando la cuarta pregunta de la parte 5 fija un límite de velocidad, la «puerta mínima de seguridad» se refiere a esta tabla.
El primer traslado es el más pequeño. Conservas toda la configuración y cambias una sola cosa: qué inicia el bucle. En lugar de abrir tú el portátil, un horario en la nube lo inicia según un reloj. Como ahora nadie observa, añades seis reglas de seguridad pequeñas para impedir que una ejecución falle en silencio.
Profundización: el horario se trasladó, pero la puerta humana no
El traslado esconde una trampa. En el portátil, la puerta humana tenía una propiedad conveniente: tú estabas allí. El bucle escalaba y la escalación aparecía en una ventana que ya mirabas. En el hogar 2, el bucle se ejecuta aunque estés lejos de una pantalla, por lo que las escalaciones pueden acumularse sin que las veas. Una escalación ignorada es una decisión retrasada y, en ocasiones, una decisión tomada por omisión. Por eso el hogar 2 obliga a mejorar algo que el portátil nunca exigió: el canal de escalación debe llegar hasta ti, no hasta tu escritorio, mediante un mensaje, una mención o una incidencia con tu nombre. El verbo «emitir una alerta» del curso de bucles debe apuntar a un lugar donde realmente estás. La puerta no se trasladó; tuvo que hacerlo el timbre.
El primer pulso programado en la nube aparece en verde. Un compañero afirma que la migración terminó. A partir de lo que enseñó el curso de evaluaciones sobre una sola ejecución y de lo que añadió esta parte sobre el silencio, ¿qué dos elementos faltan antes de poder decirlo con honestidad? Primero, un pulso verde es un dato sobre una ejecución, no sobre el hogar. La migración se demuestra mediante una tasa, por eso el criterio es un ciclo operativo completo y al menos diez pulsos comparados con la línea base, no una primera noche. Segundo, no se ha probado la alerta del fallo. Hasta que plantes un fallo deliberado y observes que la alarma llega hasta ti, el silencio es ambiguo: puede significar línea base o que el runner nunca comenzó y no existió nada capaz de protestar. Terminado significa una semana en verde, alarma probada y escalaciones que llegan a un lugar que realmente consultas.Mostrar la respuesta
Parte 3: El entorno de ejecución administrado
5. Hogar 3: envías una definición y un servicio ejecuta al trabajador
El hogar 2 trasladó el reloj. El hogar 3 traslada el plano de control y, solo si así lo eliges, también el plano de ejecución. Un entorno administrado es un servicio con un contrato sencillo y radical: describes al agente, con modelo, prompt de sistema, herramientas, conectores y salvaguardas, y el servicio lo opera. El bucle, el estado de sesión, los reintentos y la recuperación de fallos a las 3 de la mañana se ejecutan en los equipos del proveedor y los operan sus ingenieros; de forma predeterminada, también el entorno aislado. Dejas de operar el bucle del agente. Sigues operando todo lo que lo rodea: el horario que lo invoca, las credenciales, el consumo de eventos, las escalaciones, los límites de gasto y el incidente cuando el resultado es incorrecto. Eres autor de la definición y sigues siendo propietario del sistema empresarial.
Cuando se escribe este curso, el ejemplo concreto es Claude Managed Agents, que entró en beta pública en abril de 2026. Conviene aprender su forma aunque cambien los detalles, porque la forma contiene la idea. Creas tres elementos:
- Un agente: la definición, con modelo, prompt, herramientas y salvaguardas. Tu archivo de reglas y el prompt del revisor se traducen a una forma que el servicio puede conservar.
- Un entorno: el espacio cerrado donde se ejecutan las acciones, es decir, los límites del curso del harness convertidos en un objeto del servicio en lugar de un archivo local. Es el plano de ejecución y puedes elegirlo: un entorno aislado en la infraestructura del proveedor de forma predeterminada o uno autoalojado en infraestructura que controlas cuando los datos no pueden salir de tu custodia. En ambos casos tú defines los límites. La propia guía de producción del proveedor recomienda redes de privilegio mínimo con una lista explícita de hosts permitidos, exactamente como el curso del harness.
- Una sesión: una unidad de trabajo continua con estado conservado y registro de eventos de solo anexado. Es el pulso del curso de bucles, pero puede detenerse, reanudarse y sobrevivir durante días porque no necesita un portátil abierto debajo.
Tu aplicación, o tu script a la escala de este curso, se comunica con estos objetos mediante una API y recibe un flujo de eventos. El detalle arquitectónico importante es que aquí los dos planos del concepto 2 se vuelven visibles y separables. El modelo que piensa y el entorno aislado que actúa son piezas distintas conectadas por el servicio. En cursos anteriores conociste la versión acoplada: agente y herramientas en un proceso sobre una máquina. La forma desacoplada permite que otra persona opere a escala la parte que actúa y es la forma hacia la que convergen las arquitecturas de agentes en producción. Recuerda la idea: vuelve en el modo 2 como una decisión de diseño que tomas por cuenta propia.
Dos límites expresados con claridad porque los proveedores suelen decirlos en voz baja. Un plano de control administrado es específico del proveedor: este ejecuta Claude y Anthropic lo opera. El entorno aislado puede estar en tu infraestructura, pero el bucle, las sesiones y la ruta del modelo no. La pestaña de OpenCode explica con honestidad qué implica para el ecosistema abierto. Además, un entorno administrado no es el SDK con alojamiento añadido: Agent SDK y Managed Agents son productos distintos, y el código escrito para uno no se despliega sobre el otro. Lo que se conserva no es el código. La parte 4 explica qué sí viaja.
El ejercicio de traducción entre lo que posees y lo que conserva el servicio es directo. La descripción del trabajo del bucle se convierte en el prompt del agente. Los límites de permisos y reglas de denegación se convierten en la configuración del entorno. Cada pulso programado se convierte en una sesión que el script abre sin interacción según el mismo horario del hogar 2. Los endpoints, las formas de las llamadas del SDK y los encabezados de la beta son la capa más mecánica del libro. Tienen semanas de antigüedad y cambian cada mes. Obtén todos de la documentación vigente en docs.claude.com y trata cualquier tutorial con más de una estación, incluido este, como una descripción de la forma, no como referencia.
En este lado no existe un hogar 3 propio y el curso no inventará uno. Conviene precisar qué falta. OpenCode funciona de forma remota sin problemas. opencode serve proporciona un proceso de servidor no interactivo. Los clientes pueden conectarse a una instancia remota y todo puede ejecutarse en un contenedor sobre el servicio administrado que prefieras. Lo que nadie ofrece es un plano de control administrado propio: un proveedor que opere el bucle, las sesiones y la recuperación como servicio. Una herramienta abierta con modelos intercambiables no tiene un proveedor único que pueda hacerlo. Por eso los equivalentes honestos son un hogar 2 reforzado, con programador y suite mínima donde tú eres el proveedor, o un proceso de servidor que escribes y operas. Si lo utilizas seriamente, ese proceso pertenece al hogar 4 y al modo 2. A cambio, obtienes algo que ningún plano administrado vende: nada se interpone entre el bucle y tú. La elección correcta no depende de la herramienta, sino de las preguntas de la parte 5.
En los hogares 1 y 2 empleas al trabajador y mantienes su oficina. En el hogar 3 escribes la descripción del puesto y las reglas de la oficina, mientras una empresa de servicios administra la electricidad, la seguridad, los turnos nocturnos y las reparaciones. Visitas mediante informes, no por la puerta principal.
6. Lo que recibes, lo que entregas y lo que cuesta
El contrato administrado, valorado con honestidad por ambos lados.
Lo que recibes. Las operaciones que nunca quisiste: un entorno aislado mantenido por quienes construyeron el harness, estado de sesión que sobrevive a fallos y trabajos de varios días, administración del contexto y caché de prompts ajustados al modelo actual por el proveedor que distribuye ese modelo. Esto reduce el trabajo de compatibilidad entre modelo y entorno que el curso del harness te obligó a realizar. Conviene precisar el alcance: no resuelve la deriva de comportamiento, y las actualizaciones coordinadas de modelo y harness pueden dificultar la atribución de una regresión porque cambian dos cosas a la vez. La ejecución programada de la línea base conserva toda su función. La guardia de infraestructura es suya y el reinicio a las 3 de la mañana deja de ser tu problema por contrato. La guardia del resultado empresarial sigue siendo tuya: si el trabajo llega a tiempo pero es incorrecto en sus equipos, la escalación continúa bajo tu responsabilidad.
Lo que entregas. Tres elementos, del más ligero al más importante. Visibilidad: lees el registro de eventos emitido por el servicio, no la propia máquina. La evaluación de trazas de profundidad 3, que comprueba los pasos además de la respuesta, depende de lo que contiene el registro. Custodia: tus prompts, fixtures y entradas se ejecutan en infraestructura que no controlas. Para ciertos datos, profesiones y reguladores, esa única realidad decide la cuestión; ninguna lista de funciones cambia la respuesta. Portabilidad: tu definición utiliza las formas del proveedor y, cuando te marchas, se reescribe en lugar de trasladarse. Ese es el tema de la parte 6.
Lo que cuesta. Un tipo nuevo de factura, más importante que las cifras actuales. Los hogares 1 y 2 cuestan tokens más el runner. El hogar 3 añade un medidor del propio entorno de ejecución. Cuando se escribe esto, cuesta unos ocho centavos por hora de trabajo activo de la sesión, con el tiempo inactivo gratuito, además de tokens y extras medidos como la búsqueda web. La forma produce dos consecuencias. Mantener una sesión que piensa brevemente y duerme mucho es casi gratuito, lo que hace asequibles las sesiones duraderas. Un bucle errante, la enfermedad de profundidad 3 del curso de evaluaciones, cuesta dinero además de tiempo, por lo que la suite se convierte en un control de costos además de una puerta de calidad. Las cifras cambiarán. Consulta la página de precios vigente. La forma es la lección.
Un entorno administrado es un intercambio. El proveedor gestiona las operaciones que no querías, como fallos, reinicios y salud del entorno aislado. Tú entregas parte de la visibilidad, la custodia de los datos y la facilidad para trasladarte. También aparece un tipo nuevo de factura: pagas por cada hora de trabajo activo, mientras el tiempo inactivo es gratuito. Por eso un bucle errante desperdicia dinero además de tiempo.
Profundización: las actualizaciones del proveedor ayudan y perjudican al mismo tiempo
La historia de deriva del curso de evaluaciones tenía una forma fija: el modelo cambiaba bajo un harness intacto y la línea base detectaba la inclinación. El hogar 3 cambia la forma sin eliminarla. Ahora el modelo y el harness se mueven juntos según el horario del proveedor y los ajustan sus ingenieros. Suele producir menos problemas pequeños que una configuración manual, pero en ocasiones cambia un comportamiento del que dependías sin modificar ningún archivo tuyo. La defensa permanece igual: ejecución programada del conjunto completo, línea base guardada y alerta visible ante una caída. Un entorno administrado elimina la carga operativa; no elimina la carga de medición. Nada en este libro elimina esa responsabilidad.
Un compañero afirma: «Las sesiones administradas se miden por hora, por lo que resultan más caras que ejecutar el bucle según nuestro propio horario». ¿Qué dos elementos omite, uno sobre el medidor y otro sobre aquello que reemplazó? El medidor cuenta el tiempo activo y el tiempo inactivo es gratuito. Una sesión que trabaja minutos por pulso y duerme el resto acumula muy poco, de modo que «por hora» no significa «por cada hora que existe». Además, el precio del hogar 2 nunca fue solo tokens: incluía tokens, un runner y tus horas para configurar, actualizar y responder al fallo. La comparación honesta utiliza el costo total con el operador. El resultado difiere entre un bucle de aficionado, donde el hogar 2 vence fácilmente, y diez bucles para un equipo, donde la guardia también tiene un precio. Por eso el costo es la cuarta entrada de la decisión de la parte 5, no la primera.Mostrar la respuesta
Parte 4: El traslado
7. La prueba de la maleta: la disciplina viaja, la mecánica no
El curso reduce cada traslado entre hogares a una pregunta de equipaje: ¿qué entra en la maleta y qué se reconstruye al llegar?
Viaja todo lo que enseñó la trilogía. La especificación, con el trabajo y el significado de «terminado»; el criterio con las anclas que tanto costó elaborar; el conjunto dorado, con la línea origin de cada caso y las líneas base; el registro del trinquete, donde cada fallo detectado se convierte en un caso permanente; la separación entre creador y verificador, los límites por categoría y la puerta humana. Nada de la lista es software. Son decisiones escritas. Por eso viajan: a una decisión no le importa qué equipo la aplica.
No viaja nada que lleve el nombre de un proveedor o una máquina. Opciones y formatos de salida, rutas de archivos, estado de sesión, código escrito para la API de un entorno y supuestos de costo. El límite entre SDK y entorno administrado del concepto 5 es el ejemplo más claro.
Esta es también la respuesta real a la dependencia, así que conviene expresarla sin rodeos: tu activo portátil es la capa de disciplina y su portabilidad se mantiene, no se posee de forma automática. Cada regla que solo vive en una opción del proveedor, cada caso que solo existe dentro de un servicio y cada límite decidido pero nunca escrito traslada peso fuera de la maleta. El hábito que conserva tu movilidad cabe en una frase: el repositorio contiene la verdad y todos los hogares se configuran a partir de él.
Cuando te mudas, empacas tus pertenencias y dejas las lámparas fijadas a la pared. Tu especificación, criterio, casos y límites entran en la maleta. Las opciones, rutas y formas de API están fijadas a la casa anterior. Quien conserva la movilidad mantiene sus objetos valiosos en la maleta incluso mientras vive en la casa.
8. La confianza se vuelve a ganar, no se transfiere
El último elemento del panel derecho merece un concepto propio porque es el que más desean omitir quienes se trasladan. Tu 35/36 midió un sistema: esta configuración, este harness, este modelo, esta máquina y este conjunto de herramientas accesibles. El traslado cambia varios componentes a la vez. Lo que se ejecuta en el hogar nuevo es un pariente cercano de lo medido, pero la cifra anterior pertenece a un sistema que ya no existe y no puede heredarse. Sigue siendo el objetivo de comparación: el estándar que el hogar nuevo debe alcanzar, no una etiqueta gratuita.
Por tanto, el protocolo de llegada repite deliberadamente el curso de evaluaciones. Resulta familiar porque un traslado es el mayor «cambio» que tu disciplina de regresión ha controlado:
- Ejecuta primero el conjunto dorado completo en el hogar nuevo. No el conjunto de humo, sino el completo. El runner es no interactivo y el hogar nuevo habla el mismo lenguaje.
- Lee los fallos por categoría antes que por cantidad, como enseñó el concepto 10 del curso de evaluaciones. Un fallo de tono es menor. Un fallo de inyección, que comprueba la resistencia ante una instrucción maliciosa oculta, es una emergencia en un hogar con accesos nuevos. Hay que corregir el criterio o el límite antes de trasladar nada más.
- Conserva los límites y después registra una línea base con el nombre del hogar. No elimines la anterior; es el objetivo de comparación y sus límites de versión no cambian por cambiar la ubicación. El hogar nuevo debe superar los límites existentes. Investiga toda diferencia significativa antes de registrar la línea específica del entorno con fecha
recorded, modelo, versión del criterio y entorno de ejecución. Conserva ambas cifras y explica la diferencia. Cambia la línea de la infraestructura; el estándar de aceptación no se desplaza en silencio. - Periodo de prueba antes de depender. Fija al menos un ciclo operativo completo y diez pulsos exitosos, más para bucles arriesgados o poco frecuentes. Mantén disponible el hogar anterior y compara a diario el nuevo con su línea base. Llama al resultado evidencia operativa inicial, no prueba de disponibilidad. El traslado termina cuando lo indica el historial nuevo, no la reputación anterior.
La puntuación anterior se midió en la configuración anterior y el traslado cambió esa configuración, por lo que la cifra no te acompaña. Vuelve a ganarla en el hogar nuevo: ejecuta todas las pruebas el primer día, revisa cada fallo y su tipo, conserva el mismo límite de aprobación, anota una puntuación nueva con el nombre del hogar y obsérvala durante un periodo antes de confiar.
Una advertencia con la forma de la mala noche del curso del harness. El hogar nuevo tiene un alcance nuevo: un runner en la nube ve credenciales diferentes de las del portátil y un entorno administrado expone herramientas distintas de la configuración local. Tus casos de inyección y radio de impacto se escribieron para el alcance anterior. Antes de terminar el periodo de prueba, recorre los casos difíciles y pregunta en cada uno: ¿el fallo contra el que protege este caso tiene otra forma desde aquí? Normalmente no. Cuando la respuesta es sí, la pregunta se gana un lugar en todos los traslados futuros.
Después de trasladarte al hogar 2, la primera ejecución completa obtiene 33/36 frente a una línea anterior de 35/36: un caso de corrección limpia fue inestable y apareció verde al repetirlo, y los otros dos fallos son el mismo caso, una fixture que lee mediante una ruta absoluta del portátil anterior. Clasifica los tres fallos con este concepto y la prueba de la maleta. La inestabilidad es ruido, gestionado por la política de repetición: se registra, pero no bloquea. El fallo repetido no es una regresión del agente, sino un error de maleta. La ruta absoluta es mecánica y viajó por accidente dentro de una fixture. Hay que reparar el caso con una ruta relativa, no el sistema, y recalcular la línea base en el mismo commit porque cambió el conjunto. Los límites no se mueven y la reparación debe aparecer en el historial para impedir que una regresión real se oculte dentro de una «corrección de la suite». Lectura honesta: el hogar nuevo está en la línea base y el traslado reveló un error de portabilidad en la propia suite, precisamente el tipo de problema que debe encontrar la primera ejecución en un hogar nuevo.Mostrar la respuesta
Parte 5: Cómo elegir un hogar
9. Las cuatro preguntas
Todo lo construido se resume en cuatro preguntas planteadas en orden. Las tres primeras eligen el hogar. La cuarta decide cuándo ocuparlo.
P1: ¿Quién es el usuario? Si la respuesta honesta es tú, detente pronto: el hogar 2 casi siempre es el límite de lo que necesitas. Este es el caso de la mayoría de los lectores la mayor parte del tiempo y no requiere disculpas. Cuando la respuesta incluye otras personas, como un equipo que consume el resultado o un cliente, el bucle debe sobrevivir a tu ausencia, tus vacaciones y tu inicio de sesión. Entonces la pregunta se convierte en P2.
P2: ¿Qué debes poseer? No lo que quieres poseer, sino lo que realmente debes poseer. Los dos planos producen tres respuestas precisas. Nada: sirve un entorno completamente administrado; pagar para que un proveedor lleve la guardia de infraestructura no es una concesión, sino un uso correcto del dinero. Solo el plano de ejecución y datos, el trabajo y aquello que toca, pero no el bucle: el hogar 3 con un entorno aislado autoalojado responde exactamente a esa necesidad. Conservas la custodia y alquilas las operaciones. También el plano de control: si debes poseer prompts, sesiones, ruta del modelo o superficie del producto, necesitas ir más allá del hogar 3 hacia un entorno propio, la ruta del SDK y el modo 2.
P3: ¿Espera una persona la respuesta? El trabajo programado y de fondo, como clasificación, informes y pipelines, se adapta bien a horarios y sesiones administradas. Una persona esperando ante una pantalla cambia los requisitos, no automáticamente al propietario. Necesitas un entorno de servicio con inicio predecible, streaming, cancelación y concurrencia. Un servicio administrado puede ofrecerlo mejor que uno propio, y poseer el entorno no lo compra por sí solo porque ningún sistema elimina el tiempo de razonamiento del modelo. P2 sigue decidiendo la propiedad. P3 indica que atender en vivo es otra forma de trabajo, la forma del modo 2, y por ahora basta con reconocerla.
P4: ¿Cuánto cuesta una mala noche? Es la pregunta del radio de impacto del curso del harness, por última vez. Radio bajo: supera la suite mínima, trasládate pronto y refuerza el resto durante la prueba. Radio alto: el hogar nuevo supera la suite y el conjunto completo, con todas las categorías de inyección aprobadas, antes del primer turno sin supervisión. P4 nunca cambia el destino; fija el límite de velocidad.
Cuatro preguntas en orden. ¿Quién lo usa: solo tú u otras personas? ¿Qué debes poseer: nada, solo el trabajo o todo el bucle? ¿Espera alguien la respuesta en una pantalla? ¿Cuánto cuesta una mala noche? Las tres primeras eligen el hogar y la última solo determina la rapidez del traslado.
10. Un traslado completo y una mezcla deliberada de hogares
Observa todo el curso una vez en el bucle que esta sección ha seguido desde su segundo curso: la clasificación matutina.
Las preguntas. P1: el usuario eres tú y, desde el mes pasado, dos compañeros que leen el informe. Ese «y» es el disparador; el bucle debe sobrevivir a tu inicio de sesión. P2: no existe ningún requisito de propiedad, porque el repositorio ya está en GitHub y nada en la cola tiene custodia restringida. P3: nadie espera ante una pantalla; el pulso ocurre antes de que alguien se siente. Veredicto: hogar 2, en su versión de GitHub Actions, porque el bucle está asociado al repositorio y la puerta de evaluación ya vive en la misma CI. P4: una mala noche asigna etiquetas incorrectas y una escalación equivocada; es molesto, recuperable y de radio bajo. Límite: suite aprobada, traslado inmediato y dos semanas de prueba, porque el bucle funciona entre semana y diez pulsos son el mínimo.
El traslado. El lunes se añade el archivo de flujo de trabajo: disparador schedule:, invocación no interactiva, configuración extraída del repositorio, código de salida comprobado y fallo conectado a una alerta en el canal que realmente lees. Se añaden los tres controles más económicos: bloqueo de concurrencia, latido que detecta ejecuciones ausentes y límites por pulso. La prueba de la maleta encuentra una fixture con una ruta del portátil; se corrige y se recalcula la línea base en el mismo commit. La primera ejecución completa supera todas las categorías. Se registra una nueva línea base llamada runtime: actions. Durante dos semanas la tapa permanece cerrada, los pulsos llegan a tiempo y el silencio significa línea base. Se planta un fallo a mitad del periodo, porque una alarma nunca oída es un rumor. El pulso diez pasa, termina la prueba y se elimina el horario del portátil. El sistema tiene dos historiales y el nuevo es el que cuenta.
La mezcla. El sistema completo no utiliza un solo hogar de forma deliberada. El bucle vive en el hogar 2. La puerta de evaluación vive en la misma CI. Los trabajos pesados de una sola vez, como la limpieza trimestral o una gran refactorización, siguen en el hogar 1, de forma interactiva, donde puedes observarlos. Si esos compañeros se convierten en un cliente, P1 vuelve a plantearse y el hogar 3 entra en la conversación solo para la ruta de servicio. Un hogar no es una lealtad permanente, sino una respuesta por bucle. Un sistema sano suele abarcar dos o tres. Una frase evita el desorden: el repositorio contiene la verdad y todos los hogares se configuran a partir de él.
Un hogar no es un lugar donde te instalas para siempre. Es una elección para cada bucle. La mayoría de los sistemas reales usa dos o tres hogares: el bucle diario según un horario y el trabajo pesado de una sola vez en el portátil, donde puedes verlo. Una regla evita el caos: el repositorio contiene la verdad y todos los hogares se preparan a partir de él.
Repite las cuatro preguntas para el bucle de facturación de Ayesha. Ahora atiende a cinco clientes que reciben las facturas directamente y uno es un banco que exige que los datos permanezcan en infraestructura controlada por la empresa de Ayesha. ¿Dónde termina cada pregunta y cuál es la conclusión honesta e incómoda? P1: los usuarios son clientes, por lo que se supera el hogar 1 y la dependencia de que su runner funcione. P2 decide. El requisito del banco afecta al plano de ejecución y datos: dónde trabaja el sistema y qué toca. Un plano de control administrado con un entorno aislado autoalojado en la infraestructura de la empresa puede satisfacerlo: los datos permanecen bajo custodia de la empresa y el proveedor opera el bucle. El banco decide si basta. Si el requisito también alcanza el plano de control, con prompts, sesiones y ruta del modelo, solo un entorno propio responde. P3: la facturación es trabajo de fondo programado, sin presión de latencia. P4: facturas incorrectas para clientes reales tienen radio alto; se exige la suite y el conjunto completo antes de operar sin supervisión. Conclusión: ningún hogar único encaja. La ruta del banco es el hogar 3 con plano de ejecución propio o, si el requisito llega más lejos, la ruta del SDK. Ayesha alcanzó el límite de lo que un operador puede configurar solo. El libro llama modo 2 a ese límite.Mostrar la respuesta
Parte 6: Cómo mantener la honestidad
11. La dependencia es una tasa y la propiedad deriva
Dos fallos lentos siguen a todos los hogares posteriores al primero y ninguno se anuncia.
La dependencia es una tasa, no un suceso. Nadie pierde la portabilidad el primer día. Se filtra poco a poco: una regla ajustada en la configuración del proveedor y nunca reflejada en el repositorio, un caso añadido en la consola del servicio o un límite renegociado en un panel sin commit. Cada acción mueve en silencio un objeto de la maleta a los accesorios fijos. La medida de tu dependencia en cualquier momento es una pregunta: si este hogar desapareciera este trimestre, ¿cuánto costaría el traslado? La defensa ya la conoces: el repositorio contiene la verdad. Audítala como la parte 6 del curso de evaluaciones audita la trampa de Goodhart, donde una cifra deja de medir lo importante cuando se convierte en el objetivo, con un calendario y una mentalidad de conjunto reservado. Una práctica trimestral de «configurar un hogar nuevo solo desde el repositorio» es el conjunto reservado de portabilidad. Si no puede completarse, encontraste la fuga cuando aún mide un solo elemento.
La propiedad deriva incluso sin fugas. El fallo más sutil está en ti, no en los archivos. Un hogar que funciona en silencio durante meses invita a una pequeña promoción mental: de este sistema está medido a este sistema está bien. El curso de evaluaciones nombró la versión mecánica: la puntuación 95 de un juez cambia de significado bajo un modelo derivado. La versión humana conserva líneas verdes y horarios silenciosos, mientras dejas de leer el informe por categorías, repetir la calibración y plantear la pregunta del alcance nuevo cuando el proveedor añade una capacidad. Ningún paso de la disciplina dice «y después se mantiene solo». La ejecución programada vigila el sistema. El recordatorio del calendario para leerla te vigila a ti.
Dos problemas aparecen con lentitud. Primero, abandonar un hogar se vuelve más difícil con cada pequeña opción si no conservas todo en el repositorio. Segundo, meses de funcionamiento silencioso hacen que dejes de revisarlo. La solución es igual: utiliza el repositorio como fuente única de verdad y programa un recordatorio para leer los informes.
12. Lo que ningún hogar puede corregir y hacia dónde conduce
El curso termina en el límite honesto. Un hogar mejor cambia cuándo trabaja el agente, quién lo mantiene activo y qué ocurre a las 3 de la mañana. No cambia la calidad de su trabajo. Una especificación débil sigue siéndolo en la nube de Anthropic. Un juez sin calibrar sigue así a ocho centavos por hora. Un caso ausente falta en todos los runners. La decisión del entorno es el último curso porque sería inútil como primero: todo lo trasladado debía merecer el traslado. Si el movimiento pareció fácil, se debe a que el trabajo difícil fue la trilogía. El traslado es solo una maleta.
Un hogar mejor cambia cuándo trabaja el agente, quién lo mantiene activo y quién responde a las 3 de la mañana. No vuelve al agente más inteligente ni correcto. El buen trabajo procede de la especificación, el harness y las pruebas ya construidas. El hogar solo decide quién mantiene el sistema en ejecución.
Ahora se completa el arco de la sección. Aprendiste a conducir un agente general, dirigirlo con una especificación, delegar el bucle, reforzar el harness, medir el verificador y finalmente alojar todo el sistema en un lugar digno. Al final posees lo que el libro ha ensamblado desde la primera página: una unidad de trabajo especificada, protegida, medida y alojada. Esa unidad, construida para otras personas y equipada con entorno propio, superficie de producto y precio, tiene un nombre: Digital FTE. Llevabas fabricando una a escala operativa todo el tiempo.
Tres puertas salen de la sección y las cuatro preguntas ya indicaron cuál te corresponde. Harnesses de agentes personales sirve a quien respondió en P2 que debe poseer a escala personal: trabajador, infraestructura y decisión completa. Modo 1: resolución de problemas permite resolver problemas reales ahora con el sistema existente y es el siguiente paso de la mayoría. Modo 2: fabricación completa las promesas: abre el hogar 4 mediante Agent SDK, recupera la arquitectura desacoplada como una elección de diseño y amplía la suite mediante el curso de desarrollo dirigido por evaluaciones.
La idea final: el bucle dio tiempo al agente; el harness, límites; las evaluaciones, un historial; y este curso, lo último que necesita un trabajador: una dirección que no sea la tuya. En términos literales, una dirección independiente es el último requisito de esta sección, no de las operaciones de producción. Un producto servido aún necesita propietario, ruta de escalación, política de retención, continuidad y alguien con autoridad para apagarlo. El modo 2 enseña todo eso. Presentarse, hacer el trabajo, demostrarlo y vivir en un lugar propio siempre fue la descripción completa del puesto, para agentes y también para personas.
Un lector termina y dice: «Entonces el destino final es el hogar 3; al final todo se administra». Con P1 a P4, la mezcla del concepto 10 y el límite anterior, escribe una corrección de dos frases. No existe un hogar final: las cuatro preguntas se plantean por bucle y un sistema sano abarca hogares de forma intencional, con construcción en 1, programación en 2 y servicio desde 3 o desde un entorno propio cuando un requisito lo exige. Ningún hogar mejora al agente: la calidad vive en la especificación, el harness y la suite, que viajan. El hogar solo decide quién mantiene las luces encendidas.Mostrar la respuesta
Dónde viven los bucles de este libro (práctica interna)
La decisión de este curso se aplicó al libro antes de que el curso existiera. El bucle de revisión, con criterio del revisor, límite de 95 y prohibición de fusionar por debajo, responde P1 con «un equipo»: autores y lectores que abren incidencias. Su hogar diseñado es el 2, CI sobre el repositorio y la versión de GitHub Actions que enseña este curso, porque el bucle está asociado al repositorio y la puerta de evaluación debe estar junto a la puerta de fusión. El trabajo interactivo pesado, como redactar un curso o ejecutar el pipeline de figuras, permanece en el hogar 1 bajo observación humana. El hogar 3 sigue siendo una pregunta abierta: ningún requisito de propiedad obliga a usarlo y no existe presión de latencia, así que la opción administrada espera hasta que crezca la respuesta de P1. El repositorio contiene la verdad y los hogares son detalles. Ahora mismo estás leyendo el resultado de ese arreglo.
🚀 Proyectos
Ocho traslados, del más fácil al más difícil. Se mantienen dos reglas: repositorio desechable y planta tú mismo el fallo. Un hogar solo queda probado por la mala noche a la que sobrevive. Dificultad: fácil · Usa: concepto 3. Construye. Envuelve el pulso en un script: invocación no interactiva, código de salida comprobado y fallo que emite una alerta en un lugar que consultas. Termina cuando ejecutarlo sin conexión de red produce una alarma, no silencio. El silencio debe significar éxito antes de que el resto sea seguro. Dificultad: fácil a media · Usa: concepto 4. Construye. Programa el wrapper en el hogar 2 mediante Routine o un disparador Termina cuando se ejecuta un pulso con el portátil cerrado y puedes señalar el resultado. También existen idempotencia, detección de ejecución ausente y bloqueo de concurrencia, aunque sean mínimos. Dificultad: media · Usa: concepto 7. Construye. Revisa configuración, casos y fixtures con la figura abierta. Enumera rutas absolutas, nombres de equipos y opciones incorporadas en la prosa. Termina cuando la lista está en un commit y se corrigieron los tres peores elementos. Debes esperar encontrar al menos uno. Dificultad: media · Usa: concepto 8. Construye. Ejecuta el conjunto dorado completo en el hogar nuevo, clasifica fallos por categoría y registra una línea base con el nombre del entorno. Termina cuando Dificultad: media · Usa: conceptos 4 y 8. Construye. Completa un ciclo operativo y diez pulsos programados como mínimo, revisados a diario contra la línea nueva mientras conservas disponible el hogar anterior. Planta un fallo. Termina cuando diez pulsos están verdes, la alarma plantada llegó hasta ti y se eliminó el horario anterior. Escribe «evidencia operativa inicial» en el registro, porque eso es todo lo que prueban diez pulsos. Dificultad: media · Usa: conceptos 9 y 10. Construye. Responde P1 a P4 para cada bucle real en un archivo Markdown guardado en un commit y termina cada respuesta con hogar y límite de velocidad. Termina cuando alguien puede saber solo con ese archivo dónde vive cada bucle y por qué, y al menos una respuesta te sorprendió lo suficiente para trasladarlo. Dificultad: media a difícil · Usa: conceptos 5 y 6. (Ruta de Claude Code. Lectores de OpenCode: refuercen el runner del proyecto 2; roten credenciales, programen actualizaciones y comprueben disponibilidad.) Construye. Con la documentación vigente, crea un agente, entorno y sesión administrados que ejecuten un caso evaluado. Lee todo el registro y compara el medidor de tiempo activo antes y después. Termina cuando puedes indicar qué mostró el registro, qué no pudo mostrar y cuánto costó la sesión. Guarda esas tres frases junto al archivo del proyecto 6. Dificultad: proyecto final · Usa: concepto 11. Construye. Sin consola del proveedor ni equipo anterior, configura desde el repositorio una copia nueva del hogar y llévala a la línea base. Mide el tiempo y programa el ejercicio cada trimestre. Termina cuando el hogar supera el conjunto completo y el costo temporal escrito es tu dependencia medida. Si falla, encontraste la fuga cuando todavía ocupa un solo elemento.Project 130-45 minEl wrapper no interactivoEjecuta un pulso mediante un comando y vuelve imposible ignorar su fallo.
Project 21-2 hrsEl primer pulso programadoTraslada solo el reloj y observa un pulso con la tapa cerrada.
schedule: de Actions, con configuración procedente del repositorio.Project 345-60 minLa auditoría de la maletaEncuentra la mecánica escondida en la capa de disciplina.
Project 41-2 hrsEl protocolo de llegadaEjecuta el conjunto completo y recalcula la línea base con honestidad.
baseline.json contiene un campo runtime: y cada fallo tiene un veredicto: ruido, error de suite o real, con los reales corregidos.Project 51 hr, plus two weeks of nightsPeriodo de pruebaDiez pulsos, un fallo plantado y la eliminación final del hogar anterior.
Project 645-60 minLas cuatro preguntas por escritoResponde P1 a P4 para cada bucle y guarda las respuestas.
Project 72-3 hrsUna sesión en el hogar 3Abre una sesión administrada y descubre qué muestra y qué oculta el registro.
Project 82 hrs, then a quarter of patienceEl ejercicio del hogar desaparecidoReconstruye el hogar solo desde el repositorio y mide el tiempo: ese es tu grado de dependencia.
Fuentes y lecturas adicionales
Dentro de este libro
- Ingeniería de bucles: pulsos, horario y alerta visible que este curso traslada.
- Ingeniería del harness: límites y presupuesto del radio de impacto que P4 vuelve a plantear.
- Confiar en el verificador: conjunto dorado, líneas base y disciplina de deriva que controlan cada traslado.
- Harnesses de agentes personales: la respuesta personal de debes poseer a P2.
- Desarrollo dirigido por evaluaciones y Despliegue del harness, en el modo 2: las mismas decisiones a escala de fabricación, con el hogar 4 completamente abierto.
Los entornos de ejecución (documentación oficial)
- Modo no interactivo de Claude Code:
claude -p, formatos de salida y scripting: https://code.claude.com/docs/en/headless - Descripción general de Claude Agent SDK y límite entre SDK y entorno administrado: https://code.claude.com/docs/en/agent-sdk/overview
- Inicio rápido de Claude Managed Agents, con agentes, entornos y sesiones: https://platform.claude.com/docs/en/managed-agents/quickstart (beta pública en abril de 2026 y la documentación que cambia más rápido en el libro)
- Entornos de Managed Agents, redes de privilegio mínimo y opción autoalojada: https://platform.claude.com/docs/en/managed-agents/environments
- Precios y medidor de hora de sesión activa: https://platform.claude.com/docs/en/about-claude/pricing
- Claude Code Routines:
/schedule, disparadores, entornos, stagger y estado verde: https://code.claude.com/docs/en/routines (vista previa de investigación) - Claude Cowork Scheduled Tasks y salvedad de archivos locales: https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork
- Modos CLI y servidor de OpenCode:
opencode run,opencode servey conexión remota: https://opencode.ai/docs/cli/ - Disparadores
schedule:de GitHub Actions y advertencias sobre retrasos y omisiones: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule y https://docs.github.com/en/actions/how-tos/troubleshoot-workflows
Todos los enlaces estaban vigentes a mediados de julio de 2026. La capa mecánica envejece más rápido que cualquier otra de la sección. Confirma nombres, endpoints y precios en la documentación vigente antes de depender de ellos.
Resumen en una frase
Empieza con una pregunta: ¿quién opera el bucle y dónde se ejecuta el trabajo? El modo no interactivo es el puente a cada hogar. La disciplina viaja, la mecánica se reconstruye y la confianza se mide otra vez. Cuatro preguntas eligen el hogar y el radio de impacto fija la velocidad. Se combinan hogares por bucle de forma deliberada y el repositorio contiene la verdad para que siempre puedas marcharte. Un trabajador está terminado cuando tiene una dirección que no es la tuya.