Analisi del motore di orchestrazione di ElevenAgent

ElevenAgents sono alimentati da un motore di orchestrazione a bassa latenza progettato appositamente per le conversazioni in tempo reale, aggiungendo meno di 100ms di latenza. Questa architettura unisce il meglio della ricerca ElevenLabs con LLM di frontiera dei principali provider come OpenAI, Google e Anthropic, insieme a modelli open-source selezionati forniti da ElevenLabs. Utilizzando più modelli in diverse fasi della pipeline di risposta, l’agente garantisce conversazioni molto reattive e consapevoli del contesto. Sfruttando dinamicamente i punti di forza di ogni modello in sinergia, otteniamo prestazioni affidabili e scalabili su una vasta gamma di compiti enterprise e scenari conversazionali, ottimizzando il bilanciamento tra intelligenza, velocità e costi.

In questo articolo spieghiamo come questi modelli lavorano insieme per offrire le funzionalità fondamentali di cui gli agenti hanno bisogno per operare in ambienti complessi, e nello specifico quali modelli vedono quali token e quando. Al centro di tutto c’è la gestione della cronologia della conversazione nei diversi momenti dell’interazione. Torneremo su come e dove la cronologia viene condivisa per chiarire il suo ruolo nell’orchestrazione sia per workflow indipendenti che multi-agente.

Agente indipendente

Iniziamo analizzando l’agente indipendente e i suoi componenti principali. È ragionevole considerare che l’agente minimamente utile abbia un prompt di sistema, accesso a diversi strumenti e una knowledge base. I clienti dovrebbero preferire agenti indipendenti ai workflow quando il loro caso d’uso richiede un controllo limitato sulla sequenza delle azioni o quando è importante evitare silos di conoscenza tra gli agenti. I silos di conoscenza si creano quando alcuni strumenti, documenti o contesti storici sono accessibili solo ad alcuni sotto-agenti ma non ad altri. Questo è tipico dei workflow multi-agente e comporta un compromesso tra flessibilità e determinismo.

Per gli agenti indipendenti in ElevenLabs, è importante capire come:

• Costruiscono richieste di generazione efficaci
• Recuperano e integrano documenti rilevanti
• Generano ed eseguono chiamate agli strumenti per informare le risposte dell’agente
• Producono risultati per valutazione e raccolta dati

Costruire il contesto della conversazione 

Una conversazione tra un cliente e un agente ElevenLabs è composta da una serie di turni, dove ogni turno prevede uno scambio di messaggi tra le due parti. Questa sequenza alternata di messaggi dell’agente e dell’utente è il punto di partenza per costruire il contesto della conversazione. Durante ogni turno, l’LLM sottostante riceve richieste di generazione che includono una serie di messaggi alternati tra agente e utente, più lunga di un messaggio rispetto al turno precedente. Questa serie di messaggi è sempre preceduta da un unico messaggio di sistema che rappresenta il prompt di sistema dell’agente.

L’orchestratore ElevenLabs riduce la latenza percepita dell’LLM prevedendo quando l’utente ha terminato di parlare. In alcuni casi, questo può portare a più richieste di generazione LLM con lo stesso contesto conversazionale all’interno di un singolo turno. L’orchestrazione ottimizza la rapidità di risposta degli agenti, ma la qualità della risposta dipende altrettanto da come viene gestita la conoscenza. Man mano che i clienti avanzano, di solito iniziano a basare le risposte degli agenti su una combinazione di documentazione proprietaria e contenuti pubblici. Da diversi anni, la retrieval-augmented generation (RAG) è l’approccio standard per ottenere questo risultato.Le Knowledge Base di ElevenAgents si basano su RAG con un’architettura multi-modello ottimizzata che abbiamo descritto in un post precedente. Questo permette di recuperare documenti in modo affidabile anche quando l’ultimo input dell’utente è un follow-up, una conferma o non contiene una domanda esplicita.

Il recupero, però, è solo uno dei modi in cui gli agenti interagiscono con sistemi esterni.

Agire e recuperare informazioni tramite strumenti

Gli agenti ElevenLabs possono compiere azioni reali e recuperare informazioni in tempo reale durante la conversazione grazie a un sistema di strumenti flessibile. Questa possibilità introduce una considerazione importante: ogni strumento abilitato aumenta la dimensione del prompt serializzato, poiché nome, descrizione e schema dei parametri vengono inclusi insieme al prompt di sistema e alla cronologia della conversazione. Aggiungendo più strumenti, aumenta anche il carico di ragionamento richiesto al modello per scegliere la sequenza corretta di strumenti da usare. Nell’Agent Builder, la descrizione dello strumento spiega cosa fa e quali campi restituisce. Queste sono le informazioni che il modello linguistico usa per capire il contesto d’uso. Una volta definite, le condizioni specifiche per invocare lo strumento vanno inserite nel prompt di sistema dell’agente. Ad esempio:

• Descrizione dello strumento per lookup_order: “Recupera i dettagli dell’ordine di un cliente tramite ID ordine. Restituisce stato dell’ordine, articoli acquistati, indirizzo di spedizione e numero di tracking.”
• Istruzione nel prompt di sistema: “Dopo aver verificato l’identità del cliente, chiama lo strumento lookup_order per recuperare i dettagli dell’ordine.”

Questa separazione permette di riutilizzare le definizioni degli strumenti tra diversi agenti, lasciando al prompt di sistema di ciascun agente il controllo sul momento esatto in cui invocarli. Per aiutare i clienti a progettare prompt di sistema efficaci, offriamo indicazioni approfondite nella nostra Guida al Prompting. In questo framework, si possono definire diversi tipi di strumenti, principalmente:

• Webhook tool che chiamano API esterne.
• Client tool che inviano richieste come eventi tramite websocket della conversazione.
• System tool per azioni integrate come trasferimenti di chiamata.
• MCP tool che si collegano a server Model Context Protocol.

Ogni volta che un agente decide di usare uno strumento, recupera i dettagli necessari dalla conversazione e invia una richiesta per eseguirlo. Quando lo strumento restituisce un risultato, questo viene aggiunto alla conversazione così il modello può farvi riferimento nella risposta successiva. Se necessario, l’output dello strumento può anche aggiornare le informazioni memorizzate dall’agente come variabile dinamica. Queste informazioni vengono salvate come semplici coppie chiave-valore, estratte dalla risposta dello strumento tramite mapping predefiniti. Una volta impostate, queste variabili possono essere riutilizzate dal prompt di sistema dell’agente, dai parametri dei futuri strumenti e dalle condizioni dei workflow. Questo ciclo di feedback fornisce agli agenti una sorta di memoria di lavoro che evolve durante l’interazione.

Se questa è la logica di integrazione degli strumenti nel ragionamento dell’agente, anche il momento della loro esecuzione può essere configurato. Gli strumenti possono essere eseguiti in tre modalità, ognuna adatta a un’esigenza conversazionale diversa. In Immediate Mode, lo strumento viene eseguito appena richiesto dall’LLM. È la modalità predefinita per ricerche rapide in cui l’utente si aspetta una risposta quasi istantanea, come la verifica dello stato di un ordine. Se combinata con pre-tool speech, l’agente genera prima una breve conferma come “Controllo subito” e la invia all’utente mentre lo strumento viene eseguito in parallelo, riducendo i tempi morti. Per strumenti più lenti, la piattaforma estende automaticamente questi messaggi di attesa in base al tempo previsto. In Post-Tool Speech Mode, invece, l’esecuzione viene ritardata fino a quando l’agente ha terminato di parlare. Questo è essenziale per azioni con conseguenze reali, come trasferire una chiamata, chiudere una sessione o inviare un pagamento. L’utente sente tutto il contesto, ad esempio “Ora ti trasferisco alla fatturazione”, e può interrompere prima che l’azione venga eseguita. In Async Mode, lo strumento viene eseguito completamente in background senza interrompere la conversazione. Questa modalità è ideale per operazioni “fire-and-forget” come inviare un’email, avviare un workflow esterno o registrare dati, quando l’agente non deve fare riferimento al risultato nella risposta.

Definite esecuzione e orchestrazione, il passo successivo è capire come misurare le prestazioni.

Misurare le prestazioni

Dopo una chiamata con un Agent, i clienti possono voler estrarre alcune parti della chiamata per analisi, archiviazione o per capire se la chiamata è andata a buon fine. Qui entrano in gioco la Raccolta Dati e i Criteri di Valutazione. La Raccolta Dati ti permette di estrarre informazioni strutturate dalla trascrizione della chiamata per analisi e aggregazioni successive. Spesso i clienti esportano questi dati nel proprio data lakehouse aziendale per reportistica o workflow di arricchimento. Ad esempio, un Sales Development Agent può estrarre automaticamente i dati di un potenziale cliente da una conversazione per creare o aggiornare un lead nel sistema CRM. I Criteri di Valutazione, invece, determinano se una chiamata è considerata riuscita. Se tutti i criteri configurati sono soddisfatti, la chiamata viene segnata come riuscita; altrimenti viene segnalata come fallita. Questo garantisce che le conversazioni rispettino sempre gli standard di qualità e integrità definiti, offrendo feedback immediato. Una volta conclusa la chiamata e attivato il webhook post-chiamata, l’agente elabora la trascrizione finale, incluse eventuali esecuzioni di strumenti e metadati, tramite un LLM insieme a tutti i punti di raccolta dati e criteri di valutazione configurati. Il modello usa questo prompt combinato per verificare se ogni criterio è soddisfatto ed estrarre i dati richiesti per le analisi successive. Poiché l’LLM interpreta queste configurazioni direttamente come parte del prompt di input, è importante formattarle in modo chiaro e coerente affinché il modello possa comprenderle e applicarle correttamente. Per questo consigliamo le seguenti best practice per scrivere descrizioni di Criteri di Valutazione e Raccolta Dati.

Criteri di valutazione

1. Un obiettivo chiaro per ogni criterio: una frase o un breve punto elenco è meglio di più obiettivi nello stesso criterio.
2. Osservabile e basato sulla trascrizione: formula l’obiettivo in modo che il successo/fallimento sia determinabile dalla trascrizione (cosa è stato detto, cosa ha fatto l’agente, cosa ha chiesto l’utente). Evita obiettivi che richiedono contesto esterno non disponibile all’LLM.
3. Esiti espliciti di successo/fallimento/sconosciuto: l’LLM sa già che per segnare come riuscito l’obiettivo deve essere raggiunto, come fallito se non lo è, e come sconosciuto se non può dedurlo dalla trascrizione. Quindi l’obiettivo va scritto in modo che “raggiunto” e “non raggiunto” siano ben definiti; se è ambiguo, il modello potrebbe classificare come sconosciuto o sbagliare.
4. Sii conciso: a volte vengono inviati molti criteri di valutazione insieme. Criteri troppo lunghi possono creare rumore e causare allucinazioni.
5. La lingua conta: ogni motivazione fornita dall’LLM sul raggiungimento o meno di un criterio sarà nella stessa lingua della descrizione del criterio, quindi è importante tenerlo presente.

Raccolta dati

1. Descrivi esattamente cosa estrarre: la descrizione è il segnale principale per l’LLM. Spiega cosa significa il campo, in quale situazione va valorizzato e cosa fare se non è chiaro (es. “Lascia vuoto se il cliente non ha indicato una data preferita”).
2. Rispetta il tipo atteso: il valore fornito dall’LLM corrisponderà sempre al tipo di dato assegnato al punto di raccolta (es. boolean, string, integer ecc). La descrizione deve essere coerente con questo. Ad esempio, puoi scrivere “Estrai il numero di articoli richiesti” per integer, e “Sì/no se il cliente ha accettato l’offerta” per boolean.
3. Usa enum quando possibile: per i campi stringa, se i valori possibili sono fissi, usa enum nello schema; questo vincola il modello e riduce output non validi.
4. Un solo target di estrazione per voce: Non inserire più fatti non correlati nella descrizione di un solo campo; suddividi in più voci così ogni chiamata ha un target di estrazione chiaro.
5. Descrizioni brevi: Le descrizioni possono essere di poche frasi; non servono lunghi paragrafi. La trascrizione è già nel messaggio utente, quindi schema + breve descrizione bastano.

Attualmente, l’LLM usato per questa fase di valutazione ed estrazione è fisso su un modello a bassa latenza per garantire elaborazione rapida. A breve introdurremo opzioni per offrire ai clienti maggiore flessibilità.

Ora ci concentriamo sui casi d’uso che richiedono orchestrazione strutturata, determinismo o specializzazione su più ruoli conversazionali, dove i clienti possono usare i Workflow.

Workflow

I Workflow offrono un’interfaccia visuale per progettare flussi conversazionali complessi. Generano l’oggetto logico usato dall’orchestratore per gestire più sotto-agenti, strumenti e trasferimenti sotto un unico identificativo di agente indipendente. I Workflow introducono componenti aggiuntivi rispetto a quelli già visti per gli agenti indipendenti, tra cui:

• Interazione tra prompt di sistema e obiettivi conversazionali dei sotto-agenti.
• Gestione dei passaggi tra i vari punti di transizione nel grafo.

Obiettivi conversazionali specializzati

I Workflow riutilizzano le funzionalità degli agenti indipendenti per garantire comportamenti coerenti durante tutta l’interazione. Questo include elementi condivisi come il prompt di sistema di base, strumenti principali e knowledge base globali che devono essere sempre disponibili, indipendentemente dalla fase attiva del workflow. Il prompt di sistema principale di solito definisce il contesto globale della conversazione, il tono atteso, i vincoli di sicurezza e qualsiasi istruzione specifica del brand o del prodotto.

Su questa base condivisa, i Workflow introducono sotto-agenti specializzati che operano all’interno di un grafo diretto. A ciascun sotto-agente viene assegnato un obiettivo specifico e viene arricchita la configurazione di base con istruzioni aggiuntive, strumenti e fonti di conoscenza rilevanti solo per il suo ruolo. Invece di ridefinire tutta la configurazione conversazionale, i sotto-agenti aggiungono la loro intenzione al base agent tramite composizione del prompt ed estensione selettiva del contesto. La cronologia della conversazione viene mantenuta tra i passaggi per garantire continuità, ma ogni sotto-agente opera con una visione volutamente limitata del sistema. Knowledge base e strumenti sono esposti in modo selettivo, creando silos chiari che impediscono sovrapposizioni di responsabilità. Per rafforzare questa separazione, l’oggetto orchestratore viene ricostruito a ogni transizione come se fosse un agente indipendente. Così lo stato del prompt, la configurazione e le capacità disponibili del sotto-agente attivo restano sempre deterministici. Questo design permette ai Workflow di mantenere coerenza globale e specializzazione locale, ottenendo comportamenti prevedibili, separazione chiara delle responsabilità e controllo preciso su come contesto, conoscenza e azioni vengono applicati in ogni fase dell’interazione.

Uno dei meccanismi chiave che rende possibile questo controllo è la gestione delle transizioni tra sotto-agenti.

Gestire le transizioni dei workflow con condizioni LLM

I Workflow avanzano attraversando un grafo diretto di sotto-agenti, dove le transizioni tra i nodi sono controllate da condizioni esplicite. Queste condizioni determinano quando il controllo deve passare da un sotto-agente all’altro e permettono ai workflow di rispondere agli input dell’utente, ai risultati degli strumenti e alle variabili dinamiche. Le condizioni del grafo possono essere deterministiche o valutate dall’LLM. Le condizioni deterministiche, come transizioni incondizionate, controlli su espressioni di variabili dinamiche o risultati degli strumenti, garantiscono un flusso di controllo rigoroso e sono ideali per far rispettare una progressione precisa nel workflow. Le condizioni basate su LLM, invece, permettono valutazioni semantiche di criteri in linguaggio naturale, come rilevare l’intento dell’utente o riconoscere quando sono state fornite informazioni specifiche.

È importante sottolineare che le condizioni LLM vengono valutate al di fuori del prompt di sistema dell’agente attivo e non influenzano il comportamento generativo dell’agente. Vengono invece valutate in parallelo dall’orchestratore rispetto allo stato attuale della conversazione. Questa separazione garantisce che la logica di transizione non contamini il prompt dell’agente né influenzi la generazione delle risposte, pur consentendo ai workflow di sfruttare il ragionamento LLM per una navigazione flessibile del grafo. Combinando condizioni deterministiche e valutate da LLM, i workflow possono ottenere sia prevedibilità che adattabilità, usando transizioni deterministiche dove la correttezza è fondamentale e transizioni LLM dove serve interpretazione semantica.

Quando una conversazione passa a una nuova fase, il sistema attiva una versione dell’agente adattata a quello specifico step. Ogni fase opera con istruzioni mirate e accesso solo alle conoscenze e agli strumenti rilevanti per la propria responsabilità. Ad esempio, una fase di gestione rimborsi può consultare le policy di rimborso senza ereditare contesti non pertinenti da onboarding o triage. Il passaggio tra le fasi è regolato da condizioni di transizione esplicite. Queste condizioni determinano quando spostare la responsabilità e permettono di instradare la conversazione in modo naturale man mano che si sviluppa. Per garantire continuità, l’esperienza dell’utente resta fluida tra le transizioni, con ogni fase che eredita il contesto conversazionale rilevante senza esporre le meccaniche del passaggio. Sono previsti anche controlli sulle transizioni per evitare cicli improduttivi, assicurando che il workflow resti stabile e orientato all’obiettivo.

Sicurezza e protezione

Per i casi che richiedono maggiori controlli di sicurezza, i clienti possono affidarsi a componenti aggiuntivi dell’orchestratore.

Guardrail

Gli Agent ElevenLabs implementano guardrail di sicurezza tramite un sistema di moderazione e allineamento configurabile che valuta in tempo reale i messaggi di utente e agente. I contenuti in ingresso vengono classificati su più categorie di rischio, tra cui contenuti sessuali, violenza, molestie, odio e autolesionismo, ciascuna con soglie configurabili in modo indipendente. Quando viene attivato un guardrail, la conversazione viene immediatamente interrotta e il client riceve una notifica con la motivazione. Questo garantisce che le interazioni non sicure vengano bloccate subito e in modo coerente, senza affidarsi solo a mitigazioni basate sui prompt. I guardrail operano al di fuori della logica del prompt dell’agente, offrendo un livello di enforcement affidabile che non può essere aggirato dal comportamento del modello o dagli input dell’utente. Questo approccio consente ai clienti di regolare la sensibilità della sicurezza in base al proprio dominio, mantenendo enforcement deterministico a runtime.

Gestione dati conforme

A volte chi parla può condividere informazioni sensibili con un agente, soggette a requisiti stringenti di archiviazione e trattamento, ad esempio dati medici che richiedono gestione conforme HIPAA. Per questi casi, offriamo la Zero Retention Mode (ZRM) a livello di Agent o Workspace. Quando attiva, tutti i dati della chiamata vengono elaborati solo in memoria e mai salvati su storage persistente. Una volta conclusa la chiamata e l’elaborazione, nessuna informazione viene conservata da ElevenLabs. Di conseguenza, trascrizioni, registrazioni audio e risultati di analisi non sono disponibili nella Dashboard degli Agent, e questa policy vale sia per i sistemi rivolti ai clienti che per i log interni. Anche se i dati non vengono conservati, vengono comunque elaborati durante la chiamata, e qualsiasi webhook post-chiamata configurato riceverà gli output, permettendo ai clienti di archiviare trascrizioni o risultati di analisi nei propri sistemi se necessario.

Quando ZRM è attiva, ci assicuriamo anche che i subprocessor non conservino dati limitando gli LLM disponibili a provider con impegni contrattuali che vietano training o conservazione dei dati dei clienti; attualmente, questo include modelli di Google Gemini e Anthropic Claude. I clienti che desiderano usare un altro LLM con ZRM possono farlo firmando un accordo diretto con il provider e configurandolo come LLM personalizzato tramite API key coperte da quell’accordo. Poiché questo estende la gestione dei dati oltre il nostro perimetro di fiducia standard, il nostro team Safety deve esaminare e approvare manualmente il caso d’uso prima di abilitarlo. Anche se ZRM garantisce che ElevenLabs e i suoi subprocessor non conservino dati delle chiamate, resta responsabilità dei clienti assicurarsi che eventuali strumenti esterni o webhook usati dal proprio Agent siano conformi ai requisiti di conservazione e normativa applicabili.

Sguardo al futuro

In questo articolo abbiamo visto come gli Agent ElevenLabs gestiscono contesto conversazionale, strumenti, valutazione e workflow strutturati per offrire esperienze affidabili e in tempo reale su larga scala. Man mano che i clienti implementano agenti in ambienti sempre più complessi, continuiamo ad ampliare la flessibilità del nostro motore di orchestrazione, dai modelli di valutazione configurabili a controlli di transizione più ricchi, fino a una maggiore osservabilità sulla composizione dei prompt e l’uso dei token nelle varie fasi.

Il nostro team Forward Deployed Engineering lavora a stretto contatto con i clienti per garantire che queste funzionalità evolvano insieme alle implementazioni reali. La prossima generazione di Agent offrirà ancora più trasparenza, determinismo e adattabilità senza compromettere le prestazioni a bassa latenza che rendono possibile la conversazione in tempo reale.