Jak działa silnik orkiestracji ElevenAgent

ElevenAgents napędza silnik orkiestracji o niskich opóźnieniach, stworzony specjalnie do rozmów w czasie rzeczywistym i dodający mniej niż 100 ms opóźnienia. Ta architektura łączy nasze badania z najnowszymi LLM-ami od liderów takich jak OpenAI, Google czy Anthropic oraz wybrane modele open-source hostowane przez ElevenLabs. Dzięki użyciu kilku modeli na różnych etapach generowania odpowiedzi agent zapewnia szybkie i trafne rozmowy z zachowaniem kontekstu. Dynamicznie wykorzystując mocne strony każdego modelu, osiągamy niezawodność i skalowalność w różnych zadaniach i scenariuszach, optymalizując równowagę między inteligencją, szybkością i kosztami.

W tym artykule wyjaśniamy, jak te modele współpracują, by zapewnić agentom kluczowe możliwości działania w złożonych środowiskach – i które modele widzą jakie tokeny oraz kiedy. Kluczowe jest tu zarządzanie historią rozmowy na różnych etapach interakcji. Pokażemy, jak i gdzie historia rozmowy jest udostępniana, by wyjaśnić jej rolę w orkiestracji – zarówno w workflow niezależnych agentów, jak i w pracy wielu agentów.

Niezależny agent

Zaczynamy od omówienia niezależnego agenta i jego podstawowych elementów. Taki agent ma systemowy prompt, dostęp do kilku narzędzi i bazy wiedzy. Warto wybrać niezależnych agentów zamiast workflow, gdy nie trzeba pilnować ścisłej kolejności kroków lub gdy ważne jest unikanie silosów wiedzy między agentami. Silosy powstają, gdy niektóre narzędzia, dokumenty lub kontekst historyczny są dostępne tylko dla części subagentów. To naturalne w workflow z wieloma agentami i oznacza kompromis między elastycznością a przewidywalnością.

W przypadku niezależnych agentów w ElevenLabs ważne jest, by rozumieć, jak:

• Tworzą skuteczne zapytania do generowania odpowiedzi
• Wyszukują i wykorzystują odpowiednie dokumenty
• Generują i wykonują wywołania narzędzi, by wzbogacić odpowiedzi
• Zwracają wyniki do oceny i analizy

Budowanie kontekstu rozmowy 

Rozmowa klienta z agentem ElevenLabs to seria tur, gdzie każda tura to wymiana wiadomości między obiema stronami. Ta naprzemienna lista wiadomości agenta i użytkownika jest punktem wyjścia do budowania kontekstu rozmowy. W każdej turze LLM dostaje zapytanie z serią naprzemiennych wiadomości agenta i użytkownika – o jedną dłuższą niż w poprzedniej turze. Na początku tej serii zawsze jest systemowa wiadomość, czyli prompt agenta.

Orkiestrator ElevenLabs skraca odczuwalne opóźnienie LLM, przewidując, kiedy użytkownik skończy mówić. Czasem skutkuje to kilkoma zapytaniami do LLM z tym samym kontekstem w jednej turze. Orkiestracja przyspiesza odpowiedzi agentów, ale jakość odpowiedzi zależy też od sposobu dostępu do wiedzy. W miarę rozwoju klienci zwykle zaczynają opierać odpowiedzi agentów na własnych dokumentach i treściach publicznych. Od lat standardem jest tu retrieval-augmented generation (RAG). Bazy wiedzy ElevenAgents rozwijają RAG, korzystając z zoptymalizowanej, wielomodelowej architektury, którą opisaliśmy w poprzednim wpisie. Dzięki temu agent skutecznie znajduje dokumenty nawet wtedy, gdy ostatnia wypowiedź użytkownika to np. dopytanie, potwierdzenie lub nie zawiera wyraźnego pytania.

Wyszukiwanie to jednak tylko jeden ze sposobów, w jaki agenci korzystają z zewnętrznych systemów.

Wykonywanie akcji i pobieranie informacji przez narzędzia

Agenci ElevenLabs mogą wykonywać rzeczywiste akcje i pobierać aktualne dane w trakcie rozmowy dzięki elastycznemu systemowi narzędzi. Każde włączone narzędzie powiększa prompt, bo jego nazwa, opis i schemat parametrów są dołączane do systemowego promptu i historii rozmowy. Im więcej narzędzi, tym większe wyzwanie dla modelu, by wybrać właściwą sekwencję. W Agent Builder opis narzędzia wyjaśnia, do czego służy i jakie pola zwraca. To na tej podstawie model rozumie kontekst użycia. Warunki wywołania narzędzia powinny być już w systemowym promptcie agenta. Przykład:

• Opis narzędzia dla lookup_order: „Pobiera szczegóły zamówienia klienta na podstawie ID. Zwraca status zamówienia, kupione produkty, adres wysyłki i numer śledzenia.”
• Instrukcja w systemowym promptcie: „Po potwierdzeniu tożsamości klienta wywołaj narzędzie lookup_order, by pobrać szczegóły zamówienia.”

Takie rozdzielenie pozwala używać tych samych definicji narzędzi w różnych agentach, a systemowy prompt każdego agenta decyduje, kiedy je wywołać. Więcej wskazówek znajdziesz w naszym Przewodniku po promptowaniu. W tym systemie można zdefiniować różne typy narzędzi, m.in.:

• Webhooki wywołujące zewnętrzne API.
• Narzędzia klienckie, które wysyłają żądania jako zdarzenia przez websocket rozmowy.
• Narzędzia systemowe do wbudowanych akcji, np. przekierowania połączenia.
• Narzędzia MCP łączące się z serwerami Model Context Protocol.

Gdy agent zdecyduje się użyć narzędzia, pobiera potrzebne dane z rozmowy i wysyła żądanie. Po otrzymaniu wyniku dodaje go do rozmowy, by model mógł się do niego odnieść w kolejnej odpowiedzi. Jeśli trzeba, wynik narzędzia może też zaktualizować zapisane dane agenta jako zmienną dynamiczną. Te dane są przechowywane jako proste pary klucz-wartość, wyciągane z odpowiedzi narzędzia według ustalonych mapowań. Po ustawieniu zmienne mogą być użyte w systemowym promptcie, parametrach narzędzi i warunkach workflow. Dzięki temu agent zyskuje coś w rodzaju pamięci roboczej, która zmienia się w trakcie rozmowy.

To opisuje, jak narzędzia są włączane w rozumowanie agenta, ale można też ustawić, kiedy mają być uruchamiane. Narzędzia mogą działać w jednym z trzech trybów, zależnie od potrzeb rozmowy. W trybie natychmiastowym narzędzie uruchamia się od razu po żądaniu LLM – to domyślne dla szybkich zapytań, np. sprawdzenia statusu zamówienia. Jeśli agent najpierw wygeneruje krótkie potwierdzenie typu „Już sprawdzam”, użytkownik je usłyszy, a narzędzie działa równolegle, więc nie ma ciszy. Przy wolniejszych narzędziach platforma automatycznie wydłuża takie komunikaty, by wypełnić czas oczekiwania. Tryb po wypowiedzi opóźnia uruchomienie narzędzia do końca wypowiedzi agenta – to ważne przy akcjach mających skutki w świecie rzeczywistym, np. przekierowanie rozmowy, zakończenie sesji czy płatność. Użytkownik słyszy wtedy np. „Przekieruję cię teraz do działu rozliczeń” i może przerwać przed wykonaniem akcji. Tryb asynchroniczny uruchamia narzędzie całkowicie w tle, bez zatrzymywania rozmowy – to dobre np. do wysyłania maili, uruchamiania workflow czy logowania danych, gdy agent nie musi odnosić się do wyniku.

Gdy już mamy wykonanie i orkiestrację, czas na mierzenie skuteczności.

Mierzenie skuteczności

Po zakończonej rozmowie z agentem klient może chcieć wyciągnąć z niej konkretne dane do analizy lub sprawdzić, czy rozmowa była udana. Tu wchodzą w grę Zbieranie danych i Kryteria oceny. Zbieranie danych pozwala wyciągnąć uporządkowane informacje z transkrypcji rozmowy do dalszej analizy. Klienci często eksportują te dane do własnych hurtowni na potrzeby raportów lub workflow. Przykładowo agent sprzedażowy może automatycznie wyciągnąć dane potencjalnego klienta i utworzyć lub zaktualizować lead w CRM. Z kolei kryteria oceny określają, czy rozmowa była udana. Jeśli wszystkie kryteria są spełnione, rozmowa jest oznaczona jako udana; w przeciwnym razie jako nieudana. Dzięki temu rozmowy zawsze spełniają ustalone standardy jakości i spójności, a feedback jest szybki. Po zakończeniu rozmowy i wywołaniu webhooka agent przetwarza finalną transkrypcję (wraz z wykonaniami narzędzi i metadanymi) przez LLM razem ze wszystkimi punktami zbierania danych i kryteriami oceny. Model na tej podstawie sprawdza, czy każde kryterium jest spełnione i wyciąga wskazane dane do dalszej analizy. Ponieważ LLM interpretuje te ustawienia bezpośrednio z promptu, ważne jest, by były jasne i spójne – wtedy model dobrze je zrozumie i zastosuje. Dlatego polecamy te praktyki przy pisaniu kryteriów oceny i opisów zbierania danych.

Kryteria oceny

1. Jedno jasne zadanie na kryterium: jedno zdanie lub krótki punkt jest lepszy niż kilka celów w jednym kryterium.
2. Możliwe do sprawdzenia w transkrypcji: sformułuj cel tak, by dało się go ocenić na podstawie transkrypcji (co zostało powiedziane, co zrobił agent, o co pytał użytkownik). Unikaj celów wymagających zewnętrznego kontekstu, którego LLM nie ma.
3. Jasne wyniki: sukces/porażka/nieznane: LLM wie, że jeśli cel jest spełniony – oznacza sukces, jeśli nie – porażkę, a jeśli nie da się ocenić – nieznane. Cel powinien być więc napisany tak, by „spełnione” i „niespełnione” były jednoznaczne; jeśli jest niejasny, model może częściej wybierać „nieznane” lub błędnie klasyfikować.
4. Bądź zwięzły: czasem wysyłanych jest wiele kryteriów naraz. Długie kryteria mogą wprowadzać szum i powodować halucynacje.
5. Język ma znaczenie: każda uzasadnienie LLM, czy kryterium zostało spełnione, będzie w tym samym języku, co opis kryterium – warto o tym pamiętać.

Zbieranie danych

1. Opisz dokładnie, co wyciągnąć: opis to główny sygnał dla LLM. Wyjaśnij, co oznacza pole, kiedy je ustawić i co zrobić, gdy nie wiadomo (np. „Zostaw puste, jeśli klient nie podał preferowanej daty”).
2. Dopasuj typ danych: wartość zwracana przez LLM zawsze będzie zgodna z typem przypisanym do punktu zbierania danych (np. boolean, string, integer). Opis powinien to odzwierciedlać. Przykład: „Podaj liczbę zamówionych sztuk” dla integer, „Tak/nie, czy klient zgodził się na ofertę” dla boolean.
3. Używaj enum, jeśli się da: dla typu string, jeśli wartości są z góry ustalone, użyj enum w schemacie – to ogranicza model i zmniejsza liczbę błędnych odpowiedzi.
4. Jedno pole na jeden cel: Nie łącz kilku niezwiązanych faktów w jednym opisie; rozbij na osobne pola, by każde miało jeden, jasny cel.
5. Opis krótki: Opis może mieć kilka zdań – nie musi być długi. Transkrypcja i tak jest w wiadomości użytkownika, więc schemat + krótki opis wystarczy.

Obecnie do oceny i ekstrakcji używamy modelu o niskim opóźnieniu, by zapewnić szybkie działanie. Wkrótce planujemy dodać opcje, które dadzą klientom większą elastyczność.

Teraz przechodzimy do przypadków, gdzie potrzebna jest uporządkowana orkiestracja, przewidywalność lub specjalizacja ról – tu sprawdzą się Workflows.

Workflows

Workflows to wizualny interfejs do projektowania złożonych ścieżek rozmów. Tworzy logiczny obiekt, którym orkiestrator zarządza wieloma subagentami, narzędziami i przekierowaniami pod jednym identyfikatorem agenta. Workflows wprowadzają dodatkowe elementy, o których trzeba pamiętać poza tymi z niezależnych agentów, m.in. jak:

• Systemowe prompty i cele rozmów subagentów współdziałają.
• Przechodzenie przez różne punkty przejścia w grafie jest ustalane.

Specjalistyczne cele rozmów

Workflows korzystają z funkcji niezależnych agentów, by wymuszać spójne zachowanie w całej interakcji. Obejmuje to wspólne elementy, takie jak bazowy systemowy prompt, główne narzędzia i globalne bazy wiedzy, które powinny być zawsze dostępne, niezależnie od aktywnej części workflow. Główny prompt zwykle definiuje globalny kontekst rozmowy, oczekiwany ton, zabezpieczenia i wszelkie instrukcje dotyczące marki czy produktu.

Na tej bazie Workflows wprowadzają wyspecjalizowane subagenty działające w grafie skierowanym. Każdy subagent ma wąsko określony cel i rozszerza bazową konfigurację o dodatkowe instrukcje, narzędzia i źródła wiedzy potrzebne tylko w swojej roli. Zamiast definiować całą rozmowę od nowa, subagenty nakładają swój cel na bazowego agenta przez kompozycję promptu i selektywne rozszerzanie kontekstu. Historia rozmowy jest zachowana przy przejściach między subagentami, by utrzymać ciągłość, ale każdy subagent działa z celowo ograniczonym widokiem systemu. Bazy wiedzy i narzędzia są udostępniane wybiórczo, tworząc wyraźne silosy i zapobiegając mieszaniu się odpowiedzialności. By to wzmocnić, obiekt orkiestratora jest przebudowywany przy każdym przejściu, jakby to był niezależny agent. Dzięki temu prompt, konfiguracja i możliwości aktywnego subagenta są w pełni przewidywalne. Takie podejście pozwala Workflows zachować globalną spójność przy jednoczesnej lokalnej specjalizacji – daje przewidywalność, jasny podział ról i precyzyjną kontrolę nad kontekstem, wiedzą i akcjami na każdym etapie rozmowy.

Jednym z kluczowych mechanizmów tej kontroli są warunki przejść między subagentami.

Sterowanie przejściami workflow przez warunki LLM

Workflows przechodzą przez graf skierowany subagentów, gdzie przejścia między węzłami są kontrolowane przez jawne warunki. Warunki te decydują, kiedy kontrola przechodzi z jednego subagenta do drugiego i pozwalają reagować na dane od użytkownika, wyniki narzędzi i zmienne dynamiczne. Warunki w grafie mogą być deterministyczne lub oceniane przez LLM. Deterministyczne, np. przejścia bezwarunkowe, sprawdzenie wartości zmiennej czy wyniku narzędzia, dają silne gwarancje co do przebiegu workflow i są dobre do wymuszania ścisłej kolejności. Warunki LLM pozwalają natomiast na semantyczną ocenę kryteriów w języku naturalnym, np. wykrycie intencji użytkownika czy sprawdzenie, czy podano konkretne informacje.

Co ważne, warunki LLM są oceniane poza systemowym promptem aktywnego agenta i nie wpływają na generowanie odpowiedzi. Są oceniane równolegle przez orkiestrator na podstawie bieżącego stanu rozmowy. Dzięki temu logika przejść nie miesza się z promptem agenta ani nie wpływa na odpowiedzi, a jednocześnie workflow może korzystać z rozumowania LLM do elastycznego przechodzenia przez graf. Łącząc warunki deterministyczne i oceniane przez LLM, workflowy mogą być jednocześnie przewidywalne i elastyczne – deterministyczne tam, gdzie liczy się poprawność, i LLM tam, gdzie potrzebna jest interpretacja semantyczna.

Gdy rozmowa przechodzi do nowego etapu, system aktywuje wersję agenta dostosowaną do tego kroku. Każdy etap działa według własnych instrukcji i ma dostęp tylko do wiedzy i narzędzi potrzebnych do swojej roli. Przykładowo etap obsługi zwrotów może korzystać z polityki zwrotów bez dziedziczenia kontekstu z onboardingu czy triage. Przejścia między etapami są sterowane przez jawne warunki, które decydują, kiedy zmienić odpowiedzialność i pozwalają na naturalne kierowanie rozmową. Dla użytkownika przejścia są płynne – każdy etap dziedziczy odpowiedni kontekst rozmowy, ale nie ujawnia mechaniki przekazania. Dodatkowo zabezpieczenia monitorują przejścia, by uniknąć nieproduktywnych cykli i zapewnić, że workflow jest stabilny i zmierza do celu.

Zabezpieczenia i bezpieczeństwo

W przypadkach wymagających większych zabezpieczeń klienci mogą korzystać z dodatkowych funkcji orkiestratora.

Guardrails

Agenci ElevenLabs wdrażają zabezpieczenia przez konfigurowalny system moderacji i alignowania, który ocenia wiadomości użytkownika i agenta w czasie rzeczywistym. Treści są klasyfikowane w kilku kategoriach ryzyka, m.in. treści seksualne, przemoc, nękanie, hejt i samookaleczenia – każda z osobnym progiem. Po wykryciu naruszenia rozmowa jest natychmiast przerywana, a klient dostaje jasny powód. Dzięki temu niebezpieczne interakcje są blokowane od razu, bez polegania tylko na promptach. Guardrails działają poza logiką promptu agenta, tworząc warstwę egzekwującą, której nie da się obejść przez model czy użytkownika. Pozwala to klientom dostosować czułość zabezpieczeń do swojej branży i jednocześnie zachować przewidywalność działania.

Zgodne zarządzanie danymi

Czasem rozmówcy mogą przekazać agentowi wrażliwe dane, które podlegają ścisłym wymogom przechowywania i przetwarzania, np. dane medyczne wymagające zgodności z HIPAA. Dla takich przypadków oferujemy tryb Zero Retention Mode (ZRM) na poziomie agenta lub workspace. Po włączeniu wszystkie dane rozmowy są przetwarzane tylko w pamięci i nigdy nie są zapisywane na stałe. Po zakończeniu rozmowy i przetwarzania żadne dane nie są przechowywane przez ElevenLabs. Transkrypcje, nagrania audio i wyniki analizy nie są dostępne w panelu agentów, a zasada ta dotyczy zarówno systemów klienta, jak i naszych logów wewnętrznych. Dane są przetwarzane podczas rozmowy, a skonfigurowane webhooki po rozmowie otrzymają wyniki – klient może więc zapisać transkrypcję lub analizę u siebie, jeśli chce.

Gdy ZRM jest aktywny, dbamy też, by podwykonawcy nie przechowywali danych – ograniczamy dostępne LLM do tych dostawców, którzy mają umowy zakazujące trenowania na danych klienta i ich przechowywania; obecnie to modele Google Gemini i Anthropic Claude. Klienci, którzy chcą użyć innego LLM w ZRM, mogą to zrobić po podpisaniu własnej umowy z dostawcą i skonfigurowaniu go jako własny LLM przez API z odpowiednim kluczem. Ponieważ wtedy dane wychodzą poza naszą standardową strefę zaufania, nasz zespół ds. bezpieczeństwa musi ręcznie sprawdzić i zatwierdzić taki przypadek. ZRM gwarantuje, że ElevenLabs i podwykonawcy nie przechowują danych rozmów, ale klient nadal odpowiada za to, by wszelkie zewnętrzne narzędzia czy webhooki używane przez agenta były zgodne z wymogami prawnymi i dotyczącymi przechowywania danych.

Co dalej

W tym artykule pokazaliśmy, jak agenci ElevenLabs zarządzają kontekstem rozmowy, narzędziami, oceną i workflow, by zapewnić niezawodne doświadczenia w czasie rzeczywistym na dużą skalę. Wraz z wdrażaniem agentów w coraz bardziej złożonych środowiskach stale rozwijamy nasz silnik orkiestracji – od konfigurowalnych modeli oceny i bogatszych warunków przejść po lepszy wgląd w budowę promptów i zużycie tokenów na każdym etapie.

Nasz zespół Forward Deployed Engineering ściśle współpracuje z klientami, by te możliwości rozwijały się razem z realnymi wdrożeniami. Kolejna generacja agentów zapewni jeszcze większą przejrzystość, przewidywalność i elastyczność bez utraty niskich opóźnień, które umożliwiają rozmowy w czasie rzeczywistym.