Salta al contenuto

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

Modelli per integrare l'orchestrazione vocale di ElevenLabs con agenti complessi e con stato

orange mountain on the right side and blue sky on the left

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.

Componenti principali

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:

  • Flusso conversazionale attuale, inclusa l’attività vocale, le interruzioni e l’identificazione dell’oratore attivo.
  • Informazioni specifiche dell’applicazione ricavate dall’analisi in tempo reale della trascrizione, come intenzioni rilevate, entità o sentiment.
  • Traccia del ragionamento, inclusi pensieri intermedi, ipotesi e tentativi precedenti di generare una soluzione.
  • Parametri di configurazione e operativi, come obiettivi attivi, modalità di funzionamento e eventuali vincoli temporanei che guidano il comportamento durante l’interazione.

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:

  • Stato di altri utenti o sistemi con cui interagisce, come obiettivi attuali, disponibilità o permessi.
  • Strumenti e knowledge base, ad esempio API, database o integrazioni che possono influenzare la capacità d’azione dell’agente.
  • Attività in corso e dipendenze che coinvolgono attori o sistemi esterni e che influenzano i prossimi passi dell’agente.

Descriviamo un modello comune per mantenere in modo affidabile queste informazioni durante tutto il ciclo di vita della relazione tra agente e utente.

Componenti della soluzione

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.

diagram describing the flow from user to elevenlabs websocket to custom llm to stateful proxy to external 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.

Comparison of mapping ids for one to one versus one to many cases. In the case of one to many, there is a hierarchy grouping multiple conversations ids together.

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.

Diagram showing the message passing flow between some frontend application and the stateful proxy bypassing the elevenlabs agent.

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.

Uno sguardo al futuro

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!

Scopri gli articoli del team ElevenLabs

Crea con l'audio IA della massima qualità