Integrazione di agenti esterni con l'orchestrazione vocale di ElevenLabs Agents

Gli orchestratori di agenti di frontiera sono sempre più in grado di gestire attività complesse e operare sull'intera suite di strumenti aziendali. Ciò richiede una gestione accurata dello stato dell'applicazione, della conversazione e del sistema. Per le modalità diverse dalla voce, sono emersi pattern comuni sotto il termine ombrello di context engineering, che mira a definire pratiche coerenti attorno al system prompt di un agente man mano che l'interazione procede. L'aggiunta della voce non introduce solo un ulteriore livello di stato per gestire i componenti dell'interazione vocale, ma idealmente consente anche di riutilizzare gli elementi sviluppati in precedenza per altre modalità. 

In questo articolo, spieghiamo come ElevenLabs Agents supporta gli agenti esterni e i pattern che permettono un controllo granulare della loro integrazione. Questi meccanismi consentono ai clienti di sfruttare l'orchestrazione vocale leader di settore di ElevenLabs, mantenendo al contempo la piena proprietà della propria orchestrazione più ampia.

Componenti principali

ElevenLabs Agents

Nella sua forma più semplice, un agente ElevenLabs è accessibile tramite un client WebSocket. Le informazioni che rappresentano gli eventi del server e del client nella conversazione vengono scambiate con l'agente come oggetti JSON. Quando l'agente trascrive il parlato dell'utente, attiva immediatamente una richiesta di generazione. Supportiamo la maggior parte dei principali provider di modelli e consentiamo ai clienti di utilizzare il proprio Custom LLM. Quando si utilizza un orchestratore più complesso (agenti) per rispondere alle richieste di generazione dietro il Custom LLM, i clienti devono assicurarsi che supporti le API Chat Completions o Responses di OpenAI. Fortunatamente, questa specifica di formattazione delle API è facilmente supportata dalla maggior parte dei principali framework per la creazione di agenti (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...). 

Una volta integrati, questi agenti spesso devono poter leggere e aggiornare il proprio stato interno ed esterno in qualsiasi momento, indipendentemente dall'orchestratore vocale a monte. Gestire tutto questo in modo efficace garantisce la coerenza con gli agenti esistenti basati esclusivamente sul testo. 

Gestione dello stato

Per definizione, i dati che un agente deve monitorare per orientarsi efficacemente nel proprio ambiente dipendono fortemente dall'attività. Per gli agenti ElevenLabs basati su un agente esterno, è utile mantenere lo stato in alcune categorie ben definite.

Lo stato interno regola le dinamiche della conversazione. Tra gli elementi monitorati come parte dello stato interno dell'agente rientrano:

• Flusso conversazionale corrente, inclusi attività vocale, interruzioni e identificazione di chi sta parlando.
• Informazioni specifiche dell'applicazione ricavate dall'analisi della trascrizione in tempo reale, come intenti, entità o sentiment rilevati.
• Traccia del ragionamento, inclusi pensieri intermedi, ipotesi e tentativi precedenti di generare una soluzione.
• Parametri di configurazione e operativi, come obiettivi attivi, modalità operativa ed eventuali vincoli temporanei che ne guidano il comportamento durante l'interazione.

Lo stato esterno, invece, si concentra principalmente sui sistemi e sulle persone rilevanti con cui l'agente interagisce o che influenza. Tra gli elementi monitorati come parte dello stato esterno dell'agente rientrano:

• Stato di altri utenti o sistemi con cui interagisce, come obiettivi correnti, disponibilità o autorizzazioni.
• Strumenti e knowledge base, ad esempio API, database o integrazioni che possono influire sulla capacità dell'agente di agire.
• Attività in corso e dipendenze che coinvolgono soggetti o sistemi esterni e che influenzano i passaggi successivi dell'agente.

Descriviamo un pattern comune per mantenere queste informazioni in modo affidabile durante l'intero ciclo di vita della relazione tra un agente e un utente.

Componenti della soluzione

Panoramica 

In questa sezione esaminiamo i componenti dell'architettura e i dettagli di implementazione necessari per integrare con successo agenti esterni complessi. Al centro di questo approccio c'è la capacità di inoltrare un identificatore arbitrario ma univoco, che rappresenta una sessione, attraverso tutti i servizi. Per ElevenLabs Agents che utilizzano LLM personalizzati, puoi farlo semplicemente passando l'identificatore richiesto come parametro LLM nell'oggetto extra body passato come parte degli override della conversazione all'avvio della chiamata. In questo modo l'identificatore passa dall'utente, attraverso l'agente ElevenLabs, fino all'agente esterno. 

Osserva il proxy con stato dietro il LLM personalizzato. Questo servizio, che in genere non è presente, consente di associare singole richieste di generazione a identificatori arbitrari che rappresentano connessioni con l'agente esterno. L'implementazione di questo servizio è responsabilità degli sviluppatori dell'agente esterno. Nella sua forma più semplice, il proxy gestisce connessioni rappresentate da identificatori univoci associati a conversazioni ElevenLabs o SID delle chiamate (per la telefonia). Le versioni più avanzate possono invece introdurre una gerarchia nell'associazione delle conversazioni a relazioni con i clienti più complesse, che si estendono su più interazioni.

In queste configurazioni più avanzate, il proxy mantiene identificatori aggiuntivi che vanno oltre una singola richiesta collegata a una singola sessione downstream. Anziché rappresentare una sola conversazione o un SID di chiamata, ciascun identificatore può essere associato dal proxy a più interazioni correlate. Ciò consente al sistema di seguire i percorsi dei clienti che si sviluppano su più canali, riutilizzare il contesto storico e coordinare più interazioni contemporaneamente. Ad esempio, una singola associazione può raggruppare più sessioni di chat web, una chiamata vocale di follow-up e un workflow di assistenza interno sotto lo stesso identificatore logico del cliente. Il proxy può quindi instradare le richieste all'identificatore corretto in base a semplici regole, preservando al contempo uno stato unificato dietro il LLM personalizzato. Questo permette interazioni multi-step più flessibili e persistenti, gestite dall'agente esterno.

Scambio di messaggi

Oltre ad associare correttamente le richieste di generazione a entità di livello superiore, il proxy con stato può supportare lo scambio bidirezionale di messaggi con fonti esterne, come il frontend dell'applicazione o un servizio router separato, tramite richieste API. Nelle applicazioni in cui ciò è necessario, ElevenLabs Agents non deve essere consapevole che i messaggi vengono trasmessi ad altri servizi.  

Ad esempio, spesso è utile che gli agenti esterni abbiano visibilità sull'attività vocale in corso, così da poter determinare se l'utente sta parlando, per quanto tempo e se debbano intervenire in anticipo. Puoi ricavare e utilizzare direttamente queste informazioni passando i punteggi elaborati del rilevamento dell'attività vocale (VAD) forniti da ElevenLabs Agents come eventi client ricevuti tramite il websocket della conversazione. Quando riceve i punteggi da ElevenLabs, l'applicazione client può inoltrare gli eventi client VAD al proxy con stato in base ai requisiti dell'applicazione, assicurandosi di includere nel messaggio l'identificatore arbitrario della sessione. Il proxy con stato deve implementare una logica di associazione delle richieste che identifichi in modo ottimale la connessione esistente per la sessione. 

Questo pattern può essere esteso per supportare qualsiasi evento proveniente dal client, purché possa essere espresso come blocco JSON. Tuttavia, è utile anche esporre gli eventi che hanno origine dall'agente stesso. Un esempio comune riguarda il ciclo di vita delle chiamate agli strumenti o delle query alla knowledge base, che rappresentano operazioni su sistemi esterni. Questi meccanismi sono fondamentali per gli agenti che le aziende stanno creando oggi.

Quando integri agenti esterni tramite un LLM personalizzato, le funzionalità di tool calling e generazione aumentata dal recupero di informazioni (RAG) di ElevenLabs vengono spesso aggirate a favore dell'implementazione dell'agente esterno. Di conseguenza, la responsabilità di questi componenti ricade interamente sul provider dell'agente esterno. Le applicazioni beneficiano comunque della visibilità sull'attività degli strumenti, poiché consente loro di mostrare i progressi dell'agente e aggiornare di conseguenza l'esperienza dell'utente finale.

Per offrire questa visibilità, l'agente esterno emette messaggi ogni volta che vengono richiamati strumenti, sia per le richieste sia per le risposte. Il proxy con stato inoltra questi messaggi alle applicazioni client, che li gestiscono tramite una coda di messaggi dedicata. Questo rispecchia i meccanismi utilizzati dagli eventi client di ElevenLabs Agents e garantisce che le applicazioni possano rilevare quando l'agente legge da un sistema esterno o lo modifica.

Quindi, l'uso di questi componenti principali e l'abilitazione dello scambio bidirezionale di messaggi tra il proxy e l'applicazione client consentono ai clienti di integrare agenti esterni in ElevenLabs Agents per utilizzare esclusivamente l'orchestrazione vocale fornita, mantenendo al contempo la proprietà di tutte le componenti dell'orchestrazione LLM. 

Collegamento con lo stato

Per supportare efficacemente agenti esterni complessi è necessaria una chiara divisione delle responsabilità tra il proxy e l'agente, soprattutto per quanto riguarda la gestione dello stato. In questo modello, il proxy è responsabile del mantenimento di una tabella delle interazioni rilevanti, raggruppate in base alle esigenze dell'applicazione, e dell'instradamento dei messaggi tra sé e l'agente tramite una logica che rimane stateless. A sua volta, l'agente esterno dovrebbe gestire e archiviare tutte le informazioni interne ed esterne sostanziali che contribuiscono allo stato complessivo.

Sebbene rendere meno netta questa separazione possa ridurre ulteriormente il lavoro di rielaborazione di una soluzione esistente, mantenere un confine rigoroso porta generalmente a risultati più solidi e scalabili man mano che aumenta l'insieme di attività dell'agente.

Uno sguardo al futuro

Man mano che le organizzazioni maturano nell'adozione di agenti abilitati alla voce e non, prevediamo che i pattern relativi alle informazioni richieste da questi agenti si consolideranno, consentendoci di semplificare lo sviluppo e la gestione dei servizi descritti in questo articolo. Nel frattempo, continuiamo a sviluppare in base ai requisiti già emersi. Il nostro team Forward Deployed Engineering collabora strettamente con i clienti per trasformare queste esigenze emergenti in funzionalità concrete del prodotto e garantire che le nostre soluzioni evolvano di pari passo con le implementazioni nel mondo reale.

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!