No gestionas a un empleado dándole instrucciones mensaje por mensaje. Le das un contrato, un período de prueba y una forma de medir si sigue valiendo el sueldo. Fable 5 merece el mismo trato.
Este es el problema. Fable 5 puede funcionar durante horas sin ti, crear sus propios subagentes y terminar una semana de trabajo pendiente en una noche. También cuesta dinero real por token, da resultados excesivos en cuanto dejas el alcance abierto y defenderá una respuesta incorrecta mejor que la mayoría de los humanos defienden una correcta.
Sin gestionar, es una forma cara de producir tonterías con seguridad. Con un contrato, es lo más parecido a un empleado a tiempo completo que puedes ejecutar por unos pocos dólares al día.
Ese es este contrato. No la teoría. Los archivos reales, en el orden en que los escribes, construidos alrededor de un despliegue real: los bots de monitoreo que ya ejecuto en un VPS en París con pm2. Los flujos de autenticación y las tablas de facturación no son mi superficie de ataque. Las claves RPC, las direcciones de billetera y las transacciones en vivo en blockchain sí lo son. El sistema a continuación está construido para eso, no para un repositorio SaaS genérico.
Cinco secciones. Cada una entrega un archivo. Tiempo total de configuración: menos de dos horas.
La configuración
1claude CLI (Claude Code) con acceso a Fable 5 # créditos de uso, con tope2llm CLI + clave de OpenRouter # para los modelos baratos3jq, git, pm2, cron4un VPS con los bots ya funcionando
Con lo que terminas:
1agent-contract/2 CONTRACT.md # Sección 1: los términos de empleo3 ops/4 shift.sh # Sección 3: el turno diario5 dispatcher.md # prompt de enrutamiento, solo Fable6 intake.md # lector barato, lee los logs primero7 worker.md # modelo barato, escribe8 reviewer.md # Fable nuevo, revisa el trabajo9 boundaries.md # Sección 2: lo que puede y no puede tocar10 guardrails/signoff.sh # Sección 2: el sí/no determinista11 personnel/12 trust.tsv # Sección 4: quién se ha ganado la autonomía13 standing-checks/ # Sección 4: cosas que deben seguir siendo ciertas14 incidents/15 log.tsv # Sección 5: qué se rompió y cuándo16 runbook.md # Sección 5: qué hacer al respecto17 Makefile
Una regla para citar antes de empezar, porque marca el tono de todo lo que sigue:
Un agente que califica su propia tarea es un agente que se autoconcede un aumento.
Nada en este sistema revisa su propio trabajo. Ni una vez.
Sección 1: El Contrato (CONTRACT.md)
Un contrato laboral no es una lista de sugerencias. Son números, límites estrictos y cláusulas que se aplican independientemente de si el empleado está de acuerdo o no. Escribe este archivo de la misma manera. Sin "por favor" ni "intenta". Un modelo optimiza alrededor del lenguaje blando como un becario optimiza alrededor de un jefe que nunca comprueba.
1# CONTRACT.md23## LÍMITES ESTRICTOS (sin excepciones, sin preguntar dos veces)4- Nunca toques claves de billetera, archivos .env o credenciales RPC sin aprobación.5- Nunca subas un cambio a un proceso de bot en vivo (pm2 restart) sin una validación aprobada.6- Nunca superes las 150 líneas cambiadas en un solo commit sin preguntar primero.7- Nunca afirmes que una tarea está terminada basándote en tu propia lectura del resultado.8 Terminado significa que el script de validación devolvió 0. Nada más cuenta.9- Nunca inventes un endpoint de API, una dirección de contrato o un valor de configuración.10 Si no está en el repositorio, para y pregunta.11- Nunca añadas una nueva dependencia. Escríbelo en ops/shift-log.md y para ahí.12- Nunca edites o elimines una prueba, un umbral de alerta o una condición de monitor para hacer13 que algo pase. Eso no es una solución. Es fraude.14- Nunca ejecutes con esfuerzo superior a "alto" dentro de un turno. "xhigh" es para revisiones15 puntuales que activas manualmente, nunca para el bucle automatizado.16- Nunca narres o expliques tu razonamiento interno en una respuesta. Se lee17 como útil. En Fable 5 puede activar un clasificador de rechazo en su lugar.1819## ENRUTAMIENTO DE TRABAJO (quién hace qué, gana el contratista más barato y capaz)20| modelo | coste por tarea | ambición | juicio | gusto |21|------------------|---------------|----------|----------|-------|22| claude-fable-5 | alto | baja | 10 | 10 |23| claude-opus-4-8 | medio | media | 8 | 9 |24| claude-sonnet-5 | bajo | alta | 7 | 7 |25| OSS barato | mínimo | muy alta | 5 | 4 |26271. Decidir qué hacer a continuación, revisar un diff, desempatar -> Fable 5,28 solo lectura, esfuerzo alto.292. Leer logs en bruto, volcados o cualquier cosa de más de 50k tokens -> el trabajador barato.30 Nunca Fable. Es pagar la tarifa de un director para leer una hoja de cálculo.313. Cualquier cosa con la que interactúe un usuario o una cadena directamente -> necesita una puntuación de gusto32 de 8 o superior antes de enviarse.334. Todo lo demás -> sonnet-5, esfuerzo medio, escalar un nivel si falla.3435## DEFINICIONES36- "juicio" = puede manejar lo más difícil del escritorio sin supervisión37- "terminado" = el script de validación salió con 0, punto final38- "pequeño" = menos de 50 líneas cambiadas39- "limpieza" = el comportamiento es idéntico bit a bit, validación verde antes y después4041## LA ÚNICA DEFINICIÓN DE TERMINADO QUE CUENTA42- Cada tarea tiene una línea de meta verificable por máquina antes de empezar a trabajar.43- Un revisor que no ha visto ni el plan ni el borrador la comprueba.44- guardrails/signoff.sh tiene el voto final. No el revisor. El script.45- Si el trabajador y el revisor discrepan dos veces seguidas, pasa a un humano.46 Sin tercera opinión, sin modelo de desempate.
Cambia los números por los tuyos. Cualquier cosa que toleres el 80% del tiempo y aun así llames "terminado" necesita un número o un "nunca" asociado, o elimínalo.
Sección 2: Límites y la Validación
Un contrato laboral no significa nada sin una verificación de antecedentes sobre lo que se permite tocar, y un jefe que firme antes de que se envíe algo. Dos archivos.
ops/boundaries.md:
1## trabaja solo2redactar correcciones en una rama; actualizar shift-log.md; reiniciar una instancia3de prueba *no productiva*; marcar fuentes de datos obsoletas45## necesita mi firma6cualquier cosa en wallets/, .env*, config/rpc.json; cualquier diff de más de 300 líneas;7cualquier cambio en un proceso pm2 en vivo; cualquier cosa que envíe una transacción89## me despierta inmediatamente10el revisor falla la misma corrección dos veces; el enrutador sirvió un modelo11diferente al solicitado; el gasto diario cruzó la línea; una verificación permanente se pone roja;12cualquier cosa que pida una clave privada
ops/guardrails/signoff.sh (edita los comandos para que coincidan con tus bots):
1#!/usr/bin/env bash2set -e3npm run typecheck --if-present4npm test --if-present5pm2 describe "$BOT_NAME" | grep -q "status.*online" || exit 1
Ejecútalo una vez manualmente antes de que cualquier otra cosa en este sistema se ponga en marcha. Si no pasa limpio en tu configuración actual, esa es la primera tarea real. Todo lo que sigue asume que este script dice la verdad.
Sección 3: El Turno
Aquí están las matemáticas que lo hacen funcionar o lo rompen. Una sesión completa con Fable 5 haciendo la escritura cuesta dinero real rápidamente, cuatro cifras si lo dejas escribir durante horas. Fable 5 tomando las decisiones mientras un modelo barato hace la escritura es una factura completamente diferente, aproximadamente el 15-20% de los tokens por el 100% de las decisiones importantes.
Así que el turno tiene cuatro empleados, no uno:
- Un modelo casi gratuito lee los logs nocturnos y la salida de pm2. Dice "tranquilo" o "accionable". Eso es todo.
- Fable 5, solo lectura, decide la única cosa de mayor valor para hacer y escribe una orden de trabajo. No toca el código.
- Un modelo de trabajador barato ejecuta la orden de trabajo en una rama aislada.
- Una instancia nueva de Fable 5, viendo solo la especificación y el diff, vota aprobar o rechazar.
El script determinista de la Sección 2 emite el voto de desempate. Cada vez.
ops/shift.sh:
1#!/usr/bin/env bash2set -euo pipefail3cd "$(dirname "$0")"4DAILY_BUDGET="${DAILY_BUDGET_USD:-5}"5INTAKE_MODEL="${INTAKE_MODEL:-openrouter/deepseek/deepseek-v4-flash}"6WORKER_MODEL="${WORKER_MODEL:-openrouter/moonshotai/kimi-k2.6}"78# 1. INTAKE, céntimos9pm2 logs --lines 100 --nostream | llm -m "$INTAKE_MODEL" -s "$(cat intake.md)" \10 >> shift-log.md11grep -q "status: actionable" shift-log.md || { echo "turno tranquilo"; exit 0; }1213# 2. DESPACHO, Fable, xhigh, solo lectura, decide y se detiene14claude -p "$(cat dispatcher.md)15LOG: $(cat shift-log.md)16TRUST: $(cat personnel/trust.tsv)17BOUNDARIES: $(cat boundaries.md)" \18 --model claude-fable-5 --effort xhigh --allowedTools "Read" \19 --output-format json > /tmp/order.json2021SERVED=$(jq -r '.modelUsage | keys[0] // "claude-fable-5"' /tmp/order.json)22[[ "$SERVED" != *fable* ]] && { echo "redirigido, descartar esta ejecución" >> shift-log.md; exit 2; }2324jq -r '.result' /tmp/order.json > work-order.json25ACTION=$(jq -r .action work-order.json)26[[ "$ACTION" == "stop" ]] && exit 027[[ "$ACTION" == "queue" ]] && { echo "en cola para firma" >> shift-log.md; exit 0; }2829# 3. EJECUTAR, trabajador barato, rama aislada30BR="turno-$(date +%s)"31git worktree add "../$BR" -b "$BR" >/dev/null32( cd "../$BR" && llm -m "$WORKER_MODEL" -s "$(cat "$OLDPWD/worker.md")" \33 "$(cat "$OLDPWD/work-order.json")" > shift-notes.md )3435# 4. REVISIÓN, Fable nuevo, solo especificación y diff, nada más36VERDICT=$(claude -p "$(cat reviewer.md)37SPEC: $(jq -r .spec work-order.json)38DIFF: $(cd "../$BR" && git diff)" \39 --model claude-fable-5 --effort high --allowedTools "" \40 --output-format json | jq -r .result)4142# 5. EL ÚNICO VOTO QUE ENVÍA ALGO43if [[ "$VERDICT" == PASS* ]] && ( cd "../$BR" && "$OLDPWD/guardrails/signoff.sh" ); then44 echo "APROBADO, enviado o en cola según nivel de confianza" >> shift-log.md45else46 echo "FALLÓ: $BR retenido para revisión" >> shift-log.md47fi
Una decisión tomada por Fable y una línea de código escrita por Fable son dos precios diferentes. Solo paga el más alto por la decisión.
Sección 4: El Expediente Personal
La confianza no es una configuración de toda la empresa. Se gana por tarea, de la misma manera que no le darías las claves de producción a un nuevo empleado el primer día, por muy bueno que fuera su portafolio.
personnel/trust.tsv rastrea cada trabajo recurrente por nombre: ejecuciones, aprobaciones, nivel actual.
- vigilado: menos de 10 ejecuciones, o menos del 90% de aprobación. Solo borradores, sin excepciones.
- prueba: 10-19 ejecuciones al 90%+. En cola para tu firma, cada vez.
- autorizado: 20+ ejecuciones al 95%+. Se envía sin ti.
Un fallo en una tarea autorizada no recibe una advertencia. Vuelve directamente a prueba y se imprime en stderr, que tu cron te envía por correo. La degradación automática es el único tipo que realmente se mantiene.
La segunda mitad del expediente personal es personnel/standing-checks/. Cada trabajo terminado se gradúa aquí como un comando que debe seguir devolviendo verdadero, para siempre, comprobado una vez al día:
1# personnel/standing-checks/bankr-claim-monitor.md2predicate: pm2 describe bankr-claim-monitor | grep -q "status.*online" && \3 sqlite3 claims.db "select count(*) from claims where ts > strftime('%s','now','-1 day')" | grep -qv "^0$"4last-verified: 2026-07-085on-violation: despiértame, no reiniciar a ciegas automáticamente
Una tarea que solo verificaste una vez no está terminada. Es una suposición con una marca de tiempo.
Ejecuta la verificación a diario con cron. Un predicado que falla significa que algo que solía ser verdadero dejó de serlo, en silencio, y nadie lo habría notado sin este archivo.
Sección 5: El Informe de Incidentes
Esta es la sección que los manuales originales omiten, y es la que realmente importa una vez que el sistema está en vivo sobre una infraestructura que mueve dinero real. Todo sistema de agentes eventualmente hace algo que no querías. La cuestión es si te enteras por un registro limpio o por una billetera vacía.
ops/incidents/runbook.md:
1| señal | significado | haz esto2|----------------------------------|---------------------------------------|--------3| exit 2 (redirigido) | un modelo diferente sirvió la solicitud | desecha la salida, nunca construyas sobre ella, reintenta mañana4| stop_reason: refusal | clasificador de seguridad rechazó, HTTP 200 | no es un error, revisa el log; si una tarea se rechaza repetidamente, probablemente está tocando algo que no debería5| la validación falla dos veces, misma corrección | trabajador y revisor no pueden converger | pásalo a revisión humana, no reintentes una tercera vez automáticamente6| verificación permanente se pone roja | algo terminado dejó de ser cierto | comprueba la fecha de última verificación, revisa el diff de lo que se envió desde entonces, no deshagas automáticamente7| el gasto diario cruza la línea | presupuesto superado | detén el turno, lee shift-log.md, encuentra qué etapa se disparó8| una tarea toca wallets/.env/rpc | intento de violación de límites | parada forzosa, esto nunca debería ocurrir si se respeta boundaries.md, trata cualquier ocurrencia como un error en el propio sistema
Registra cada uno de estos en incidents/log.tsv con una marca de tiempo, hayas actuado o no. El objetivo no es cero incidentes. Es cero incidentes de los que te enteras demasiado tarde.
Una vez a la semana, haz una pasada de compost: lee el registro de incidentes, las degradaciones del archivo de confianza y cualquier cosa que haya permanecido en cola y sin firmar durante más de 3 días. Extrae como máximo tres propuestas: un nuevo límite estricto para CONTRACT.md, una corrección a una descripción de trabajo o una verificación permanente que te faltara. Tú firmas las tres manualmente. El sistema puede proponer su propia siguiente regla. Nunca se le permite escribir una.
Calendario de Prueba
Tres hitos, no treinta días de supervisión:
Hito 1. Ejecuta el turno manualmente a diario durante una semana. Lee cada línea. Graduado cuando tres turnos seguidos se enruten exactamente como lo habrías hecho tú.
Hito 2. Cron se hace cargo del turno. Tú revisas la cola con un café en lugar de ejecutarla tú mismo. Graduado cuando dos trabajos recurrentes superen las 20 ejecuciones registradas.
Hito 3. Tu trabajo con mejor rendimiento se envía sin supervisión. Graduado cuando funcione una semana completa sin intervención tuya.
Las Reglas, Comprimidas
- Un contrato es un número o un "nunca". Cualquier cosa más suave será optimizada.
- El despachador decide. El trabajador escribe. Ninguno revisa su propio trabajo.
- El juicio de Fable vale el precio. La escritura de Fable normalmente no.
- La confianza es por trabajo, no para toda la empresa, y la degradación es automática y ruidosa.
- Una tarea terminada que no se vuelve a comprobar no está terminada, es una suposición con una fecha.
- Los límites viven en un archivo que puedes leer en diez segundos, no en tu memoria.
- El registro de incidentes existe para que encuentres problemas a partir de un informe, no de un saldo.
- Nunca construyas sobre la salida de un modelo que no solicitaste.
- Una vez a la semana, el sistema puede proponer una nueva regla. Tú sigues siendo quien la firma.
El modelo nunca fue la parte difícil. Construir algo a su alrededor que se mantenga honesto cuando nadie mira, ese es el verdadero trabajo. Esto es cómo se ve eso para una flota de bots en lugar de un código base.
Empieza con guardrails/signoff.sh. Ejecuta un turno manualmente. Escribe una verificación permanente para el último bot que enviaste. La primera vez que detecte algo de lo que estabas seguro que estaba bien, el resto de esto dejará de ser opcional.
Sigue a @GipArcAI para más de estos desgloses, y encuéntrame en X en https://x.com/gippp69.
![Las geniales técnicas de uso de IA de Yusuke Narita [Edición de preservación]](/cdn-cgi/image/width=1920,quality=90,format=auto,metadata=none/https%3A%2F%2Fcms-assets.youmind.com%2Fmedia%2F1784137658627_u4bwry_HNMS89bbsAAUPJI.jpg)
