ElevenAgents Architect: progettare e correggere agenti vocali con test e bozze

ElevenAgents Architect è un assistente per costruire, analizzare e migliorare agenti vocali, lavorando su configurazioni, conversazioni e test. Non è la voce che risponde direttamente al cliente: aiuta il team a capire e modificare il sistema che gestisce quelle conversazioni.

ElevenLabs lo ha presentato il 6 ottobre 2026 in alpha, con distribuzione graduale. La documentazione descrive accesso gratuito durante l'alpha, indicata fino a ottobre 2026: non è una promessa di gratuità permanente. Le modifiche vengono preparate in bozze non pubblicate, da verificare prima dell'attivazione. Annuncio ElevenLabs e documentazione Architect.

Per una PMI che usa telefonia AI, la novità interessa soprattutto la manutenzione. Quando un assistente fraintende una richiesta, il problema può dipendere dal prompt, da uno strumento, dal percorso o dalla base di conoscenza. Architect può aiutare a indagare; il team deve comunque decidere quale correzione sia appropriata e provarla prima che raggiunga i clienti.

Quale problema cerca di risolvere Architect?

Un agente vocale è composto da più parti: istruzioni, voce, strumenti, documenti, percorsi e controlli. Quando una chiamata va male, ascoltare il risultato non basta per individuare la causa. Una risposta sbagliata può nascere da una fonte obsoleta; un appuntamento mancante può dipendere dal calendario; un trasferimento fallito può essere un problema di percorso.

Architect è descritto come un assistente capace di leggere il contesto operativo e proporre interventi su prompt, workflow, tool, knowledge base e guardrail. Il suo ruolo è rendere più accessibile il lavoro di costruzione e diagnosi, secondo le funzioni documentate. Non vengono qui presentati test Giallo o risultati indipendenti sulla qualità delle correzioni. Funzioni dichiarate.

La guida alla voice AI per aziende aiuta a distinguere questi livelli. Una voce naturale è soltanto una parte dell'esperienza. Il sistema deve comprendere il compito, usare dati corretti, rispettare autorizzazioni e dare al cliente un esito riconoscibile. La manutenzione riguarda tutti questi passaggi.

Come funzionano bozze e pubblicazione?

La documentazione indica che le modifiche proposte vengono conservate in bozze non pubblicate. Questo crea uno spazio di revisione fra richiesta del team e comportamento dell'agente attivo. Non va però letto come una garanzia che ogni correzione proposta sia sicura o corretta. La bozza deve essere compresa e collaudata. Gestione documentata delle modifiche.

Prima della pubblicazione è utile confrontare configurazione precedente e nuova. Il team dovrebbe sapere quale problema si vuole risolvere, quali componenti cambiano e quali conversazioni potrebbero esserne influenzate. Una modifica al prompt apparentemente locale può alterare un percorso già funzionante, soprattutto quando introduce nuove priorità o eccezioni.

È preferibile correggere un problema identificato alla volta quando ciò rende il confronto più chiaro. Cambiare insieme istruzioni, strumenti e documenti può migliorare una prova ma rendere difficile capire il motivo. Una nota breve con causa ipotizzata, intervento e test eseguito aiuta a mantenere il servizio anche quando interviene un'altra persona.

Quali dati evitare nella chat con Architect?

Le conversazioni con Architect non sono coperte da Zero Retention Mode, secondo la documentazione. Non bisogna quindi assumere che l'impostazione adottata per altre parti del servizio si estenda automaticamente a questo assistente. È opportuno evitare dati personali o sensibili nei messaggi e verificare le condizioni correnti prima dell'uso. Limite sulla conservazione.

Per descrivere un errore, spesso basta una ricostruzione anonimizzata: richiesta del chiamante, azione attesa, risultato ottenuto e componente coinvolto. Non serve sempre incollare la conversazione integrale con nome, telefono e dettagli della pratica. La minimizzazione dovrebbe essere una regola operativa del team, non una decisione improvvisata a ogni problema.

Anche l'accesso alle conversazioni e ai test va controllato. Chi mantiene il sistema può aver bisogno di informazioni tecniche diverse da quelle visibili a chi gestisce il cliente. Prima del pilota bisogna capire quali persone possano consultare quei dati e con quale finalità. Un assistente di manutenzione non rende irrilevanti le responsabilità sui contenuti analizzati.

Come distinguere gli errori di una telefonata?

La tabella propone un metodo di diagnosi. Evita di usare “il modello ha sbagliato” come spiegazione universale. Un parametro errato e un documento obsoleto richiedono correzioni diverse. L'analisi dovrebbe conservare soltanto le informazioni necessarie a distinguere questi casi.

Gli errori della voice AI riguardano spesso anche il disegno del servizio. Se il sistema non sa cosa fare quando il cliente cambia richiesta, non basta sostituire una frase nel prompt. Bisogna decidere se annullare una proposta, confermare un dato o trasferire la conversazione. Architect può assistere il lavoro, ma la regola aziendale deve esistere.

Scenario ipotetico: un centro assistenza corregge le prenotazioni

Immaginiamo un centro assistenza che usa un agente vocale per prenotare interventi. Il personale nota che alcune richieste vengono associate al servizio sbagliato. Prima di modificare il prompt, raccoglie esempi anonimizzati e verifica se le categorie del calendario siano comprensibili e coerenti con il linguaggio dei clienti.

Architect può essere usato per esaminare configurazione e test e preparare una proposta di correzione. La bozza viene provata con richieste chiare, ambigue e corrette a metà conversazione. Il team controlla sia il testo pronunciato sia la categoria realmente inviata allo strumento. Una risposta rassicurante non basta se l'intervento registrato resta sbagliato.

Questo è uno scenario ipotetico. Non indica risultati di un cliente né una riduzione misurata degli errori. L'esito da chiedere al pilota è una correzione dimostrabile sul problema osservato, insieme all'assenza di regressioni nei percorsi già approvati. La pubblicazione arriva dopo la revisione, con la possibilità di recuperare la configurazione precedente.

Scenario ipotetico: un distributore migliora il passaggio al personale

Consideriamo un distributore che usa la voce per leggere lo stato degli ordini. Il cliente può però chiedere un cambio commerciale che l'agente non è autorizzato a eseguire. Il problema osservato è un trasferimento poco chiaro: il cliente non sa se stia parlando con una persona o se la richiesta sia soltanto registrata.

Il team definisce prima il comportamento atteso. Se un operatore è disponibile, il percorso trasferisce la chiamata con una sintesi essenziale; altrimenti raccoglie una richiesta di seguito. Architect può aiutare a modificare messaggi e workflow in bozza, ma non inventa la disponibilità reale del personale né decide gli impegni commerciali.

Anche questo caso è ipotetico. Il test deve includere assenza di operatori, richiesta insistente e dati incompleti. Il risultato corretto è un esito comprensibile e praticabile. La guida al centralino AI per telefonate mostra perché il passaggio umano sia parte del servizio e non un dettaglio da aggiungere dopo la scelta della voce.

Quali test ripetere dopo una correzione?

Apri la scheda per verificare una bozza Architect

Identifica il problema e conserva il comportamento precedente. Prova la modifica sul caso che ha generato l'errore, su casi simili e su percorsi già funzionanti. Controlla risposte, strumenti, scritture e trasferimento. Pubblica soltanto dopo revisione e prepara una procedura per tornare alla configurazione approvata precedente.

I test non dovrebbero essere composti soltanto da richieste ideali. Servono informazioni mancanti, rumore, cambi di idea, richieste estranee e servizi indisponibili. Anche la decisione di fermarsi deve essere valutata. Un agente che insiste quando non può completare il compito può aumentare frustrazione e rischio.

Il tema si collega ad Aqua e gli errori degli agenti in produzione: l'analisi del comportamento richiede osservazioni e criteri, non soltanto un giudizio sull'eleganza della risposta. Le simulazioni aiutano a esplorare i percorsi, ma devono essere accompagnate da verifiche sul sistema integrato che esegue le operazioni.

Il monitoraggio tecnico basta a capire se l'agente funziona?

No. Un servizio può rispondere correttamente a livello tecnico e lasciare il cliente senza una soluzione. Il team deve osservare esito del compito, passaggi umani e richieste rimaste incomplete. Gli errori degli strumenti sono una parte del quadro; la qualità del servizio comprende anche informazioni corrette e promesse coerenti con le regole aziendali.

Le nuove Make Event subscriptions offrono un esempio di canale per segnalare eventi di una piattaforma di automazione. Non sono una funzione di Architect e non vengono presentate come integrazione pronta. Il collegamento concettuale è la necessità di portare un segnale a una persona che possa agire.

Ogni correzione importante dovrebbe avere un responsabile e una verifica successiva. Se cambia un documento, un calendario o un servizio esterno, alcuni test vanno ripetuti anche senza modificare il prompt. L'agente dipende dal contesto operativo: mantenerne soltanto le istruzioni significa controllare una parte del sistema e ignorare le altre.

Alpha gratuita significa costo nullo del progetto?

No. L'accesso gratuito durante l'alpha riguarda le condizioni indicate per Architect, non elimina il costo dell'agente in esercizio, della telefonia, dell'integrazione o del lavoro di revisione. La durata e le condizioni successive vanno verificate sulle pagine ufficiali e nell'account. Non viene qui assunto un listino futuro. Condizioni dell'alpha.

La distribuzione è graduale: l'annuncio non dimostra che ogni account italiano abbia già accesso. Se la funzione non è presente, il progetto deve poter continuare con procedure di configurazione e test conosciute. Basare tutta la manutenzione su un accesso non verificato crea una dipendenza evitabile.

Per un confronto di livelli, Amazon Nova Sonic è un modello vocale da integrare, mentre Architect assiste la costruzione e manutenzione di agenti nell'ambiente ElevenLabs. La scelta va fatta sul ciclo di lavoro completo e sui requisiti del servizio, senza trattare prodotti con ruoli diversi come sostituti perfetti.

Dove si sbaglia usando un assistente per correggere altri agenti?

Il primo errore è pubblicare una proposta perché la spiegazione sembra convincente. Il secondo è condividere dati sensibili nella chat assumendo la copertura di Zero Retention Mode. Il terzo è correggere un sintomo senza controllare fonte e strumenti. Il quarto è testare soltanto il caso che ha fallito, dimenticando i percorsi già funzionanti.

Un altro errore è lasciare al software una decisione di servizio non definita. Se l'azienda non ha stabilito quando accettare una richiesta o come gestire un reclamo, l'assistente di manutenzione non può trasformare quell'ambiguità in una regola legittima. La persona responsabile deve decidere; il sistema può aiutare a tradurre la decisione in configurazione e test.

Infine, la correzione deve restare comprensibile. Un team che accumula istruzioni contraddittorie può perdere il controllo del comportamento. Quando un'eccezione si ripete, è utile chiedersi se serva un percorso esplicito, una fonte migliore o uno strumento più ristretto, invece di aggiungere un'altra frase al prompt.

Come rendere leggibile la manutenzione nel tempo?

Il team dovrebbe conservare un registro essenziale delle modifiche: problema osservato, componente aggiornato, casi di prova e decisione di pubblicazione. Non serve trasformarlo in un archivio indiscriminato di conversazioni. La traccia deve aiutare un collega a capire cosa sia cambiato e quale comportamento controllare se il problema ritorna.

Quando una correzione viene ritirata, il motivo va mantenuto visibile. Altrimenti una proposta simile può essere pubblicata di nuovo senza ricordare il limite già emerso. Le bozze consentono revisione, ma la memoria del servizio richiede comunque una procedura del team. Il software non sostituisce questa responsabilità organizzativa.

Anche chi riceve i trasferimenti dovrebbe contribuire alle segnalazioni. Può riconoscere informazioni mancanti o promesse fraintese che non emergono dal solo log tecnico. Una nota strutturata, priva di dati eccedenti, rende quel riscontro utilizzabile nella prossima revisione del percorso vocale.

Come iniziare da una chiamata che ha creato un problema?

Scegli una conversazione rappresentativa, ricostruiscila senza dati non necessari e definisci l'esito corretto. Identifica la parte del sistema che potrebbe aver causato il problema. Poi prepara una bozza, confronta il cambiamento e prova il percorso insieme ai casi collegati.

Il deliverable utile è una correzione revisionata con evidenze, non una nuova configurazione priva di spiegazione. Chi gestisce il servizio deve sapere cosa cambia, perché cambia e come capire se il problema ritorna. Questo metodo resta valido anche quando strumenti e condizioni dell'alpha evolvono.

Se il tuo assistente telefonico risponde ma lascia richieste irrisolte, il lavoro sugli agenti AI Giallo può partire da quelle conversazioni. L'obiettivo è collegare diagnosi, regole, strumenti e test in un servizio che il team sappia mantenere e il cliente possa capire.