Så fungerar ElevenAgents orkestreringsmotor

ElevenAgents drivs av en orkestreringsmotor med låg latens, byggd för konversationer i realtid, som lägger till mindre än 100 ms overhead. 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 modeller med öppen källkod som driftas av ElevenLabs. Genom att använda flera modeller i olika steg av svarskedjan säkerställer agenten att konversationer både är mycket responsiva och medvetna om sitt sammanhang. Genom att dynamiskt utnyttja varje modells styrkor tillsammans får vi tillförlitlig, skalbar prestanda för en rad företagsuppgifter och konversationsscenarier, samtidigt som vi optimerar balansen mellan intelligens, hastighet och kostnad.

I den här artikeln förklarar vi hur modellerna samverkar för att ge agenter de grundläggande funktioner de behöver för att fungera i komplexa miljöer, och mer specifikt vilken modell som ser vilka token och när. Kärnan i detta är hanteringen av konversationshistorik vid olika tidpunkter i interaktionen. Vi går igenom hur och var konversationshistoriken delas för att klargöra dess roll i orkestreringen för både fristående agenter och arbetsflöden med flera agenter.

Fristående agent 

Vi börjar med att utforska den fristående agenten och dess huvudkomponenter. En agent med grundläggande värde har rimligen en systemprompt, tillgång till ett antal verktyg och en kunskapsbas. Kunder bör välja fristående agenter framför arbetsflöden när användningsfallet i begränsad utsträckning kräver kontroll av en strikt sekvens av steg, eller när det är viktigt att undvika kunskapssilor mellan agenterna. Kunskapssilor uppstår när vissa verktyg, dokument eller historisk kontext är tillgängliga för vissa underagenter men inte för andra. De är en naturlig del av arbetsflöden med flera agenter och innebär en avvägning mellan flexibilitet och determinism. 

För fristående agenter i ElevenLabs är det viktigt att förstå hur de:

• Skapar effektiva genereringsförfrågningar
• Hämtar och använder relevanta dokument
• Genererar och kör verktygsanrop som ger underlag till agentsvar
• Levererar resultat för utvärdering och datainsamling

Bygga konversationskontext 

En konversation mellan en kund och en ElevenLabs-agent består av en serie turer, där varje tur utgörs av ett meddelandeutbyte mellan båda parter. Den här växlande listan med meddelanden från agenten och användaren är utgångspunkten när vi bygger konversationskontexten. Under varje tur får den underliggande LLM:en genereringsförfrågningar som innehåller en serie växlande meddelanden från agenten och användaren, med ett meddelande mer än i föregående tur. Serien av meddelanden inleds naturligtvis med ett enda systemmeddelande som representerar agentens systemprompt.

ElevenLabs orkestrerare minskar den upplevda LLM-latensen genom att förutse när en användare har slutat tala. I vissa fall kan det leda till flera LLM-genereringsförfrågningar med samma konversationskontext inom en och samma tur.  Även om orkestreringen optimerar hur snabbt agenter svarar, beror svarskvaliteten lika mycket på hur kunskap hämtas. När kunder kommer längre börjar de vanligtvis förankra sina agentsvar i en kombination av egen dokumentation och offentligt innehåll. I flera år har retrieval-augmented generation (RAG) varit standardmetoden för detta. Kunskapsbaser för ElevenAgents bygger vidare på RAG med en optimerad arkitektur med flera modeller, som vi har beskrivit i ett tidigare inlägg. Det gör det möjligt att hämta dokument på ett tillförlitligt sätt även när användarens senaste inmatning är en följdfråga, en bekräftelse av ett förtydligande eller på annat sätt saknar en uttrycklig fråga.

Hämtning ä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 en konversation via ett flexibelt verktygssystem. Den möjligheten innebär en viktig designaspekt: varje aktiverat verktyg ökar storleken på den serialiserade prompten, eftersom dess namn, beskrivning och parameterschema inkluderas tillsammans med systemprompten och konversationshistoriken. När fler verktyg läggs till ökar också den mängd resonemang modellen behöver göra för att anropa rätt sekvens av verktyg. I Agent Builder beskriver verktygets beskrivning vad verktyget gör och vilka fält det returnerar. Det är informationen språkmodellen använder för att förstå sammanhanget för dess användning. När verktyget har definierats ska de specifika villkoren för att anropa det finnas i agentens systemprompt. Till exempel:

• Verktygsbeskrivning för lookup_order: ”Hämtar en kunds orderuppgifter via order-ID. Returnerar orderstatus, köpta artiklar, leveransadress och spårningsnummer.”
• Instruktion i systemprompten: ”När du har verifierat kundens identitet anropar du verktyget lookup_order för att hämta orderuppgifterna.”

Den här ansvarsfördelningen gör verktygsdefinitioner återanvändbara mellan agenter, samtidigt som varje agents systemprompt kan styra exakt när ett verktyg anropas. För att hjälpa kunder att utforma dessa systemprompter effektivt ger vi mer vägledning i vår guide för promptning. I det här ramverket kan framför allt följande typer av verktyg definieras:

• Webhook-verktyg som anropar externa API:er.
• Klientverktyg som skickar verktygsförfrågningar som händelser via konversationens websocket.
• Systemverktyg för inbyggda åtgärder som samtalsöverföringar.
• MCP-verktyg som ansluter till Model Context Protocol-servrar.

När en agent beslutar sig för att använda ett verktyg hämtar den nödvändiga uppgifter från konversationen och skickar en förfrågan om att köra det. När verktyget returnerar ett resultat läggs resultatet till i konversationen så att modellen naturligt kan hänvisa till det i nästa svar. Vid behov kan verktygets utdata även uppdatera agentens lagrade information som en dynamisk variabel. Den lagrade informationen sparas som enkla nyckel/värde-par, extraherade från verktygets svar med fördefinierade mappningar. När de har angetts kan variablerna återkopplas till agenten via systemprompten, framtida verktygsparametrar och arbetsflödesvillkor. Den här återkopplingsslingan ger agenter ett slags arbetsminne som utvecklas medan de interagerar.

Även om detta beskriver hur verktyg integreras i agentens resonemang kan tidpunkten för körningen också konfigureras. Verktyg kan köras i ett av tre körlägen, vart och ett anpassat till olika konversationsbehov. I Immediate Mode körs verktyget så snart LLM:en begär det. Det är standard för snabba uppslag där användare förväntar sig ett nästan omedelbart svar, till exempel kontroll av orderstatus. I kombination med pre-tool speech genererar agenten först en kort bekräftelse, som ”Låt mig kontrollera det åt dig”, och skickar den till användaren medan verktyget körs parallellt, vilket minimerar tystnad. För långsammare verktyg förlänger plattformen automatiskt dessa utfyllnadsmeddelanden för att motsvara den förväntade väntetiden. Post-Tool Speech Mode fördröjer däremot körningen tills agenten har talat klart. Det är nödvändigt för åtgärder med verkliga konsekvenser, exempelvis att överföra ett samtal, avsluta en session eller skicka in en betalning. Användaren får höra hela sammanhanget, som ”Jag kopplar dig till faktureringen nu”, och har möjlighet att avbryta innan åtgärden utförs. Async Mode kör verktyget helt i bakgrunden utan att pausa konversationen. Läget passar bäst för fire-and-forget-åtgärder som att skicka ett e-postmeddelande, utlösa ett externt arbetsflöde eller logga data, där agenten inte behöver hänvisa till resultatet i sitt svar.

När körning och orkestrering är på plats är nästa steg att förstå hur prestandan mäts.

Mäta prestanda

När ett samtal med en agent har avslutats kan kunder vilja extrahera vissa delar av samtalet för vidare analys och lagring, eller avgöra om samtalet lyckades. Det är här Datainsamling och Utvärderingskriterier kommer in i bilden. Med Datainsamling kan du extrahera strukturerad information från ett samtalstranskript för senare analys och aggregering. Kunder exporterar ofta dessa resultat till sitt företags data lakehouse för rapportering eller arbetsflöden för dataanrikning. En Sales Development Agent kan till exempel automatiskt extrahera uppgifter om potentiella kunder från en konversation för att skapa eller uppdatera en lead i systemet för kundrelationshantering (CRM). Utvärderingskriterier avgör däremot om ett samtal anses ha lyckats. Om alla konfigurerade kriterier uppfylls markeras samtalet som lyckat, annars markeras det som misslyckat. Det säkerställer att konversationer konsekvent uppfyller definierade standarder för kvalitet och integritet, samtidigt som det ger snabb återkoppling. När ett samtal avslutas och webhooken efter samtalet utlöses bearbetar agenten det slutgiltiga transkriptet, inklusive verktygskörningar och metadata, med en LLM tillsammans med alla konfigurerade datainsamlingspunkter och utvärderingskriterier. Modellen använder denna sammansatta prompt för att avgöra om varje utvärderingskriterium är uppfyllt och för att extrahera angivna datapunkter för senare analys. Eftersom LLM:en tolkar dessa konfigurationer direkt som en del av sin inmatningsprompt är det viktigt att formatera dem tydligt och konsekvent så att modellen kan förstå och tillämpa dem korrekt. Därför rekommenderar vi följande bästa praxis för att skriva beskrivningar för Utvärderingskriterier och Datainsamling.

Utvärderingskriterier

1. Ett tydligt mål per kriterium: en mening eller en kort punkt är bättre än flera mål i ett och samma kriterium. 
2. Observerbart och transkriptbaserat: formulera målet så att framgång/misslyckande kan avgöras utifrån transkriptet (vad som sades, vad agenten gjorde, vad användaren frågade). Undvik mål som kräver extern kontext som LLM:en saknar.
3. Tydliga utfall för framgång/misslyckande/okänt: LLM:en har redan kontexten att målet måste uppfyllas för att markeras som lyckat, inte vara uppfyllt för att markeras som misslyckat och inte kunna avgöras från transkriptet för att markeras som okänt. Målet bör därför skrivas så att ”uppfyllt” respektive ”inte uppfyllt” är tydligt definierat. Är det tvetydigt kan modellen luta åt okända eller felaktiga klassificeringar.
4. Håll det kortfattat: ibland kan många utvärderingskriterier skickas tillsammans. Långa utvärderingskriterier kan därför skapa brus och potentiellt orsaka hallucinationer.
5. Språket spelar roll: LLM:ens motivering till huruvida ett utvärderingskriterium uppfylldes eller inte ges på samma språk som kriteriebeskrivningen, så det är viktigt att ha i åtanke.

Datainsamling

1. Beskriv exakt vad som ska extraheras: beskrivningen är den viktigaste signalen för LLM:en. Ange vad fältet betyder, i vilken situation det ska sättas och vad som ska göras när det är oklart (t.ex. ”Lämna null om kunden aldrig angav ett önskat datum”).
2. Matcha den förväntade typen: värdet från LLM:en kommer alltid att matcha datatypen som har tilldelats datainsamlingspunkten (t.ex. boolean, string, integer). Beskrivningen bör därför stämma överens med den. Du kan till exempel använda ”Extrahera antalet efterfrågade artiklar” för integer och ”Ja/nej om kunden godkände erbjudandet” för boolean.
3. Använd enums när det är möjligt: om uppsättningen värden är fast för typen string, använd enum i schemat. Det begränsar modellen och minskar ogiltiga utdata.
4. Ett extraheringsmål per objekt: lägg inte flera orelaterade fakta i ett objekts beskrivning. Dela upp dem i separata objekt så att varje anrop har ett enda tydligt extraheringsmål.
5. Håll beskrivningarna korta: beskrivningar kan bestå av några meningar, utan behov av långa stycken. Transkriptet finns redan i användarmeddelandet, så schemat plus en kort beskrivning räcker.

För närvarande är LLM:en som används för detta utvärderings- och extraheringssteg fast inställd på en modell med låg latens för att säkerställa snabb bearbetning. Inom en snar framtid förväntar vi oss att införa alternativ som ger kunder större flexibilitet. 

Härnäst tittar vi på användningsfall som kräver strukturerad orkestrering, determinism eller specialisering mellan flera konversationsroller, där kunder i stället kan använda Workflows.

Workflows

Workflows erbjuder ett visuellt gränssnitt för att utforma komplexa konversationsflöden. Det skapar i slutändan det logiska objekt som orkestreraren använder för att hantera flera underagenter, verktyg och överföringar under en fristående agentidentifierare. Workflows introducerar ytterligare komponenter att beakta utöver dem som redan beskrivits för fristående agenter, inklusive hur:

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

Specialiserade konversationsmål

Workflows återanvänder funktionalitet från fristående agenter för att upprätthålla ett beteende som är konsekvent genom hela interaktionen. Det omfattar gemensamma delar som bas-systemprompten, centrala verktyg och globala kunskapsbaser som alltid ska vara tillgängliga, oavsett vilken del av arbetsflödet som är aktiv. Den övergripande systemprompten ansvarar vanligtvis för att definiera global konversationskontext, förväntad ton, säkerhetsbegränsningar och varumärkes- eller produktövergripande instruktioner.

Ovanpå denna gemensamma grund introducerar Workflows specialiserade underagenter som arbetar i en riktad graf. Varje underagent tilldelas ett snävt avgränsat mål och utökar baskonfigurationen med ytterligare promptinstruktioner, verktyg och kunskapskällor som endast är relevanta för dess roll. I stället för att omdefiniera hela konversationsupplägget lägger underagenter sitt syfte ovanpå basagenten genom promptkomposition och selektiv utökning av kontexten. Konversationshistoriken bevaras vid övergångar mellan underagenter för att upprätthålla kontinuitet, men varje underagent arbetar med en medvetet begränsad vy av systemet. Kunskapsbaser och verktyg exponeras selektivt, vilket skapar tydliga silor som förhindrar läckage mellan ansvarsområden. För att förstärka denna isolering byggs orkestrerarobjektet om vid varje övergång, som om det vore en fristående agent. Det säkerställer att den aktiva underagentens promptstatus, konfiguration och tillgängliga funktioner förblir helt deterministiska. Designen gör att Workflows kan behålla global konsekvens samtidigt som den stödjer lokal specialisering, vilket ger förutsägbart beteende, tydlig ansvarsfördelning och exakt kontroll över hur kontext, kunskap och åtgärder tillämpas i varje steg av en interaktion.

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

Styra övergångar i arbetsflöden med LLM-villkor

Workflows går framåt genom en riktad graf av underagenter, där övergångarna mellan noder styrs av uttryckliga villkor. Dessa villkor avgör när kontrollen ska flyttas från en underagent till en annan och gör det möjligt för arbetsflöden att reagera på användarinmatning, verktygsresultat och dynamiska variabler. Grafvillkor kan vara antingen deterministiska eller LLM-utvärderade. Deterministiska villkor, som villkorslösa övergångar, kontroller baserade på uttryck för dynamiska variabler eller villkor för verktygsresultat, ger starka garantier för styrflödet och passar väl för att säkerställa strikt progression genom ett arbetsflöde. LLM-baserade villkor möjliggör däremot semantisk utvärdering av kriterier i naturligt språk, till exempel att upptäcka användarens avsikt eller känna igen när specifik information har lämnats.

Det är viktigt att LLM-villkor utvärderas utanför den aktiva agentens systemprompt och inte påverkar agentens genereringsbeteende. I stället utvärderas de parallellt av orkestreraren mot konversationens aktuella tillstånd. Den här uppdelningen säkerställer att övergångslogiken inte förorenar agentens prompt eller påverkar hur svar genereras, samtidigt som arbetsflöden kan använda LLM-resonemang för flexibel förflyttning i grafen. Genom att kombinera deterministiska och LLM-utvärderade villkor kan arbetsflöden uppnå både förutsägbarhet och anpassningsbarhet: deterministiska övergångar där korrekthet är avgörande och LLM-baserade övergångar där semantisk tolkning krävs.

När en konversation går vidare till ett nytt steg aktiverar systemet en version av agenten som är anpassad specifikt för det steget. Varje steg arbetar med egna fokuserade instruktioner och har endast tillgång till den kunskap och de verktyg som är relevanta för dess ansvar. Ett steg för återbetalningshantering kan till exempel hänvisa till återbetalningspolicyer utan att ärva orelaterad kontext från onboarding eller triage. Förflyttningen mellan steg styrs av uttryckliga övergångsvillkor. Dessa villkor avgör när ansvaret ska flyttas och gör att routningsbeslut kan fattas naturligt medan konversationen utvecklas. För att bibehålla kontinuiteten blir användarens upplevelse sömlös mellan övergångar, där varje steg ärver relevant konversationskontext utan att blotta mekaniken bakom överlämningen. Skyddsmekanismer övervakar också övergångar för att förhindra improduktiva routningscykler och säkerställer att arbetsflödet förblir stabilt och målinriktat.

Säkerhet och trygghet

För användningsfall som kräver utökade säkerhets- och trygghetskontroller kan kunder använda ytterligare delar av orkestreraren. 

Skyddsräcken

ElevenLabs Agents implementerar skyddsräcken för säkerhet genom ett konfigurerbart system för moderering och anpassning som utvärderar användar- och agentmeddelanden i realtid. Inkommande innehåll klassificeras i flera riskkategorier, bland annat sexuellt innehåll, våld, trakasserier, hat och självskada, var och en med individuellt konfigurerbara tröskelvärden. När ett skyddsräcke utlöses avslutas konversationen omedelbart och klienten meddelas med en tydlig orsak till misslyckandet. Det säkerställer att osäkra interaktioner blockeras tidigt och konsekvent, utan att enbart förlita sig på åtgärder i prompten. Skyddsräcken fungerar utanför agentens promptlogik och ger ett tillförlitligt lager för efterlevnad som inte kan kringgås av modellbeteende eller användarinmatning. Metoden låter kunder justera säkerhetskänsligheten utifrån sin domän, samtidigt som den behåller deterministisk tillämpning vid körning.

Kompatibel datahantering

Talare kan ibland dela känslig information med en agent som omfattas av strikta krav på lagring och behandling, till exempel medicinska data som kräver HIPAA-kompatibel hantering. För att stödja dessa användningsfall erbjuder vi Zero Retention Mode (ZRM) på Agent- eller Workspace-nivå. När det är aktiverat behandlas all samtalsdata endast i minnet och skrivs aldrig till beständig lagring. När samtalet och behandlingen är klara behåller ElevenLabs ingen information. Därför är transkript, ljudinspelningar och analysresultat inte tillgängliga i Agents Dashboard, och policyn gäller både kundnära system och interna loggar. Även om data inte behålls behandlas den under samtalet, och alla konfigurerade webhooks efter samtalet får resultaten. Kunder kan därmed lagra transkript eller analysresultat i sina egna system vid behov. 

När ZRM är aktivt säkerställer vi också att underleverantörer inte behåller data genom att begränsa tillgängliga LLM:er till leverantörer med avtalsmässiga åtaganden som förbjuder träning på eller lagring av kunddata. För närvarande omfattar 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 ett eget avtal med leverantören och konfigurera den som en anpassad LLM med API-nycklar som omfattas av avtalet. Eftersom detta utökar datahanteringen bortom vår vanliga förtroendegräns måste vårt Safety-team granska och godkänna användningsfallet manuellt innan det aktiveras. Även om ZRM säkerställer att ElevenLabs och dess underleverantörer inte behåller samtalsdata ansvarar kunderna fortfarande för att externa verktyg eller webhooks som används av deras Agent uppfyller tillämpliga krav på lagring och reglering.

Framåt

I det här inlägget har vi utforskat hur ElevenLabs Agents hanterar konversationskontext, verktyg, utvärdering och strukturerade arbetsflöden för att leverera tillförlitliga upplevelser i realtid i stor skala. När kunder driftsätter agenter i allt mer komplexa miljöer fortsätter vi att utöka flexibiliteten i vår orkestreringsmotor, från konfigurerbara utvärderingsmodeller och mer omfattande övergångskontroller till djupare insyn i promptkomposition och tokenanvändning mellan 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 driftsättningar. Nästa generation av Agents kommer att ge ännu större transparens, determinism och anpassningsbarhet utan att kompromissa med den låga latens som möjliggör konversationer i realtid.