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 schemi comuni riuniti sotto il termine context engineering, che mira a definire pratiche coerenti attorno al system prompt di un agente man mano che l'interazione procede. L'introduzione della voce non aggiunge soltanto un ulteriore livello di stato per gestire i componenti dell'interazione vocale, ma idealmente permette anche di riutilizzare gli artefatti del lavoro svolto in precedenza su altre modalità. 

In questo articolo, illustriamo come ElevenLabs Agents supporti gli agenti esterni e gli schemi che consentono un controllo granulare della loro integrazione. Questi meccanismi permettono ai clienti di sfruttare l'orchestrazione vocale di ElevenLabs, tra le migliori della categoria, mantenendo al tempo stesso il pieno controllo 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 passano da e verso 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 usare 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 Chat Completions o Responses API di OpenAI. Fortunatamente, questa specifica di formattazione delle API è supportata facilmente dalla maggior parte dei principali framework per la creazione di agenti (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...). 

Una volta integrati, questi agenti richiedono spesso la possibilità di leggere e aggiornare il proprio stato interno ed esterno in qualsiasi momento, indipendentemente dall'orchestratore vocale a cui sono collegati. Gestirlo in modo efficace garantisce coerenza con gli agenti esistenti basati solo sul testo. 

Gestione dello stato

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

Lo stato interno regola le dinamiche della conversazione. Esempi di elementi monitorati come parte dello stato interno dell'agente includono:

• Flusso conversazionale corrente, inclusi attività vocale, interruzioni e identificazione dell'interlocutore attivo.
• Informazioni specifiche dell'applicazione ricavate dall'analisi delle trascrizioni 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. Esempi di elementi monitorati come parte dello stato esterno dell'agente includono:

• 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à di azione dell'agente.
• Attività in corso e dipendenze che coinvolgono attori o sistemi esterni e che influenzano i passaggi successivi dell'agente.

Descriviamo uno schema 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 architetturali 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 usano LLM personalizzati, è possibile farlo semplicemente passando l'identificatore richiesto come parametro LLM nell'oggetto extra body passato come parte delle conversation overrides durante l'avvio della chiamata. Così l'identificatore passa attraverso l'agente ElevenLabs, dall'utente fino all'agente esterno. 

Osserva il proxy con stato dietro il Custom LLM. Questo servizio, generalmente non presente, consente di associare le 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, invece, possono introdurre una gerarchia nell'associazione delle conversazioni a relazioni con i clienti più complesse, che comprendono più interazioni.

In queste configurazioni più avanzate, il proxy mantiene identificatori aggiuntivi che vanno oltre una singola richiesta legata a una singola sessione downstream. Anziché rappresentare una sola conversazione o un solo 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 spostano tra diversi 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 Custom LLM. Questo permette interazioni multi-step più flessibili e persistenti, gestite dall'agente esterno.

Scambio di messaggi

Oltre ad associare con successo 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 è 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, per determinare se l'utente sta parlando, per quanto tempo e se debbano intraprendere azioni preventive. Queste informazioni possono essere ricavate direttamente e utilizzate trasmettendo i punteggi elaborati di 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 schema può essere esteso per gestire qualsiasi evento dal client, a condizione che possa essere espresso come blocco JSON. Tuttavia, è utile esporre anche 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 Custom LLM, le funzionalità di tool calling e generazione aumentata dal recupero delle informazioni (RAG) di ElevenLabs vengono spesso bypassate a favore dell'implementazione dell'agente esterno. Di conseguenza, la responsabilità di questi componenti ricade interamente sul provider dell'agente esterno. Le applicazioni traggono comunque vantaggio dalla 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 invocati strumenti, sia per le richieste sia per le risposte. Questi messaggi vengono inoltrati dal proxy con stato alle applicazioni client, che li gestiscono tramite una message queue dedicata. Questo rispecchia i meccanismi utilizzati dagli eventi client di ElevenLabs Agents e garantisce che le applicazioni possano monitorare quando l'agente legge da un sistema esterno o lo modifica.

Pertanto, usare questi componenti principali e abilitare lo scambio bidirezionale di messaggi tra il proxy e l'applicazione client permette ai clienti di integrare agenti esterni in ElevenLabs Agents, utilizzando strettamente l'orchestrazione vocale offerta e mantenendo il controllo su tutte le parti dell'orchestrazione LLM. 

Collegamento con lo stato

Supportare efficacemente agenti esterni complessi richiede 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é stesso e l'agente usando una logica che rimane stateless. L'agente esterno, a sua volta, dovrebbe gestire e archiviare tutte le informazioni interne ed esterne sostanziali che contribuiscono allo stato complessivo.

Sebbene attenuare questa separazione possa ridurre ulteriormente la rielaborazione di una soluzione esistente, mantenere un confine netto porta generalmente a risultati più solidi e scalabili man mano che cresce l'insieme di attività dell'agente.

Prospettive future

Man mano che le organizzazioni maturano nell'adozione di agenti abilitati alla voce e non, ci aspettiamo che gli schemi relativi alle informazioni richieste da questi agenti si consolidino, permettendoci di semplificare lo sviluppo e la responsabilità dei servizi descritti in questo articolo. Nel frattempo, continuiamo a sviluppare soluzioni per i requisiti già emersi. Il nostro team Forward Deployed Engineering collabora a stretto contatto 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 reali.

Se lavori già con un agente esistente e desideri abilitare la voce con ElevenLabs Agents mantenendo il controllo sulla tua orchestrazione LLM, prova questo approccio e facci sapere cosa ne pensi!