
Come rendere il Text to Speech meno robotico
- Categoria
- Risorse
- Data
Modelli per integrare l'orchestrazione vocale di ElevenLabs con agenti complessi e con stato
Gli orchestratori di agenti di nuova generazione sono sempre più in grado di gestire compiti complessi e di operare su tutta la suite di strumenti aziendali. Questo richiede una gestione attenta dello stato di applicazioni, conversazioni e sistemi. Per le modalità diverse dalla voce, si sono affermati modelli comuni sotto il termine ombrello di context engineering, che punta a costruire pratiche coerenti attorno al system prompt dell’agente man mano che l’interazione avanza. Integrare la voce non solo introduce un ulteriore livello di stato per gestire i componenti dell’interazione vocale, ma idealmente permette anche di riutilizzare elementi già sviluppati per altre modalità.
In questo articolo spieghiamo come ElevenLabs Agents supporta agenti esterni e i modelli che permettono un controllo dettagliato sulla loro integrazione. Questi meccanismi ti consentono di sfruttare l’orchestrazione vocale di ElevenLabs mantenendo la piena proprietà della tua orchestrazione più ampia.
ElevenLabs Agents
Nella sua forma più semplice, un ElevenLabs Agent è accessibile tramite un client Websocket. Le informazioni che rappresentano eventi server e client nella conversazione vengono scambiate con l’agente come oggetti JSON. Quando l’agente trascrive la voce dell’utente, attiva immediatamente una richiesta di generazione. Supportiamo la maggior parte dei principali provider di modelli e permettiamo ai clienti di utilizzare il proprio LLM personalizzato. Quando si utilizza un orchestratore più complesso (agenti) per rispondere alle richieste di generazione dietro al Custom LLM, è necessario assicurarsi che supporti le API Chat Completions o Responses di OpenAI. Fortunatamente, questa specifica di formattazione API è facilmente supportata dalla maggior parte dei principali framework per agenti (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...).
Una volta integrati, questi agenti spesso hanno bisogno di leggere e aggiornare il proprio stato interno ed esterno in qualsiasi momento, indipendentemente dall’orchestratore vocale utilizzato. Gestire questo aspetto in modo efficace garantisce coerenza con gli agenti solo testuali già esistenti.
Gestione dello stato
Per definizione, i dati che un agente deve tracciare per muoversi efficacemente nel suo ambiente sono molto specifici per il compito. Per gli ElevenLabs Agents alimentati da un agente esterno, è utile mantenere lo stato su alcune categorie ben definite.
Lo stato interno regola la dinamica della conversazione. Esempi di elementi tracciati come stato interno dell’agente includono:
Lo stato esterno, invece, si concentra principalmente su sistemi e persone con cui l’agente interagisce o che influenza. Esempi di elementi tracciati come stato esterno dell’agente includono:
Descriviamo un modello comune per mantenere in modo affidabile queste informazioni durante tutto il ciclo di vita della relazione tra agente e utente.
Panoramica
In questa sezione vediamo i componenti architetturali e i dettagli di implementazione necessari per integrare con successo agenti esterni complessi. Al centro di questo approccio c’è la possibilità di trasmettere un identificatore arbitrario ma univoco che rappresenta una sessione tra tutti i servizi. Per gli ElevenLabs Agents che usano custom LLM, questo si può fare semplicemente passando l’identificatore richiesto come parametro LLM all’interno dell’extra body object inviato come parte delle sostituzioni nella conversazione all’avvio della chiamata. In questo modo l’identificatore viene trasmesso dall’utente fino all’agente esterno tramite l’ElevenLabs Agent.

Nota il proxy con stato dietro al custom LLM. Questo servizio, che di solito non è presente, ci permette di associare le singole richieste di generazione a identificatori arbitrari che rappresentano le connessioni con l’agente esterno. La responsabilità dell’implementazione di questo servizio è degli sviluppatori dell’agente esterno. Nella sua forma più semplice, il proxy gestisce connessioni rappresentate da identificatori univoci che mappano alle conversazioni ElevenLabs o ai call SID (per la telefonia). Versioni più avanzate possono introdurre una gerarchia nella mappatura delle conversazioni per gestire relazioni cliente più complesse che coprono più interazioni.

In queste configurazioni avanzate, il proxy mantiene identificatori aggiuntivi che vanno oltre la singola richiesta legata a una sola sessione a valle. Invece di associare ogni identificatore a una sola conversazione o call SID, il proxy può collegare un identificatore a più interazioni correlate. Questo permette al sistema di seguire il percorso del cliente tra diversi canali, riutilizzare il contesto storico e coordinare più interazioni contemporaneamente. Ad esempio, una singola mappatura può raggruppare più sessioni di chat web, una chiamata vocale di follow-up e un workflow di supporto interno sotto lo stesso identificatore cliente. Il proxy può poi instradare le richieste all’identificatore corretto in base a regole semplici, mantenendo uno stato unificato dietro al custom LLM. Questo consente interazioni multi-step più flessibili e persistenti gestite dall’agente esterno.
Scambio di messaggi
Oltre a mappare correttamente le richieste di generazione a entità di ordine superiore, il proxy con stato può supportare lo scambio bidirezionale di messaggi verso fonti esterne come il frontend dell’applicazione o un servizio router separato tramite richieste API. Nelle applicazioni dove questo è necessario, gli ElevenLabs Agents non devono essere a conoscenza del fatto che i messaggi vengono inoltrati ad altri servizi.
Ad esempio, spesso è utile che gli agenti esterni abbiano visibilità sull’attività vocale in corso, così da capire se l’utente sta parlando, per quanto tempo e se è il caso di agire in anticipo. Queste informazioni possono essere ricavate e utilizzate direttamente passando i punteggi di voice activity detection (VAD) elaborati dagli ElevenLabs Agents come eventi client ricevuti tramite il websocket della conversazione. Quando riceve i punteggi da ElevenLabs, l’applicazione client può inoltrare gli eventi VAD al proxy con stato in base alle esigenze, assicurandosi di includere l’identificatore di sessione nel messaggio. È necessario che il proxy con stato implementi una logica di mappatura delle richieste che identifichi in modo ottimale la connessione esistente per la sessione.
Questo modello può essere esteso a qualsiasi evento proveniente dal client, purché sia espresso come blocco JSON. Tuttavia, è utile anche esporre eventi che hanno origine direttamente dall’agente. Un esempio comune riguarda il ciclo di vita delle chiamate a strumenti o delle query alle knowledge base che rappresentano operazioni su sistemi esterni. Questi meccanismi sono fondamentali per gli agenti che le aziende stanno costruendo oggi.
Quando si integrano agenti esterni tramite un custom LLM, spesso le funzionalità di tool calling e retrieval augmented generation (RAG) di ElevenLabs vengono bypassate a favore dell’implementazione dell’agente esterno. Di conseguenza, la responsabilità di questi componenti è interamente del provider dell’agente esterno. Le applicazioni beneficiano comunque della visibilità sull’attività degli strumenti, perché permette di mostrare i progressi dell’agente e aggiornare l’esperienza dell’utente finale.
Per offrire questa visibilità, l’agente esterno invia messaggi ogni volta che vengono utilizzati strumenti, sia per le richieste che per le risposte. Questi messaggi vengono inoltrati dal proxy con stato alle applicazioni client, che li gestiscono tramite una coda messaggi dedicata. Questo rispecchia i meccanismi usati dagli eventi client degli ElevenLabs Agents e garantisce che le applicazioni possano tracciare quando l’agente legge o modifica un sistema esterno.

Quindi, utilizzando questi componenti principali e abilitando lo scambio bidirezionale di messaggi tra proxy e applicazione client, puoi integrare agenti esterni all’interno di ElevenLabs Agents per sfruttare esclusivamente l’orchestrazione vocale offerta, mantenendo la proprietà di tutta l’orchestrazione LLM.
Collegamento con lo stato
Supportare agenti esterni complessi in modo efficace richiede una chiara divisione delle responsabilità tra proxy e agente, soprattutto nella gestione dello stato. In questo modello, il proxy si occupa di mantenere una tabella delle interazioni rilevanti, raggruppate secondo le esigenze dell’applicazione, e di instradare i messaggi tra sé e l’agente usando una logica che resta stateless. L’agente esterno invece deve gestire e conservare tutte le informazioni interne ed esterne che contribuiscono allo stato complessivo.
Anche se allentare questa separazione può ridurre il lavoro di adattamento di una soluzione esistente, mantenere un confine netto porta generalmente a risultati più robusti e scalabili man mano che i compiti dell’agente aumentano.
Man mano che le organizzazioni maturano nell’adozione di agenti vocali e non vocali, ci aspettiamo che i modelli per le informazioni richieste da questi agenti si consolidino, permettendoci di semplificare lo sviluppo e la gestione dei servizi descritti in questo articolo. Nel frattempo, continuiamo a lavorare sulle esigenze già emerse. Il nostro team di ingegneria Forward Deployed collabora a stretto contatto con i clienti per trasformare questi bisogni emergenti in funzionalità concrete e garantire che le nostre soluzioni evolvano insieme alle implementazioni reali.
Se stai già lavorando con un agente esistente e vuoi abilitare la voce con ElevenLabs Agents mantenendo la proprietà della tua orchestrazione LLM, prova questo approccio e facci sapere cosa ne pensi!



