"The Orchestrator’s Tax" e i subagent

Quattro subagent in esecuzione su una refactor della response-pipeline, risultati fuori ordine, una sessione che diventa più difficile da seguire del codice. L’innesco è preciso: durante una sessione su un codebase .NET con Claude Code, il dubbio interrompe il lavoro e costringe a riconsiderare il flusso¹.

Da quell’incidente nasce “The Orchestrator’s Tax”, pubblicato il 28 luglio 2026. L’articolo mette in discussione una giustificazione ricorrente dei subagent: non conta solo il tempo risparmiato né l’esecuzione in parallelo, soprattutto nei lavori multi‑agente di lunga durata. Conta la memoria di lavoro dell’orchestrator. Ogni token nel suo contesto compete per la sua attenzione. Il valore reale di un subagent è ciò che tiene fuori da quel contesto¹.

La tesi è diretta: trattare i subagent come uno strumento di protezione della working memory dell’orchestrator. Delegare il ragionamento che l’orchestrator non deve trattenere. Ridurre l’ingombro cognitivo, più che accorciare i tempi. Questo sposta il criterio di scelta: quando delegare e con quale scopo diventano decisioni esplicite, non effetti collaterali dell’ottimizzazione delle prestazioni¹.

Il racconto operativo è concreto. Quattro subagent già al lavoro sulla stessa refactor. Risposte che arrivano senza ordine. La sessione che inizia a sembrare più opaca del codice. In quel momento cade la fiducia nella sensazione che “probabilmente va bene”. A volte il problema è il codice. A volte l’architettura. Talvolta è il workflow che va esaminato¹.

Da qui una proposta: dare all’orchestrator regole esplicite su quando e come delegare. Non basta avviare subagent e aspettare. Occorre specificare le condizioni di delega e il perimetro dell’attività che non deve rientrare nel contesto dell’orchestrator. L’obiettivo è proteggere l’attenzione disponibile: tenere a distanza i dettagli che non servono per il prossimo passo decisionale¹.

Il lavoro si presenta come esplorativo. Nasce da un episodio reale, non da una serie di esperimenti controllati. Non chiude il tema. Si chiude con più domande che risposte: come definire buone regole di delega? Come stabilire cosa resti fuori dal contesto per preservare la memoria di lavoro? Come riconoscere quando il workflow rende la sessione più pesante del compito stesso¹?

La prospettiva suggerisce una revisione delle priorità. Se ogni token nel contesto chiede attenzione, il rischio non è solo la lentezza. È la saturazione della memoria di lavoro. In questo quadro, la scelta di delegare mira a sottrarre materiale superfluo all’orchestrator, non a moltiplicare processi. Il successo non si misura soltanto con il cronometro, ma con quanto ragionamento resta fuori dalla sua testa operativa¹.

Il lessico della “tassa” chiarisce il compromesso: ogni informazione non filtrata che rientra nel contesto ha un costo di attenzione. La difesa sta nelle regole di delega esplicite. L’articolo non offre un manuale definitivo; indica un orientamento e apre un cantiere di domande su pratica e criteri di delega nei sistemi multi‑agente di lunga durata¹.