Agenti AI: servono code operative, non solo prompt

Quando un agente lavora per cinque minuti, il prompt sembra l’interfaccia principale. Quando lavora per un’ora, apre tool, legge contesto, produce bozze e aspetta una review, il prompt è solo il punto di partenza. La domanda più difficile diventa operativa: da dove entra il lavoro, chi lo possiede, quanti task possono girare insieme e quando l’agente deve fermarsi?

Il 25 giugno 2026 OpenAI ha descritto l’agentic AI come un passaggio da interazioni singole a task delegati e di lungo orizzonte. Nello stesso post racconta che, a giugno 2026, gli utenti Codex più intensi dentro OpenAI generavano oltre 60 ore di agent turns al giorno, distribuite su agenti paralleli. Microsoft ha usato una direzione simile il 2 giugno 2026, presentando Scout come personal agent sempre attivo in background, capace di agire sotto il controllo dell’utente e dell’organizzazione.

Questo linguaggio conta perché cambia il problema di prodotto. Se gli agenti diventano uno strato di lavoro in background, i team non possono gestirli come una chat. Serve un sistema di lavoro.

Cosa cambia quando il prompt non è il modello operativo?

La qualità del prompt conta ancora. Una richiesta vaga produce lavoro vago, mentre un task brief preciso aiuta l’agente a partire meglio. Ma appena l’agente può continuare dopo la prima istruzione, il prompt non basta più.

Un team che delega lavoro agli agenti deve rispondere a domande più vicine alle operations che al prompting. Quali task possono entrare nel sistema? Quali sono troppo rischiosi? Chi controlla il risultato? Cosa succede se l’output è incompleto? Cosa si ritenta, cosa si scala, cosa si abbandona?

Sono domande di prodotto. Definiscono l’esperienza interna delle persone che usano l’agente e la qualità del lavoro che arriva alla fine.

Si collegano direttamente a due problemi vicini: governare gli agenti per livello di autonomia e progettare workflow n8n che reggono in produzione. La coda è il punto in cui quelle regole diventano visibili invece di restare nascoste nel prompt.

Ogni agente ha bisogno di intake

Una coda per agenti inizia prima che il modello lavori. Inizia dall’intake: il punto in cui il lavoro diventa abbastanza leggibile da poter essere delegato.

Per un team piccolo, l’intake può essere semplice. Un task deve avere un tipo, un owner, una fonte di contesto, una definizione di done e una condizione di stop. Senza questi elementi, l’agente può comunque produrre qualcosa, ma il team deve ricostruire dopo cosa significava davvero quel lavoro.

È qui che molti workflow AI diventano rumorosi. Un founder chiede a un agente di “fare ricerca sui competitor”, un PM gli chiede di “sistemare il backlog”, un operator gli chiede di “controllare le automazioni fallite”. Le parole si capiscono, ma il lavoro non è ancora delimitato. Quali competitor? Quale parte del backlog? Quali errori bloccano davvero? Cosa va ignorato? Cosa deve diventare un ticket?

La coda obbliga a chiarirlo prima che il task parta.

Anche gli agenti hanno bisogno di WIP limit

Gli agenti paralleli fanno sembrare il lavoro abbondante. Il rischio è che creino anche review parallele, cambi di contesto paralleli e incertezza parallela.

Se dieci task agentici finiscono nello stesso momento, il collo di bottiglia si sposta sul lato umano. Qualcuno deve leggere le bozze, controllare le assunzioni, decidere cosa usare, scartare l’output debole e accorgersi se un task ha creato lavoro per un altro team. Più throughput dell’agente non significa automaticamente più throughput dell’organizzazione.

Per questo servono WIP limit. Un team può decidere che solo tre task agentici possono girare insieme dentro un workflow, che i task ad alto impatto richiedono un owner prima di entrare in coda, o che tutto ciò che tocca comunicazioni verso clienti aspetta approvazione esplicita. Il limite non è poca ambizione. Protegge attenzione, qualità della review e responsabilità.

Le code hanno bisogno di owner, non solo di status

Una coda senza ownership diventa un’altra inbox. I task entrano, gli status cambiano, ma nessuno si sente responsabile della decisione finale.

Il lavoro degli agenti ha bisogno di almeno due ownership. Una persona possiede il task: perché esiste, cosa significa fatto bene e se il risultato può essere usato. Un’altra può possedere il sistema: quali classi di task sono ammesse, quali template sono sicuri, quali log restano, quali errori richiedono escalation.

In una società piccola può essere la stessa persona. In un team più grande, di solito è meglio separare i ruoli. Il punto non è aggiungere burocrazia. È evitare quel vuoto strano in cui l’agente ha lavorato, l’output esiste, ma nessuno sa dire se il processo ha funzionato.

Le condizioni di stop fanno parte del design

Gli agenti sempre attivi sembrano utili finché “sempre attivo” diventa “non è chiaro quando ha finito”. La coda dà all’agente un punto di ingresso, ma serve anche un punto di uscita.

Una condizione di stop può essere semplice: restituisci una bozza e aspetta, crea un ticket e fermati, chiedi il contesto mancante, ritenta due volte, scala dopo un errore bloccante, chiudi il task se le prove non bastano. Queste regole contano perché il lavoro lungo può fallire in modo silenzioso. Può continuare a raccogliere contesto, generare varianti o agire su un’assunzione debole.

Un buon lavoro agentico non è un lavoro che non si ferma mai. È un lavoro che si ferma in uno stato utile: completato, pronto per review, bloccato con una ragione chiara o rifiutato prima di creare altro rumore a valle.

L’artefatto utile è la policy della coda

Se un team vuole introdurre agenti nel lavoro reale, io non partirei da una libreria di prompt. Partirei da una breve policy di coda.

La policy può stare in una pagina:

1. Quali classi di task possono entrare nella coda agentica.
2. Quali classi di task sono escluse.
3. Quale contesto è richiesto prima della partenza.
4. Chi possiede review e approvazione finale.
5. Quanti task possono girare insieme.
6. Quali errori fermano, ritentano o scalano.

È meno emozionante che annunciare agenti autonomi, ma è molto più vicino a come il lavoro regge nella pratica. I prompt aiutano l’agente a capire un task. Le code aiutano il team a gestire lavoro delegato.

La prossima volta che un team dice di volere agenti in background, la prima domanda utile non è “quale prompt scriviamo?”. È: “quale lavoro può entrare nella coda, e chi risponde quando ne esce?”.