Sto scommettendo la mia azienda sugli agenti proattivi

Gli agenti possono fare quasi tutto ciò che gli chiedi, e il problema è proprio questo: devi ancora chiedere.

Continuo a sentire persone chiamare gli agenti “colleghi digitali”. È un’immagine sbagliata. Un collega che sta in silenzio finché non gli consegni un compito perfettamente delimitato, lo completa e poi torna ad aspettare, non è un collega. Ogni agente che hai mai usato funziona esattamente così. I modelli sono diventati più intelligenti, gli harness migliori, i run più lunghi, ma l’interfaccia non è mai cambiata: tu porti il lavoro, l’agente porta la manodopera.

E la maggior parte delle persone non se n’è accorta, perché la casella del prompt è diventata in silenzio ciò che l’IA è nella nostra testa.

Ask anything about your stack...

Ogni interfaccia è ancora una casella di prompt

La casella di input è il modo in cui è iniziata tutta questa era. ChatGPT ne ha messa una sopra un modello ed è diventato il prodotto con la crescita più rapida della storia, e tutti l’abbiamo copiato. Ogni prodotto IA da allora è una variazione della stessa interazione: la persona digita, la macchina risponde, la macchina aspetta.

Claude Code è stato l’evoluzione successiva. L’agente si è trasferito nel tuo terminale, ha preso in mano i tuoi file, la tua shell e la tua cronologia git, e ha iniziato a fare lavoro vero invece di parlarne. Ha cambiato cosa gli agenti possono fare, ma non come iniziano: tu digiti, lui lavora, si ferma e aspetta che tu digiti di nuovo.

~/app

$ claude

✳ 12 files · main · last session 2h ago

> fix the failing checkout tests

? for shortcuts

Poi gli agenti si sono spostati nel cloud. Codex, Devin, Claude Code sul web. Girano per ore invece che per minuti, avviano sub-agenti per parallelizzare il lavoro e non muoiono quando chiudi il portatile. Ne affidi un compito a uno prima di pranzo e torni trovando una pull request.

Il prompt ha persino smesso di essere una cosa solo da tastiera. Gli agenti in background possono essere avviati da un alert o da un webhook, e la maggior parte delle piattaforme per agenti ora offre automazioni: quando scatta questo evento, o quando questo cron ticchetta, esegui un agente con queste istruzioni.

Triage Sentry alerts Enabled

When

a Sentry alert fires

Do

investigate, open an incident if it's real

Then

post the findings to #incidents

Ma cos’è un’automazione? È un prompt che hai scritto in anticipo. Hai previsto la modalità di guasto, scelto l’evento e annotato cosa fare al riguardo. Il trigger fa partire l’agente, ma il giudizio al suo interno è tuo, congelato al momento della configurazione. Un’automazione intercetta esattamente ciò che avevi previsto, e nient’altro.

Sei tu lo scheduler

Togli gli strumenti e la divisione del lavoro non si è mossa in tre anni. L’agente fa il lavoro. Decidere qual è il lavoro resta compito tuo.

Leggi le dashboard, ascolti gli utenti, capisci cosa conta e comprimi tutto ciò che hai imparato in un prompt, o dal vivo alla tastiera o in anticipo in un trigger. L’agente esegue brillantemente, ma ogni frammento di giudizio nel sistema ha origine in te.

La prossima evoluzione: agenti che trovano il lavoro

Sto scommettendo che la prossima evoluzione siano agenti che capiscono da soli qual è il lavoro da fare. Nessun prompt, nessun trigger da configurare, nessuna istruzione scritta in anticipo. Colleghi il tuo stack, e l’agente trova il lavoro da solo: osserva gli stessi segnali che osservi tu, nota cosa non va, decide se conta e inizia a lavorarci in autonomia.

È facile da dire, e brutalmente difficile da costruire, perché la proattività è tre problemi impilati uno sull’altro, e saltarne uno qualsiasi ti dà qualcosa di peggio dell’agente dietro una casella di input.

Contesto. Ovviamente, l’agente ha bisogno di un modello vivo del mondo in cui opera, non di uno snapshot che hai incollato nella finestra di contesto al momento del prompt. Un agente reattivo con un contesto scadente ti dà una risposta scadente. Un agente proattivo con un contesto scadente cancella il tuo database di produzione perché pensava fosse staging.

Giudizio. È ciò che mi sta dando più filo da torcere. In qualsiasi momento, migliaia di cose in un sistema in produzione sono leggermente fuori posto. Un agente che le segnala tutte è una macchina del rumore, le macchine del rumore vengono silenziate, e gli agenti silenziati sono agenti morti. L’intero valore della proattività vive nello spazio tra “qualcosa è cambiato” e “qualcosa conta”:

[
  {
    "signal": "memory up 3% on checkout-edge",
    "verdict": "no anomaly",
    "reasoning": "within the seasonal range for this hour on this worker"
  },
  {
    "signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
    "verdict": "incident",
    "reasoning": "error class never seen on this worker, tightly correlated with a deploy"
  }
]

Azione. Notare senza agire è solo un alert più intelligente, e gli alert sono la cosa che sto cercando di eliminare. L’agente deve finire il lavoro, entro confini che rendano l’autonomia sicura: azioni reversibili, prove per tutto e un cancello rigido prima che accada qualsiasi cosa di irreversibile.

Nessuno di questi tre comporta che l’agente decida cosa significa “bene”. Decide cosa non va, se conta e cosa fare al riguardo, e la lista finisce qui, perché in produzione nessuno deve definire cosa sia “bene”: errori a zero, latenza alla baseline, code svuotate, certificati validi. Lo stato desiderato viene con il territorio.

Il che significa che il vero cambiamento non è da “tu fai il prompt” a “l’agente si fa il prompt da solo”. È da operations imperative a operations dichiarative. Un’automazione è imperativa: enumeri in anticipo le modalità di guasto e scrivi una risposta per ciascuna. Un agente proattivo è un ciclo di riconciliazione: tiene il sistema che hai a confronto con il sistema che dovresti avere, e lavora per chiudere il divario. Kubernetes l’ha fatto per l’infrastruttura dieci anni fa, scrivi tre repliche e un controller fa tutto il necessario per tenere in vita tre repliche. Nessuno l’ha fatto per l’operatività del software stesso. E qui non c’è nemmeno YAML da scrivere, perché lo stato desiderato è già noto. Funziona così com’è.

Ho iniziato dalle operations

Chiedi a un agente proattivo di scegliere la roadmap del tuo prodotto e ottieni uno stagista con molte opinioni, perché la direzione di un prodotto è una questione di gusto. La produzione no. È l’unico dominio in cui tutti e tre i problemi sono risolvibili oggi.

Il lavoro si annuncia da solo: i tassi di errore salgono, un deploy va storto, un certificato scade, una coda si intasa. Il lavoro è già lì nella telemetria, in attesa che qualcuno lo noti. E a differenza dei domini guidati dal gusto, esiste una verità di riferimento: il tasso di errore ha avuto un picco oppure no, il rollback ha ripristinato la baseline oppure no, quindi il giudizio dell’agente viene valutato dal sistema stesso, in continuazione, senza spazio per le sensazioni.

Soprattutto, per questo lavoro assumiamo già delle persone. Lo chiamiamo on-call: una persona che dorme accanto a un telefono, aspettando che una macchina dica che un’altra macchina è infelice. Ho passato anni nell’observability, ho fondato un’azienda di observability che Cloudflare ha acquisito, e ho scritto un intero manifesto su come strutturare la telemetria perché la risposta sia a una sola query di distanza. La sua tesi è il motivo per cui esiste questa azienda: nel 2026 nessuno dovrebbe essere in on-call.

Perché la verità scomoda sull’ultimo decennio di observability è che abbiamo reso i sistemi più facili da interrogare per le persone alle 3 di notte, poi abbiamo dichiarato vittoria mentre le persone erano ancora quelle che venivano svegliate. Le dashboard sono diventate più belle e il pager è rimasto sul comodino. L’observability senza azione è solo storage costoso.

Com’è nella pratica

È questo che fa Polylane. Ecco un martedì concreto:

Nessuno ha configurato un controllo per questa modalità di guasto. Non ci sono regole da scrivere né soglie da tarare: gli agenti valutano ogni risorsa collegata a cadenza continua, e le tue dashboard esistenti e le query salvate diventano la loro checklist. Il giudizio è il punto in cui sono più severo. Il verdetto predefinito è nessuna issue, perché è molto meglio perdersi una issue al limite che svegliare qualcuno per il rumore. “Un deploy potrebbe introdurre un bug” è vero di ogni deploy e non è mai un motivo per svegliare qualcuno.

Quando qualcosa è reale, l’indagine esegue in parallelo diverse ipotesi in competizione, e il compito di ogni agente è smentire la propria ipotesi anziché confermarla, così la correlazione non riesce mai a mascherarsi da causa. Quando la causa radice confermata è una modifica al codice, il fix arriva come pull request con l’indagine allegata:

Restore Hyperdrive pool size in checkout-edge

PR open coreplane/checkout-edge

Investigation report attached Checks passing

Opened by Polylane · gated on review and CI

Proattivo non significa senza supervisione

L’autonomia sta nel notare, nel triage, nell’archeologia delle 3 di notte e nella mitigazione. Tutto ciò che ripristina uno stato noto come buono, l’agente lo fa da solo: rollback del deploy difettoso, flag rimessa a off. Quelle azioni sono reversibili per costruzione, e sono quelle che silenziano davvero il pager. Ciò che resta dietro un cancello è tutto ciò che crea uno stato nuovo: una modifica al codice passa attraverso la tua review e la tua CI, mai aggirandole.

La linea non è persona contro agente. È reversibile contro non reversibile. Ed è il motivo per cui non sei segretamente ancora in on-call: il rollback ha chiuso l’incidente alle 02:33, sei ore prima che tu unissi la pull request. La PR non è mai stata ciò che ha fermato l’emorragia. È ciò che impedisce che succeda di nuovo, e quello può aspettare il caffè.

E il cancello è tuo da delegare. Gli agenti di code review leggono già ogni pull request nel tuo repository. Esiste un mondo, non lontano da questo, in cui il tuo agente di review legge il fix alle 02:41, lo verifica rispetto all’indagine, lo approva, e la tua CI fa il deploy in produzione prima che tu ti svegli. Niente nel ciclo cambia, tranne chi tiene il pulsante di approvazione. È lì che finisce tutto questo: software che si ripara da solo, con te che scrivi la policy invece di cliccare su merge.

Nota cosa manca in quel ciclo:

Ask anything about your stack...

La casella del prompt è stata un ottimo modo per imparare a fidarsi di questi sistemi, ed è un modo terribile per far girare la produzione. L’agente ha visto ogni deploy, ogni riga di log e ogni metrica di ogni servizio, tutto insieme. Tenerlo dietro un prompt significa che il membro più informato del tuo team parla solo quando gli viene rivolta la parola.

Nel 2026 nessuno dovrebbe essere in on-call.