Non gestisci un dipendente scrivendogli comandi un messaggio alla volta. Gli dai un contratto, un periodo di prova e un modo per misurare se vale ancora lo stipendio. Fable 5 merita lo stesso trattamento.
Ecco il problema. Fable 5 può funzionare per ore senza di te, creare i propri sotto-agenti e finire una settimana di arretrato in una notte. Costa anche soldi veri per token, fa il lavoro in eccesso non appena lasci lo scopo aperto e difenderà una risposta sbagliata meglio di quanto la maggior parte degli umani difenda una risposta giusta.
Lasciato senza gestione, è un modo costoso per produrre sciocchezze sicure di sé. Messo sotto contratto, è la cosa più vicina a un'assunzione a tempo pieno che puoi far funzionare per pochi dollari al giorno.
Questo è quel contratto. Non la teoria. I file veri, nell'ordine in cui li scrivi, costruiti attorno a un'implementazione reale: i bot di monitoraggio che già eseguo su un VPS a Parigi tramite pm2. I flussi di autenticazione e le tabelle di fatturazione non sono il mio punto debole. Le chiavi RPC, gli indirizzi dei wallet e le transazioni live sulla blockchain lo sono. Il sistema qui sotto è costruito per quello, non per un repository SaaS generico.
Cinque sezioni. Ognuna produce un file. Tempo totale di configurazione: meno di due ore.
La Configurazione
1claude CLI (Claude Code) con accesso a Fable 5 # crediti di utilizzo, con tetto massimo2llm CLI + chiave OpenRouter # per i modelli economici3jq, git, pm2, cron4un VPS con i bot già in esecuzione
Cosa ottieni alla fine:
1agent-contract/2 CONTRACT.md # Sezione 1: i termini di impiego3 ops/4 shift.sh # Sezione 3: il turno giornaliero5 dispatcher.md # prompt di instradamento, solo Fable6 intake.md # lettore economico, legge prima i log7 worker.md # modello economico, scrive il codice8 reviewer.md # Fable nuovo, controlla il lavoro9 boundaries.md # Sezione 2: cosa può e non può toccare10 guardrails/signoff.sh # Sezione 2: il sì/no deterministico11 personnel/12 trust.tsv # Sezione 4: chi si è guadagnato l'autonomia13 standing-checks/ # Sezione 4: cose che devono rimanere vere14 incidents/15 log.tsv # Sezione 5: cosa si è rotto e quando16 runbook.md # Sezione 5: cosa fare al riguardo17 Makefile
Una regola da citare prima di iniziare, perché dà il tono a tutto ciò che segue:
Un agente che si valuta i compiti da solo è un agente che si dà un aumento.
Niente in questo sistema controlla il proprio lavoro. Nemmeno una volta.
Sezione 1: Il Contratto (CONTRACT.md)
Un contratto di lavoro non è un elenco di suggerimenti. Sono numeri, limiti rigidi e clausole che vengono fatte rispettare sia che il dipendente sia d'accordo o meno. Scrivi questo file allo stesso modo. Niente "per favore" o "cerca di." Un modello ottimizza attorno a un linguaggio morbido come un tirocinante ottimizza attorno a un manager che non controlla mai.
1# CONTRACT.md23## LIMITI RIGIDI (nessuna eccezione, nessuna richiesta ripetuta)4- Non toccare mai le chiavi del wallet, i file .env o le credenziali RPC senza approvazione.5- Non inviare mai una modifica a un processo bot live (pm2 restart) senza un signoff superato.6- Non superare mai 150 righe modificate in un singolo commit senza chiedere prima.7- Non dichiarare mai un'attività completata basandoti sulla tua lettura dell'output.8 Completato significa che lo script di signoff ha restituito 0. Nient'altro conta.9- Non inventare mai un endpoint API, un indirizzo di contratto o un valore di configurazione.10 Se non è nel repository, fermati e chiedi.11- Non aggiungere mai una nuova dipendenza. Scrivila in ops/shift-log.md e fermati lì.12- Non modificare o eliminare mai un test, una soglia di avviso o una condizione di monitoraggio per far13 passare qualcosa. Questa non è una correzione. È una frode.14- Non eseguire mai con uno sforzo superiore a "high" all'interno di un turno. "xhigh" è per revisioni15 una tantum che attivi manualmente, mai per il ciclo automatico.16- Non narrare o spiegare mai il tuo ragionamento interno in una risposta. Sembra17 utile. Su Fable 5 può invece attivare un classificatore di rifiuto.1819## INSTARDAMENTO DEI COMPITI (chi fa cosa, vince l'assunzione più economica capace)20| modello | costo per attività | ambizione | giudizio | gusto |21|------------------|--------------------|-----------|----------|-------|22| claude-fable-5 | alto | basso | 10 | 10 |23| claude-opus-4-8 | medio | medio | 8 | 9 |24| claude-sonnet-5 | basso | alto | 7 | 7 |25| worker OSS economico | bassissimo | altissimo | 5 | 4 |26271. Decidere cosa fare dopo, rivedere un diff, risolvere un pareggio -> Fable 5,28 sola lettura, sforzo alto.292. Leggere log grezzi, dump o qualsiasi cosa oltre 50k token -> il worker economico.30 Mai Fable. Sarebbe pagare la tariffa di un dirigente per leggere un foglio di calcolo.313. Qualsiasi cosa con cui un utente o una catena interagisce direttamente -> necessita di un punteggio di gusto32 di 8 o superiore prima di essere pubblicata.334. Tutto il resto -> sonnet-5, sforzo medio, scala di un livello in caso di errore.3435## DEFINIZIONI36- "giudizio" = può gestire la cosa più difficile sul tavolo senza supervisione37- "fatto" = lo script di signoff è uscito con 0, punto e basta38- "piccolo" = sotto le 50 righe modificate39- "pulizia" = il comportamento è identico bit per bit, signoff verde prima e dopo4041## L'UNICA DEFINIZIONE DI FATTO CHE CONTA42- Ogni attività ottiene un traguardo verificabile dalla macchina prima che inizi il lavoro.43- Un revisore che non ha visto né il piano né la bozza lo controlla.44- guardrails/signoff.sh ha il voto finale. Non il revisore. Lo script.45- Se il worker e il revisore dissentono due volte di seguito, la questione va a un umano.46 Nessuna terza opinione, nessun modello di spareggio.
Sostituisci con i tuoi numeri. Qualsiasi cosa lasceresti correre l'80% delle volte e chiameresti comunque "fatto" ha bisogno di un numero o di un "mai" associato, altrimenti tagliala.
Sezione 2: Limiti e il Sign-off
Un contratto di lavoro non significa nulla senza un controllo sui precedenti su cosa possono toccare e un manager che firmi prima che qualsiasi cosa venga pubblicata. Due file.
ops/boundaries.md:
1## lavora da solo2bozze di correzioni su un ramo; aggiorna shift-log.md; riavvia un'istanza di test3*non di produzione*; segnala feed di dati obsoleti45## necessita della mia firma6qualsiasi cosa sotto wallets/, .env*, config/rpc.json; qualsiasi diff oltre 300 righe;7qualsiasi modifica a un processo pm2 live; qualsiasi cosa che invii una transazione89## mi sveglia immediatamente10il revisore fallisce la stessa correzione due volte; il router ha servito un modello11diverso da quello richiesto; la spesa giornaliera ha superato il limite; un controllo12permanente diventa rosso; qualsiasi cosa richiede una chiave privata
ops/guardrails/signoff.sh (modifica i comandi per adattarli ai tuoi bot):
1#!/usr/bin/env bash2set -e3npm run typecheck --if-present4npm test --if-present5pm2 describe "$BOT_NAME" | grep -q "status.*online" || exit 1
Eseguilo una volta manualmente prima che qualsiasi altra cosa in questo sistema vada in produzione. Se non passa senza errori sulla tua configurazione attuale, quello è il vero primo compito. Tutto ciò che segue presuppone che questo script dica la verità.
Sezione 3: Il Turno
Ecco il calcolo che fa funzionare o meno questa cosa. Una sessione completa con Fable 5 che scrive il codice costa soldi veri, quattro cifre se lo lasci scrivere per ore. Fable 5 che prende le decisioni mentre un modello economico scrive il codice è un conto completamente diverso, circa il 15-20% dei token per il 100% delle decisioni critiche.
Quindi il turno ha quattro assunti, non uno:
- Un modello quasi gratuito legge i log notturni e l'output di pm2. Dice "tranquillo" o "azione necessaria." Tutto qui.
- Fable 5, sola lettura, decide l'unica cosa di maggior valore da fare e scrive un ordine di lavoro. Non tocca il codice.
- Un modello worker economico esegue l'ordine di lavoro su un ramo isolato.
- Un'istanza nuova di Fable 5, che vede solo le specifiche e il diff, vota promosso o bocciato.
Lo script deterministico nella Sezione 2 esprime il voto decisivo. Ogni volta.
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, pochi centesimi9pm2 logs --lines 100 --nostream | llm -m "$INTAKE_MODEL" -s "$(cat intake.md)" \10 >> shift-log.md11grep -q "status: actionable" shift-log.md || { echo "turno tranquillo"; exit 0; }1213# 2. DISPACCIO, Fable, xhigh, sola lettura, decide e si ferma14claude -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 "reindirizzato, scarta questa esecuzione" >> 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 "in coda per firma" >> shift-log.md; exit 0; }2829# 3. ESECUZIONE, worker economico, ramo isolato30BR="shift-$(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. REVISIONE, Fable nuovo, solo specifiche e diff, nient'altro36VERDICT=$(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. L'UNICO VOTO CHE PUBBLICA QUALCOSA43if [[ "$VERDICT" == PASS* ]] && ( cd "../$BR" && "$OLDPWD/guardrails/signoff.sh" ); then44 echo "PASS, pubblicato o in coda in base al livello di fiducia" >> shift-log.md45else46 echo "FALLITO: $BR trattenuto per revisione" >> shift-log.md47fi
Una decisione presa da Fable e una riga di codice scritta da Fable hanno due prezzi diversi. Paga quello più alto solo per la decisione.
Sezione 4: Il Fascicolo Personale
La fiducia non è un'impostazione a livello aziendale. Si guadagna per ogni compito, allo stesso modo in cui non daresti le chiavi di produzione a un nuovo assunto il primo giorno, per quanto bello fosse il suo portfolio.
personnel/trust.tsv tiene traccia di ogni lavoro ricorrente per nome: esecuzioni, superamenti, livello attuale.
- sorveglianza: meno di 10 esecuzioni, o tasso di superamento inferiore al 90%. Solo bozze, nessuna eccezione.
- prova: 10-19 esecuzioni con un tasso del 90%+. In coda per la tua firma, ogni volta.
- autorizzato: 20+ esecuzioni con un tasso del 95%+. Viene pubblicato senza di te.
Un errore su un compito autorizzato non riceve un avvertimento. Torna direttamente in prova e stampa su stderr, che la tua cron ti invia via email. La retrocessione automatica è l'unico tipo che funziona davvero.
La seconda metà del fascicolo personale è personnel/standing-checks/. Ogni lavoro finito si diploma qui come un comando che deve continuare a restituire vero, per sempre, controllato una volta al giorno:
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: svegliami, non riavviare alla cieca automaticamente
Un compito che hai verificato una sola volta non è finito. È un'ipotesi con un timestamp sopra.
Esegui il controllo quotidianamente tramite cron. Un predicato fallito significa che qualcosa che prima era vero ha smesso di esserlo, silenziosamente, e nessuno se ne sarebbe accorto senza questo file.
Sezione 5: Il Rapporto sugli Incidenti
Questa è la sezione che i playbook originali saltano, ed è quella che conta davvero una volta che il sistema è live su un'infrastruttura che muove soldi veri. Ogni sistema agente prima o poi fa qualcosa che non volevi. La domanda è se lo scopri da un log pulito o da un wallet prosciugato.
ops/incidents/runbook.md:
1| segnale | significato | azione2|----------------------------------|---------------------------------------|--------3| exit 2 (reindirizzato) | un modello diverso ha servito la richiesta | butta via l'output, non costruirci mai sopra, riprova domani4| stop_reason: refusal | classificatore di sicurezza ha rifiutato, HTTP 200 | non è un errore, controlla il log; se un compito rifiuta ripetutamente, probabilmente il compito sta toccando qualcosa che non dovrebbe5| signoff fallisce due volte, stessa correzione | worker e revisore non riescono a convergere | portalo in revisione umana, non riprovare automaticamente una terza volta6| controllo permanente diventa rosso | qualcosa di finito ha smesso di essere vero | controlla la data last-verified, fai un diff di ciò che è stato pubblicato da allora, non annullare automaticamente7| spesa giornaliera supera il limite | budget superato | ferma il turno, leggi shift-log.md, trova quale fase è esplosa8| un compito tocca wallets/.env/rpc | tentativo di violazione dei limiti | arresto immediato, questo non dovrebbe mai accadere se boundaries.md è rispettato, tratta ogni occorrenza come un bug nel sistema stesso
Registra ognuno di questi in incidents/log.tsv con un timestamp, che tu abbia agito o meno. L'obiettivo non è zero incidenti. È zero incidenti di cui vieni a sapere troppo tardi.
Una volta a settimana, esegui un passaggio di compostaggio: leggi il registro degli incidenti, le retrocessioni del file di fiducia e qualsiasi cosa sia rimasta in coda e non firmata per più di 3 giorni. Estrai al massimo tre proposte: un nuovo limite rigido per CONTRACT.md, una correzione a una descrizione del lavoro o un controllo permanente che ti mancava. Firma tutti e tre manualmente. Il sistema può proporre la propria prossima regola. Non ne scrive mai una di propria iniziativa.
Piano di Prova
Tre punti di controllo, non trenta giorni di babysitting:
Punto di controllo 1. Esegui il turno manualmente ogni giorno per una settimana. Leggi ogni riga. Diploma quando tre turni consecutivi instradano esattamente come avresti fatto tu.
Punto di controllo 2. La cron prende il turno. Rivedi la coda con un caffè invece di eseguirla tu stesso. Diploma quando due lavori ricorrenti superano le 20 esecuzioni registrate.
Punto di controllo 3. Il tuo lavoro con le migliori prestazioni viene pubblicato senza supervisione. Diploma quando funziona per un'intera settimana con zero interventi da parte tua.
Le Regole, Compresse
- Un contratto è un numero o un mai. Qualsiasi cosa più morbida viene ottimizzata.
- Il dispatcher decide. Il worker scrive. Nessuno dei due controlla il proprio lavoro.
- Il giudizio di Fable vale il prezzo. La scrittura di Fable di solito no.
- La fiducia è per lavoro, non a livello aziendale, e la retrocessione è automatica e rumorosa.
- Un compito finito che non viene ricontrollato non è finito, è un'ipotesi con una data sopra.
- I limiti vivono in un file che puoi leggere in dieci secondi, non nella tua memoria.
- Il registro degli incidenti esiste così trovi i problemi da un rapporto, non da un saldo.
- Non costruire mai sull'output di un modello che non hai richiesto.
- Una volta a settimana, il sistema può proporre una nuova regola. Sei ancora tu a firmarla.
Il modello non è mai stato la parte difficile. Costruire qualcosa attorno ad esso che rimanga onesto quando nessuno guarda, questo è il vero lavoro. Ecco come appare per una flotta di bot invece che per un codebase.
Inizia con guardrails/signoff.sh. Esegui un turno manualmente. Scrivi un controllo permanente per l'ultimo bot che hai pubblicato. La prima volta che cattura qualcosa di cui eri sicuro andasse bene, tutto il resto smette di essere opzionale.
Segui @GipArcAI per altre analisi come questa, e trovami su X all'indirizzo https://x.com/gippp69.
