Så fungerar ElevenAgents orkestreringsmotor

ElevenAgents drivs av en låglatens orkestreringsmotor som är byggd för samtal i realtid och lägger till mindre än 100 ms fördröjning. Arkitekturen kombinerar det bästa från ElevenLabs forskning med avancerade LLM:er från ledande leverantörer som OpenAI, Google och Anthropic, samt utvalda open source-modeller som hostas av ElevenLabs. Genom att använda flera modeller i olika steg av svarskedjan säkerställer agenten att samtalen blir både snabba och kontextmedvetna. Genom att dynamiskt utnyttja varje modells styrkor tillsammans uppnår vi pålitlig och skalbar prestanda för olika företagsuppgifter och samtalsscenarier, samtidigt som vi optimerar balansen mellan intelligens, hastighet och kostnad.

Här förklarar vi hur dessa modeller samverkar för att leverera de kärnfunktioner som agenter behöver för att fungera i komplexa miljöer – och mer specifikt, vilken modell som ser vilka tokens och när. Kärnan i detta är hanteringen av samtalshistorik vid olika punkter i interaktionen. Vi går igenom hur och var samtalshistoriken delas för att förtydliga dess roll i orkestreringen, både för självständiga och multi-agent arbetsflöden.

Självständig agent

Vi börjar med att titta på den självständiga agenten och dess kärnkomponenter. Det är rimligt att tänka sig att en minimalt värdefull agent har en systemprompt, tillgång till ett antal verktyg och en kunskapsbas. Självständiga agenter passar bäst när ditt användningsområde inte kräver att du följer en strikt sekvens av steg, eller när det är viktigt att undvika kunskapssilor mellan agenter. Kunskapssilor uppstår när vissa verktyg, dokument eller historik bara är tillgängliga för vissa underagenter. Detta är vanligt i multi-agent arbetsflöden och innebär en avvägning mellan flexibilitet och förutsägbarhet.

För självständiga agenter i ElevenLabs är det viktigt att förstå hur de:

• Bygger effektiva genereringsförfrågningar
• Hämtar och använder relevanta dokument
• Skapar och utför verktygsanrop för att informera agentens svar
• Levererar resultat för utvärdering och datainsamling

Bygga samtalskontext 

Ett samtal mellan en kund och en ElevenLabs-agent består av en serie turer där varje tur är ett utbyte av meddelanden mellan båda parter. Denna växlande lista av agent- och användarmeddelanden är utgångspunkten för att bygga samtalskontexten. Under varje tur får den underliggande LLM:en genereringsförfrågningar som innehåller en serie växlande agent- och användarmeddelanden, där varje tur är ett meddelande längre än den förra. Denna serie meddelanden inleds alltid med ett systemmeddelande som representerar agentens systemprompt.

ElevenLabs orkestrator minskar upplevd LLM-fördröjning genom att förutse när en användare har pratat klart. I vissa fall kan detta leda till flera LLM-genereringsförfrågningar med samma samtalskontext under en och samma tur. Orkestreringen optimerar hur snabbt agenter svarar, men svarskvaliteten beror minst lika mycket på hur kunskap hämtas. När kunderna kommer längre brukar de grunda agenternas svar i en kombination av egen dokumentation och publikt innehåll. I flera år har retrieval-augmented generation (RAG) varit standardmetoden för detta.ElevenAgents kunskapsbaser bygger vidare på RAG med en optimerad multimodell-arkitektur som vi beskrivit i ett tidigare inlägg. Det gör att dokument kan hämtas pålitligt även när det senaste användarinlägget är en följdfråga, ett bekräftande svar eller saknar en tydlig fråga.

Att hämta information är dock bara ett sätt för agenter att interagera med externa system.

Utföra åtgärder och hämta information med verktyg

ElevenLabs-agenter kan utföra verkliga åtgärder och hämta aktuell information mitt i ett samtal via ett flexibelt verktygssystem. Den möjligheten innebär en viktig designfråga: varje aktiverat verktyg ökar storleken på den serialiserade prompten, eftersom namn, beskrivning och parameterschema inkluderas tillsammans med systemprompt och samtalshistorik. Ju fler verktyg som läggs till, desto större blir modellens ansvar att välja rätt verktyg i rätt ordning. I Agent Builder beskriver verktygets beskrivning vad verktyget gör och vilka fält det returnerar. Det är denna information som språkmodellen använder för att förstå kontexten kring användningen. När det är definierat ska de specifika villkoren för att använda verktyget anges i agentens systemprompt. Till exempel:

• Verktygsbeskrivning för lookup_order: ”Hämtar en kunds orderdetaljer via order-ID. Returnerar orderstatus, köpta varor, leveransadress och spårningsnummer.”
• Instruktion i systemprompt: ”Efter att ha verifierat kundens identitet, använd verktyget lookup_order för att hämta orderdetaljer.”

Denna uppdelning gör att verktygsdefinitioner kan återanvändas mellan agenter, samtidigt som varje agents systemprompt styr exakt när ett verktyg ska användas. För att hjälpa kunder att utforma dessa systemprompter ger vi mer vägledning i vår Prompting Guide. Inom detta ramverk kan flera typer av verktyg definieras, främst:

• Webhook-verktyg som anropar externa API:er.
• Klientverktyg som skickar verktygsanrop som händelser via samtalswebsocket.
• Systemverktyg för inbyggda åtgärder som samtalsöverföringar.
• MCP-verktyg som kopplar till Model Context Protocol-servrar.

När en agent väljer att använda ett verktyg hämtar den nödvändig information från samtalet och skickar en begäran om att köra det. När verktyget returnerar ett resultat läggs det till i samtalet så att modellen kan hänvisa till det i nästa svar. Vid behov kan verktygets utdata också uppdatera agentens sparade information som en dynamisk variabel. Denna information sparas som enkla nyckel-värde-par, hämtade från verktygets svar med fördefinierade mappningar. När de är satta kan dessa variabler användas i agentens systemprompt, framtida verktygsparametrar och arbetsflödesvillkor. Denna återkoppling ger agenten ett slags arbetsminne som utvecklas under interaktionen.

Detta beskriver hur verktyg integreras i agentens resonemang, men även när de körs kan konfigureras. Verktyg kan köras i tre olika lägen, anpassade för olika samtalsbehov. I Omedelbart läge körs verktyget så fort LLM:en begär det. Detta är standard för snabba uppslag där användaren förväntar sig ett direkt svar, som att kolla orderstatus. Kombinerat med förhandsmeddelande genererar agenten först ett kort svar som ”Jag kollar det åt dig” och skickar det till användaren medan verktyget körs parallellt, vilket minimerar tystnad. För långsammare verktyg förlänger plattformen automatiskt dessa utfyllnadssvar för att matcha väntetiden. I Efter-verktyg-läge väntar agenten tills den pratat klart innan verktyget körs. Detta är viktigt för åtgärder med verkliga konsekvenser, som att överföra ett samtal, avsluta en session eller skicka en betalning. Användaren hör hela kontexten, till exempel ”Jag kopplar dig till fakturering nu”, och kan avbryta innan åtgärden utförs. I Asynkront läge körs verktyget helt i bakgrunden utan att pausa samtalet. Det passar bäst för åtgärder som inte kräver återkoppling, som att skicka e-post, trigga ett externt arbetsflöde eller logga data, där agenten inte behöver hänvisa till resultatet i sitt svar.

När exekvering och orkestrering är på plats är nästa steg att förstå hur man mäter prestanda.

Mäta prestanda

Efter ett samtal med en agent kan du vilja extrahera vissa delar av samtalet för vidare analys och lagring, eller för att avgöra om samtalet var lyckat. Här kommer Datainsamling och Utvärderingskriterier in i bilden. Datainsamling låter dig extrahera strukturerad information från en samtalstranskription för vidare analys och sammanställning. Kunder exporterar ofta dessa resultat till sitt företags datalager för rapportering eller vidare bearbetning. Till exempel kan en Sales Development Agent automatiskt extrahera prospektinformation från ett samtal för att skapa eller uppdatera ett lead i CRM-systemet. Utvärderingskriterier avgör om ett samtal anses lyckat. Om alla kriterier är uppfyllda markeras samtalet som lyckat, annars flaggas det som misslyckat. Det säkerställer att samtalen alltid håller uppsatta kvalitets- och integritetskrav och ger snabb återkoppling. När ett samtal avslutas och webhooken triggas bearbetar agenten den slutliga transkriptionen, inklusive verktygsanrop och metadata, genom en LLM tillsammans med alla konfigurerade datainsamlingspunkter och utvärderingskriterier. Modellen använder denna kombinerade prompt för att avgöra om varje kriterium är uppfyllt och för att extrahera angivna datapunkter för vidare analys. Eftersom LLM:en tolkar dessa konfigurationer direkt i sin prompt är det viktigt att de är tydligt och konsekvent formulerade så att modellen kan förstå och tillämpa dem korrekt. Vi rekommenderar därför följande bästa praxis för att skriva utvärderingskriterier och datainsamlingsbeskrivningar.

Utvärderingskriterier

1. Ett tydligt mål per kriterium: en mening eller en kort punkt är bättre än flera mål i ett kriterium.
2. Observerbart och baserat på transkriptionen: formulera målet så att det går att avgöra utifrån transkriptionen (vad som sades, vad agenten gjorde, vad användaren frågade). Undvik mål som kräver extern kontext som LLM:en inte har.
3. Tydliga utfall för lyckat/misslyckat/okänt: LLM:en vet redan att målet måste vara uppfyllt för att markeras som lyckat, inte uppfyllt för misslyckat och okänt om det inte går att avgöra från transkriptionen. Målet bör därför vara tydligt definierat så att ”uppfyllt” och ”inte uppfyllt” är klart; om det är otydligt kan modellen välja okänt eller felaktig klassificering.
4. Håll det kort: ibland skickas många utvärderingskriterier samtidigt. Långa kriterier kan skapa brus och leda till hallucinationer.
5. Språket spelar roll: all motivering från LLM:en om ett kriterium är uppfyllt eller inte ges på samma språk som kriteriebeskrivningen, så tänk på det.

Datainsamling

1. Beskriv exakt vad som ska extraheras: beskrivningen är den viktigaste signalen för LLM:en. Säg vad fältet betyder, när det ska sättas och vad som gäller om det är oklart (t.ex. ”Lämna tomt om kunden aldrig angav ett önskat datum”).
2. Matcha förväntad typ: värdet från LLM:en kommer alltid att matcha datatypen för insamlingspunkten (t.ex. boolean, string, integer osv). Beskrivningen bör därför stämma med det. Till exempel: ”Extrahera antal beställda varor” för integer, och ”Ja/nej om kunden accepterade erbjudandet” för boolean.
3. Använd enum där det går: för string-typ, om värdemängden är fast, använd enum i schemat; det begränsar modellen och minskar felaktiga svar.
4. Ett extraktionsmål per punkt: Packa inte in flera olika fakta i en beskrivning; dela upp i separata punkter så att varje samtal har ett tydligt extraktionsmål.
5. Håll beskrivningarna korta: Beskrivningar kan vara några meningar; det behövs inga långa stycken. Transkriptionen finns redan i användarmeddelandet, så schema + kort beskrivning räcker.

Just nu används en låglatensmodell för denna utvärdering och extraktion för att säkerställa snabb bearbetning. Inom kort planerar vi att erbjuda fler valmöjligheter för ökad flexibilitet.

Nästa steg är att titta på användningsområden som kräver strukturerad orkestrering, förutsägbarhet eller specialisering mellan flera samtalsroller – där kan du istället använda Workflows.

Workflows

Workflows ger ett visuellt gränssnitt för att designa komplexa samtalsflöden. Det resulterar i det logiska objekt som orkestratorn använder för att hantera flera underagenter, verktyg och överföringar under en självständig agentidentitet. Workflows innebär ytterligare komponenter utöver de som redan beskrivits för självständiga agenter, bland annat hur:

• Systemprompter och underagenters samtalsmål samverkar.
• Förflyttning genom olika övergångspunkter i grafen avgörs.

Specialiserade samtalsmål

Workflows återanvänder funktionalitet från självständiga agenter för att säkerställa ett konsekvent beteende genom hela interaktionen. Det inkluderar gemensamma delar som grundläggande systemprompt, kärnverktyg och globala kunskapsbaser som alltid ska vara tillgängliga, oavsett var i arbetsflödet man befinner sig. Den övergripande systemprompten ansvarar oftast för att definiera global samtalskontext, förväntad ton, säkerhetskrav och eventuella varumärkes- eller produktinstruktioner.

Ovanpå denna gemensamma grund introducerar Workflows specialiserade underagenter som verkar i en riktad graf. Varje underagent får ett smalt definierat mål och utökar grundkonfigurationen med ytterligare promptinstruktioner, verktyg och kunskapskällor som bara är relevanta för dess roll. Istället för att omdefiniera hela samtalsinställningen lägger underagenter till sin avsikt ovanpå basagenten via promptkomposition och selektiv kontextutökning. Samtalshistoriken bevaras mellan underagentövergångar för att hålla kontinuitet, men varje underagent arbetar med en avsiktligt begränsad vy av systemet. Kunskapsbaser och verktyg exponeras selektivt, vilket skapar tydliga silor och förhindrar läckage mellan ansvarsområden. För att förstärka denna isolering byggs orkestratorobjektet om vid varje övergång, som om det vore en självständig agent. Det säkerställer att den aktiva underagentens prompt, konfiguration och tillgängliga funktioner är helt förutsägbara. Denna design gör att Workflows kan bibehålla global konsekvens samtidigt som lokal specialisering stöds, vilket ger förutsägbart beteende, tydlig ansvarsfördelning och exakt kontroll över hur kontext, kunskap och åtgärder används i varje steg av interaktionen.

En av de viktigaste mekanismerna för denna kontroll är hur övergångar mellan underagenter styrs.

Styr arbetsflödesövergångar med LLM-villkor

Workflows går vidare genom att följa en riktad graf av underagenter, där övergångarna mellan noder styrs av tydliga villkor. Dessa villkor avgör när kontrollen ska flyttas från en underagent till en annan och gör att arbetsflöden kan reagera på användarinmatning, verktygsresultat och dynamiska variabler. Grafvillkor kan vara antingen deterministiska eller LLM-utvärderade. Deterministiska villkor, som ovillkorliga övergångar, uttrycksbaserade kontroller på dynamiska variabler eller verktygsresultat, ger starka garantier om kontrollflödet och passar bra för att säkerställa strikt progression genom ett arbetsflöde. LLM-baserade villkor möjliggör semantisk utvärdering av naturliga språk-kriterier, som att upptäcka användarens avsikt eller känna igen när viss information har lämnats.

Viktigt är att LLM-villkor utvärderas utanför den aktiva agentens systemprompt och påverkar inte agentens generering. Istället utvärderas de parallellt av orkestratorn mot det aktuella samtalstillståndet. Denna uppdelning säkerställer att övergångslogiken inte påverkar agentens prompt eller hur svar genereras, samtidigt som arbetsflöden kan använda LLM-resonemang för flexibel grafnavigering. Genom att kombinera deterministiska och LLM-utvärderade villkor kan arbetsflöden uppnå både förutsägbarhet och anpassningsförmåga – använd deterministiska övergångar där korrekthet är avgörande och LLM-baserade där semantisk tolkning krävs.

När ett samtal går vidare till ett nytt steg aktiveras en version av agenten som är anpassad för just det steget. Varje steg har egna instruktioner och tillgång bara till den kunskap och de verktyg som är relevanta för dess ansvar. Till exempel kan ett återbetalningssteg hänvisa till återbetalningspolicy utan att ärva irrelevant kontext från onboarding eller triage. Förflyttning mellan steg styrs av tydliga övergångsvillkor. Dessa avgör när ansvaret ska flyttas och gör att routingbeslut kan ske naturligt under samtalets gång. För att hålla kontinuitet är användarupplevelsen sömlös över övergångarna, där varje steg ärver relevant samtalskontext utan att visa överlämningsmekaniken. Skyddsmekanismer övervakar också övergångarna för att förhindra icke-produktiva loopar, så att arbetsflödet förblir stabilt och målinriktat.

Säkerhet och trygghet

För situationer som kräver högre säkerhetsnivå kan kunder använda ytterligare delar av orkestratorn.

Skyddsräcken

ElevenLabs Agents implementerar säkerhetsskydd genom ett konfigurerbart modererings- och alignmentsystem som utvärderar användar- och agentmeddelanden i realtid. Innehåll klassificeras i flera riskkategorier, som sexuellt innehåll, våld, trakasserier, hat och självskada, där varje kategori har egna tröskelvärden. När ett skyddsräcke utlöses avslutas samtalet direkt och klienten får ett tydligt felmeddelande. Det gör att osäkra interaktioner blockeras tidigt och konsekvent, utan att bara förlita sig på promptbaserade åtgärder. Skyddsräcken fungerar utanför agentens promptlogik och ger ett pålitligt skyddslager som inte kan kringgås av modellbeteende eller användarinmatning. Detta gör att kunder kan anpassa säkerhetsnivån efter sitt område och samtidigt behålla förutsägbar tillämpning i realtid.

Efterlevande datahantering

Ibland kan talare dela känslig information med en agent som omfattas av särskilda lagrings- och hanteringskrav, till exempel medicinska data som kräver HIPAA-anpassad hantering. För dessa fall erbjuder vi Zero Retention Mode (ZRM) på agent- eller arbetsytanivå. När det är aktiverat behandlas all samtalsdata endast i minnet och sparas aldrig permanent. När samtalet och bearbetningen är klar sparas ingen information av ElevenLabs. Det innebär att transkriptioner, ljudinspelningar och analysresultat inte finns tillgängliga i Agents Dashboard, och policyn gäller både kundsystem och interna loggar. Även om data inte sparas behandlas den under samtalet, och eventuella konfigurerade webhooks efter samtalet får utdata, så att kunder kan lagra transkriptioner eller analysresultat i sina egna system om det behövs.

När ZRM är aktivt ser vi också till att underleverantörer inte sparar data genom att begränsa tillgängliga LLM:er till leverantörer med avtal som förbjuder träning på eller lagring av kunddata; för närvarande gäller detta modeller från Google Gemini och Anthropic Claude. Kunder som vill använda en annan LLM med ZRM kan göra det genom att teckna eget avtal med leverantören och konfigurera den som en egen LLM med API-nycklar som täcks av avtalet. Eftersom detta innebär datahantering utanför vår vanliga säkerhetsgräns måste vårt säkerhetsteam manuellt granska och godkänna användningsfallet innan det aktiveras. Även om ZRM säkerställer att ElevenLabs och dess underleverantörer inte sparar samtalsdata är det kundens ansvar att se till att externa verktyg eller webhooks som används av agenten följer gällande lagar och regler för lagring.

Framåt

I det här inlägget har vi gått igenom hur ElevenLabs Agents hanterar samtalskontext, verktyg, utvärdering och strukturerade arbetsflöden för att leverera pålitliga upplevelser i realtid i stor skala. När kunder använder agenter i allt mer komplexa miljöer fortsätter vi att utveckla vår orkestreringsmotor – från konfigurerbara utvärderingsmodeller och bättre övergångskontroller till djupare insyn i promptkomposition och tokenanvändning i olika steg.

Vårt Forward Deployed Engineering-team samarbetar nära med kunder för att säkerställa att dessa funktioner utvecklas i takt med verkliga behov. Nästa generations agenter kommer att ge ännu större transparens, förutsägbarhet och flexibilitet – utan att kompromissa med den låga latens som möjliggör samtal i realtid.