Idea principale

Un hook collegato alla fine di un turno di conversazione, il cui compito consiste proprio nel chiamare l'assistente per fargli riassumere lo scambio, si innesca da solo: la chiamata che emette termina a sua volta, e quella fine risveglia l'hook. Il ciclo non è un incidente di implementazione, è la conseguenza diretta della configurazione — l'automatismo usa lo strumento di cui sorveglia la fine.

Il rimedio non consiste nell'evitare la chiamata, ma nel rendere l'automatismo capace di distinguere gli inneschi che ha provocato da quelli che vengono dal lavoro reale. Claude Code passa a questo scopo un indicatore stop_hook_active nei dati inviati allo script, e lo script esce subito quando lo vede, prima di qualsiasi elaborazione.

Questo controllo va messo per primo, prima della lettura del transcript e prima di qualsiasi chiamata al modello. Una protezione collocata dopo il lavoro costoso non protegge da nulla: il ciclo starebbe già consumando risorse.

Perché è importante

È un guasto che non si scopre progettando, ma pagando — in tempo di esecuzione, in chiamate fatturate, in sessioni che non restituiscono più il controllo. Sapere che è strutturale permette di affrontarlo in fase di progettazione.

E lo schema si ritrova ovunque un sistema reagisca ai propri effetti: un trigger di database che scrive nella tabella che sorveglia, un'integrazione continua che fa il push di un commit, una regola di posta che risponde nel thread che osserva.

Sfumature e limiti

La distinzione è possibile solo se l'ambiente la fornisce. Senza un segnale del genere bisogna fabbricarla — un lock, un marcatore, una finestra temporale — e questi surrogati falliscono appena due esecuzioni si sovrappongono.

E uscire su questo segnale ha un costo: lo scambio interno, invece, non viene mai registrato.

Domande aperte

• Come accorgersi che un'automazione riflessiva gira in ciclo, se il suo esito è proprio non scrivere nulla?