Il tuo agente IA ti sta aspettando: trasforma le approvazioni in telefonate

Indice

• Quanto sono davvero frequenti gli incidenti con gli agenti?
• Cosa succede davvero quando un agente ha bisogno di una persona?
• Quali eventi di un agente meritano una telefonata?
• Come collegare l'approvazione di un agente a una telefonata
• Passo 1 — Crea un canale Chiamata per gli agenti bloccati
• Passo 2 — Attiva il webhook dal ramo di approvazione
• Passo 3 — Usa gli hook quando l'agente è una CLI e non una libreria
• Passo 4 — Intercetta gli agenti che mandano solo email
• Passo 5 — Aggiungi condizioni perché squillino solo i blocchi veri
• Passo 6 — Provalo con Non disturbare attivo
• Non si finisce così per ricreare l'alert fatigue con una campanella più forte?
• Cosa non fa Echobell
• FAQ
• Posso approvare un'azione dell'agente direttamente dalla telefonata?
• Quali eventi del framework dovrebbero attivare il webhook?
• Funziona con gli agenti headless in CI?
• E nello specifico l'elicitation di MCP?
• È sicuro mettere l'output dell'agente nella notifica?
• Tutto il mio team può ricevere lo stesso avviso dell'agente?
• Vale solo per iOS?
• In cosa è diverso dalla configurazione con WebhookMCP?
• Articoli correlati

Ogni framework per agenti autonomi uscito nel 2026 ha lo stesso buco. L'agente lavora per ore senza di te, incontra un'azione che non è autorizzato a compiere da solo, si ferma — e poi non succede più niente. L'esecuzione non fallisce. Non viene ritentata. Resta in memoria con in mano un oggetto di stato serializzato, ad aspettare una persona che non ha idea di essere attesa. Questa guida mostra come colmare quel vuoto trasformando il momento “ho bisogno di una persona” dell'agente in una telefonata che squilla davvero, con Echobell.

Il vuoto è strutturale, non è il bug di un singolo prodotto. La documentazione sugli agenti di OpenAI descrive il flusso di approvazione con precisione: quando uno strumento richiede un'approvazione, “l'esecuzione va in pausa finché non la approvi o la rifiuti”, il risultato restituisce interruptions più uno state da cui riprendere e, se la revisione può richiedere tempo, ti viene detto di serializzare quello stato, salvarlo e riprendere più tardi (OpenAI, guida all'Agents SDK). In nessun punto di quel flusso qualcosa arriva a una persona. Avvisare chi deve approvare resta interamente a carico tuo.

Nel frattempo le esecuzioni si allungano. AWS descrive i suoi agenti di frontiera come capaci di “operare per ore o giorni senza bisogno di interventi” (About Amazon). Kiro Crew, lanciato il 4 agosto 2026, lo dice senza giri di parole: “Avvia una migrazione e continuerà ad andare avanti tra checkpoint e nuovi tentativi mentre sei in riunione o dormi” — pur precisando che “le richieste degli strumenti possono richiedere un'approvazione” (Kiro). Le due metà sono vere insieme. L'agente lavora mentre dormi, e l'agente si ferma mentre dormi.

Quanto sono davvero frequenti gli incidenti con gli agenti?

Abbastanza frequenti che la maggior parte delle aziende ne ha avuto almeno uno, e quasi nessuna lascia lavorare gli agenti senza supervisione. In un sondaggio su 418 professionisti IT e della sicurezza condotto nel gennaio 2026 dalla Cloud Security Alliance su commissione di Token Security, il 65% delle organizzazioni ha segnalato almeno un incidente legato a un agente IA nell'ultimo anno — il 61% con esposizione di dati, il 43% con interruzioni operative e il 35% con perdite economiche (comunicato stampa CSA, rapporto).

I numeri sulla governance dello stesso sondaggio sono quelli che contano per gli avvisi. Solo il 13% fa girare agenti completamente autonomi. Il 53% lascia che gli agenti agiscano in autonomia sui compiti a basso rischio, con revisione umana per le azioni più rischiose, e il 24% tiene una persona nel ciclo per la maggior parte dei compiti. L'82% aveva scoperto agenti IA ombra nel proprio ambiente nell'ultimo anno.

Leggilo come un dato operativo, non come una statistica allarmistica: circa tre organizzazioni su quattro hanno inserito deliberatamente una pausa nei propri agenti. Ognuna di quelle pause è un momento in cui una macchina resta bloccata in attesa di una persona. Se quella persona lo scopre alle 9 del mattino dopo, la capacità dell'agente di lavorare di notte non è valsa niente.

Cosa succede davvero quando un agente ha bisogno di una persona?

Aspetta, in silenzio, e ogni framework lascia la notifica a te. Il meccanismo cambia; il risultato no.

Il Model Context Protocol lo mette nero su bianco a livello di specifica. L'elicitation esiste proprio perché un server possa chiedere qualcosa a una persona nel mezzo di un'esecuzione, e la revisione attuale (2026-07-28) avverte che i server “NON DOVREBBERO dare per scontato che le richieste di elicitation vadano sempre a buon fine” e devono gestire rifiuto, annullamento ed errori del client (specifica MCP). Il protocollo standardizza la domanda. Non standardizza — e non può standardizzare — il modo di ottenere l'attenzione della persona.

È tutta qui l'opportunità. Ogni livello dello stack degli agenti ha una pausa progettata bene. Nessuno di questi livelli ha un numero di telefono.

Quali eventi di un agente meritano una telefonata?

Due, e sul resto conviene essere spietati. Una telefonata è una risorsa scarsa: spendila solo dove a bloccare tutto è davvero una persona che dorme.

1. Un'approvazione bloccata in un'esecuzione che senza di essa non può proseguire. L'agente è fermo, il tempo passa e aspettare non risolve niente. È il caso tipico.
2. Il fallimento definitivo di una lunga esecuzione non presidiata. Sei ore di migrazione morta alla seconda ora sono sei ore che non recuperi, e preferiresti saperlo alla seconda ora.

Tutto il resto va su un canale più silenzioso. “Attività completata con successo” è una normale notifica push. “L'agente ha consumato l'80% del budget” è al massimo urgente. “Agente avviato” non è affatto una notifica. I tre tipi di notifica di Echobell — Normale, Urgente e Chiamata — esistono esattamente per questo triage, e far corrispondere gli eventi dell'agente all'uno o all'altro è la decisione di progettazione più importante di tutte. Se stai già combattendo con il volume delle notifiche, leggi come risolvere l'alert fatigue prima di aggiungere un canale che squilla.

Come collegare l'approvazione di un agente a una telefonata

Echobell trasforma un webhook o un'email in una telefonata: una chiamata vera, che squilla e vibra e che buca la Full Immersion di iOS e Non disturbare come farebbe la chiamata di un familiare (vedi come bucare la Full Immersion di iOS). Sta tra l'agente che si ferma e la persona che può farlo ripartire.

Passo 1 — Crea un canale Chiamata per gli agenti bloccati

Crea un canale nell'app e imposta il tipo di notifica su Chiamata. Dagli un nome inequivocabile come “Agente bloccato — serve approvazione” e non usarlo per nient'altro. Copia l'URL del webhook dai dettagli del canale; ha questa forma: https://hook.echobell.one/t/<channel-token>. Trattalo come un segreto: chiunque ce l'abbia può far squillare il tuo telefono (guida ai webhook).

Imposta i modelli di titolo e corpo su qualcosa su cui puoi agire dalla schermata di blocco:

Title: Agente bloccato: {{agent}}
Body: In attesa di {{action}} in {{project}} — dalle {{time}} UTC

{{time}} e le altre variabili di sistema per l'ora sono sempre disponibili in UTC senza che tu debba inviarle.

Passo 2 — Attiva il webhook dal ramo di approvazione

In qualsiasi SDK che restituisce interruzioni, la pausa è un normale ramo del tuo codice. Manda una POST all'URL del canale prima di parcheggiare l'esecuzione:

let result = await run(agent, input, { stream: false });

if (result.interruptions?.length) {
  await fetch(process.env.ECHOBELL_BLOCKED_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      agent: agent.name,
      action: result.interruptions[0].rawItem.name,
      project: process.env.PROJECT_NAME,
      externalLink: `https://ops.example.com/runs/${runId}`,
    }),
  });
  await saveState(runId, result.state); // serializza e riprendi dopo l'approvazione
}

La variabile speciale externalLink diventa un link cliccabile nel record della notifica, così chi risponde alla chiamata arriva direttamente sull'esecuzione invece di doverla cercare.

Passo 3 — Usa gli hook quando l'agente è una CLI e non una libreria

Claude Code espone un hook Notification il cui matcher filtra per tipo di notifica, inclusi agent_needs_input e agent_completed, e i suoi gestori possono essere comandi di shell o richieste HTTP dirette (riferimento sugli hook). Un gestore command ti dà il controllo sulla forma del payload, il che conta perché Echobell mostra le chiavi JSON che gli invii:

{
  "hooks": {
    "Notification": [
      {
        "matcher": "agent_needs_input",
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{agent: \"claude-code\", action: .message, project: .cwd}' | curl -sS -X POST -H 'Content-Type: application/json' -d @- \"$ECHOBELL_BLOCKED_URL\""
          }
        ]
      }
    ]
  }
}

Con i gestori command l'input dell'hook arriva come JSON su stdin, con campi come session_id, cwd, hook_event_name e permission_mode. Il tipo di gestore http invia lo stesso JSON direttamente a un URL, senza nessuno script: è allettante, ma si aspetta anche che la risposta sia un documento di output dell'hook, e la risposta di Echobell non lo è. Usa command, a meno che tu non abbia verificato che http si comporti come vuoi nella tua configurazione.

Passo 4 — Intercetta gli agenti che mandano solo email

Molte piattaforme per agenti, servizi di esecuzioni pianificate e strumenti interni comunicano solo via email. Ogni canale Echobell può avere un proprio indirizzo, quindi basta una regola di inoltro per trasformare quei messaggi in chiamate (trigger via email, configurare email-to-call). I trigger via email espongono from, to, subject, text e html come variabili dei modelli, così puoi costruire una condizione sull'oggetto senza doverti scrivere un parser.

Passo 5 — Aggiungi condizioni perché squillino solo i blocchi veri

Un canale che squilla a ogni evento dell'agente smette di essere una telefonata e diventa rumore di fondo. Le condizioni di Echobell filtrano sui valori delle variabili con la stessa sintassi delle espressioni dei modelli, quindi puoi richiedere, per esempio:

blocking == true && risk == "high"

Manda tutto quello che sta sotto quella soglia su un canale Urgente separato. Un obiettivo utile: il canale Chiamata dovrebbe squillare al massimo un paio di volte a settimana. Se squilla di più, il confine di autonomia del tuo agente è tracciato nel posto sbagliato e nessuna impostazione di notifica lo sistemerà.

Passo 6 — Provalo con Non disturbare attivo

Attiva il canale con curl mentre Non disturbare è attivo sul telefono che riceverà davvero l'avviso:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{"agent":"test","action":"deploy to prod","project":"demo","blocking":true,"risk":"high"}'

Attiva nell'app Riprova le chiamate non riuscite, così una chiamata bloccata dalla Full Immersion viene ritentata. Un percorso di escalation non testato è solo un'ipotesi.

Non si finisce così per ricreare l'alert fatigue con una campanella più forte?

Sì, se salti il passo 5. Il rischio è concreto e vale la pena nominarlo. Gli agenti generano molti più eventi dei server — ogni chiamata a uno strumento, ogni checkpoint, ogni nuovo tentativo — e la tentazione di far confluire tutto da qualche parte di visibile è forte.

La disciplina che funziona: una telefonata è riservata agli eventi in cui l'unica cosa che si frappone tra l'agente e il suo avanzamento è una persona che dorme. È un insieme molto più piccolo di “cose importanti che l'agente ha fatto”. Se non riesci a descrivere in una frase cosa farà quella persona nei novanta secondi dopo aver risposto, non merita una chiamata.

C'è anche un argomento di sicurezza per tenere alta l'asticella. Lo stesso sondaggio CSA ha rilevato che le organizzazioni indicano il rischio dell'azione (63%) e l'autorizzazione umana (53%) come principali segnali di governance. Quei segnali contano qualcosa solo se l'autorizzazione umana arriva davvero in tempi rapidi. Un'approvazione a cui di norma si risponde con otto ore di ritardo insegna a tutti ad allargare le maglie — ed è così che quel 13% di piena autonomia diventa in silenzio l'impostazione predefinita, per i motivi sbagliati.

Cosa non fa Echobell

Qui la precisione conta, perché l'infrastruttura per agenti attira promesse esagerate.

Echobell fa questo: trasforma un webhook o un'email in una chiamata che squilla, in un avviso urgente o in una normale notifica push; filtra con le condizioni; mostra il contesto con i modelli; consegna lo stesso trigger a un canale di team condiviso in cui ogni iscritto sceglie la propria urgenza.

Echobell non fa questo:

• Approvare qualcosa. Non è un'interfaccia di approvazione e non ha alcun collegamento con lo stato del tuo agente. Ti fa squillare il telefono; per approvare o rifiutare apri comunque un laptop, una dashboard o un terminale. Non esiste nessun “premi 1 per approvare”.
• Riprendere l'esecuzione. Serializzare e ripristinare lo stato dell'agente è compito del tuo framework. Echobell non lo tocca mai.
• Offrire policy di escalation, prese in carico o turni di reperibilità. Non esiste nessun “se non risponde nessuno entro cinque minuti, chiama la persona successiva”. Chiama gli iscritti a un canale. Se ti servono turni pianificati e tracciamento delle prese in carico, ti serve una piattaforma di incident management: guarda il confronto tra le alternative a Opsgenie per quella categoria di strumenti.
• Mettere in sicurezza i tuoi agenti. Niente di tutto questo affronta gli agenti ombra, i permessi troppo ampi sugli strumenti o il ritardo nella dismissione descritto nel rapporto CSA. Un'attenzione umana più rapida mitiga una risposta lenta, non un'architettura sbagliata.
• Garantire la consegna. Una chiamata dipende dall'infrastruttura di push, dalla rete e da un telefono carico. Consideralo il livello che accorcia l'attesa, non un controllo su cui puoi contare in modo assoluto.

Detto onestamente: il confine di autonomia del tuo agente non cambia a seconda dell'app che ti fa squillare il telefono. Quello che cambia con una chiamata è il numero di ore tra il momento in cui l'agente si ferma e quello in cui una persona se ne accorge — e in un'esecuzione notturna quelle ore sono tutto il valore di farla girare di notte.

FAQ

Posso approvare un'azione dell'agente direttamente dalla telefonata?

No. Echobell consegna una chiamata con il contenuto della notifica e un link cliccabile; non ha nessun canale di risposta interattiva verso il tuo agente. Lo schema realistico è: la chiamata ti sveglia, externalLink ti porta alla dashboard dell'esecuzione o all'endpoint di approvazione, e lì decidi. Se vuoi approvare rispondendo, quell'endpoint devi costruirtelo tu: Echobell copre solo la metà che ti sveglia.

Quali eventi del framework dovrebbero attivare il webhook?

Quelli in cui l'esecuzione non può proseguire. Nell'OpenAI Agents SDK è un array interruptions non vuoto. In MCP, una richiesta elicitation/create a cui il tuo client non può rispondere senza una persona. In Claude Code, l'hook Notification con il matcher agent_needs_input. Gli eventi di completamento vanno su un canale Normale o Urgente, non su uno di tipo Chiamata.

Funziona con gli agenti headless in CI?

Sì, ed è lì che conta di più, visto che nessuno sta guardando un terminale. Qualsiasi step di CI in grado di eseguire curl può attivare un canale. Manda la richiesta sul ramo di fallimento di un job lungo e non a ogni job, altrimenti la tua pipeline diventerà la cosa più rumorosa che possiedi.

E nello specifico l'elicitation di MCP?

L'elicitation è pensata per un client con una persona presente a cui mostrare una richiesta. In un'esecuzione non presidiata non c'è nessuno a cui mostrarla, e la specifica dice esplicitamente ai server di gestire rifiuto e annullamento invece di dare per scontata una risposta. Uno schema ragionevole è che il wrapper del client MCP attivi un webhook Echobell quando riceve una richiesta di elicitation a cui non può rispondere in autonomia, e poi tenga in sospeso o annulli secondo le tue regole.

È sicuro mettere l'output dell'agente nella notifica?

Invia il meno possibile. Meglio un identificatore e un link che l'output vero e proprio dell'agente: usa externalLink per puntare al record dell'esecuzione in un sistema fatto per conservarlo. Echobell conserva il contenuto e la cronologia delle notifiche solo sul tuo dispositivo, e sul server tiene soltanto account, canali e iscrizioni (modello di privacy); è ottimo per la minimizzazione dei dati, ma non è un motivo per inviare più del necessario.

Tutto il mio team può ricevere lo stesso avviso dell'agente?

Sì. Condividi il canale e ogni iscritto riceve il trigger, scegliendo il proprio tipo di notifica. Una configurazione comune: chi è responsabile dell'agente si iscrive come Chiamata, il resto del team come Urgente.

Vale solo per iOS?

No. Echobell funziona su iOS e su Android tramite Google Play (vedi il rilascio su Android). Il comportamento degli avvisi in stile chiamata cambia da piattaforma a piattaforma, quindi provalo sui dispositivi che le persone reperibili hanno davvero in tasca.

In cosa è diverso dalla configurazione con WebhookMCP?

WebhookMCP dà al modello uno strumento che può decidere di chiamare quando un'attività finisce: utile, ma dipende dal fatto che sia l'agente a decidere di avvisarti. L'approccio descritto qui parte dal tuo codice o da un hook del framework, quindi funziona anche quando l'agente è bloccato, confuso o è andato in crash. Usali entrambi: uno per “fatto”, uno per “bloccato”.

---

Articoli correlati

• Ricevi una notifica quando le attività IA finiscono, con WebhookMCP
• Come bucare la Full Immersion di iOS per gli avvisi critici
• Risolvere l'alert fatigue: guida per sviluppatori
• Avvisi per i cron job falliti
• Guida all'integrazione dei webhook
• Guida alle condizioni