Persistent queue w Agentforce – lekcja dla architektów

Limit 300 RPM dla współdzielonej infrastruktury LLM wystarcza, by zatrzymać nawet dobrze zaprojektowany proces, jeśli tysiące zadań wpadają do systemu jednocześnie. W praktyce to nie model staje się pierwszym problemem, tylko orkiestracja: kto ma dostać przepustowość, kiedy i według jakich reguł. W Agentforce rozwiązano to przez rozproszoną persistent queue, która zwiększyła bezpieczny throughput 5x bez łamania limitów infrastruktury (Engineering_Salesforce). Dla architektów, adminów i devów w Polsce to ważny sygnał: przy AI w Salesforce wąskim gardłem coraz częściej nie jest logika biznesowa, ale kontrola współdzielonej pojemności.

Persistent queue jako warstwa orkiestracji, a nie zwykła kolejka

Najważniejsza zmiana polega na tym, że outreach nie jest wykonywany natychmiast po zleceniu. Między workflow klienta a infrastrukturą pojawia się trwała kolejka, która decyduje, kiedy zadanie może wejść do wykonania bez ryzyka przeciążenia. To przesuwa odpowiedzialność z pojedynczego flow, agenta czy procesu sprzedażowego na wspólną warstwę sterowania ruchem.

Technicznie ta kolejka grupuje pracę według execution context. Dla agentów AI takim kontekstem może być bot user, a dla pracy człowieka – owner procesu. Dispatcher przechodzi przez te grupy metodą round-robin i w każdej iteracji pobiera po jednym zadaniu z danego kontekstu, aż zapełni dostępną pojemność dispatchu. Taki model nie pozwala, by jeden agent lub jeden zespół sprzedaży zużył cały budżet wywołań LLM kosztem pozostałych.

To istotna lekcja także poza samym Agentforce. W wielu orgach Salesforce automatyzacja nadal jest projektowana lokalnie – osobny Flow, osobny Apex, osobna integracja, osobny scheduler. Przy klasycznych limitach platformy to bywa wystarczające. Przy AI już nie zawsze. Jeśli kilka ścieżek wykonania współdzieli ten sam limit zewnętrzny, potrzebna jest centralna polityka admission control, a nie tylko retry i monitoring błędów. Podobny kierunek widać też w rosnącej roli Flow Orchestration jako warstwy koordynacji procesów, gdzie sama sekwencja działań przestaje być dodatkiem, a staje się elementem architektury.

Dla praktyka oznacza to trzy konkretne działania. Po pierwsze, warto mapować wszystkie procesy, które konsumują wspólne limity AI lub integracyjne. Po drugie, trzeba oddzielić moment utworzenia zadania od momentu jego wykonania – szczególnie gdy w grę wchodzą LLM, providerzy e-mail i ograniczenia godzin pracy. Po trzecie, fairness powinno być zaprojektowane jawnie: per user, per owner, per kanał albo per typ procesu. Bez tego najbardziej agresywny workload zawsze wygra.

Priorytety i backfill: jak nie zgubić najcenniejszych interakcji

Nie każde zadanie ma tę samą wartość biznesową. Odpowiedź do zaangażowanego leada jest ważniejsza niż wiadomość typu intro czy nudge. Jeśli system traktuje wszystko jednakowo, niższy priorytet może zająć sloty i opóźnić najbardziej wartościowe interakcje. W środowisku sprzedażowym to nie jest detal wydajnościowy, tylko bezpośredni wpływ na pipeline.

Dlatego zastosowano trzy poziomy priorytetu: reply, intro i nudge. Sama hierarchia nie wystarcza jednak, jeśli prowadzi do marnowania pojemności. Rozwiązaniem jest dynamiczna alokacja slotów z mechanizmem adaptive backfill. System odpytuje każdy poziom priorytetu tylko raz. Jeśli najwyższa warstwa nie wypełni całej dostępnej pojemności, brakujące sloty są uzupełniane wcześniej pobranymi wynikami z niższych poziomów. Efekt jest podwójny: reply idą pierwsze, ale przepustowość pozostaje w pełni wykorzystana.

To ważny wzorzec dla zespołów budujących AI workflows w Salesforce. Priorytet nie powinien oznaczać prostego if/else ani sztywnej kolejności bez kontroli wykorzystania zasobów. Lepiej myśleć o nim jak o polityce dispatchu: najpierw ochrona najcenniejszych zdarzeń, potem maksymalizacja użycia dostępnych slotów. Tę samą logikę można odnieść do innych scenariuszy – od obsługi incydentów po routing zadań agentowych. W kontekście bardziej złożonych topologii agentów dobrze łączy się to z podejściem opisanym przy architekturze agent-to-agent w Salesforce, gdzie bez jawnych guardrails szybko pojawia się konkurencja o wspólne zasoby.

Praktyczny wniosek jest prosty: przed wdrożeniem AI trzeba ustalić, które interakcje są krytyczne czasowo i biznesowo. Następnie należy przypisać im osobne klasy priorytetu oraz zdefiniować zasady backfill, by niższe klasy nie blokowały systemu, ale też nie pozostawały w nieskończonym oczekiwaniu. Bez takiej polityki organizacja zwykle widzi tylko średni throughput, nie zauważając, że najważniejsze zadania kończą z najgorszym SLA.

Jak uniknąć starvation i kaskady retry przy human review oraz LLM limits

Najtrudniejszy problem pojawia się wtedy, gdy w jednym systemie współistnieją ścieżki autonomiczne i human-in-the-loop. Część organizacji wymaga zatwierdzenia wiadomości przed wysyłką. Wtedy e-mail wygenerowany przez AI nie może od razu trafić do dispatchu, tylko czeka na akceptację. Jeśli taki proces nie jest odseparowany od pracy autonomicznej, bardzo łatwo o starvation – jedna ścieżka zaczyna blokować drugą.

Rozwiązaniem jest architektura dual-path. Ścieżka autonomiczna przechodzi standardowo przez generowanie i wysyłkę, ale tylko po sprawdzeniu ograniczeń pojemności, dziennych limitów e-mail oraz godzin operacyjnych. Ścieżka z review działa inaczej: wiadomość jest draftowana wcześniej i przechowywana w stanie queued. Po akceptacji człowieka system pobiera zatwierdzone e-maile osobno i planuje ich dostarczenie bez ponownego kroku generacji. To kluczowe, bo zatwierdzone wiadomości nie zużywają już bieżącej pojemności LLM.

Przed zaplanowaniem wysyłki sprawdzana jest jeszcze pojemność właściciela: limity dzienne i operating hours. Jeśli owner nie ma wolnego capacity, zadanie jest odkładane do kolejnego cyklu dispatchu. Dzięki temu review-required i full-autonomous mogą współdzielić infrastrukturę bez wzajemnego blokowania.

Drugi ważny element to odejście od push-based retry jako głównego mechanizmu odporności. Wcześniejsze podejście retry po błędzie rate limit prowadziło do kaskad: zaległe zadania konkurowały z nowymi, a system coraz trudniej wracał do stabilnego stanu. Zamiast tego zastosowano adaptive rate modulation z proactive capacity-based admission control. Przed dispatchingiem sprawdzane jest bieżące zużycie organizacji, a wolumen zadań jest odpowiednio zmniejszany, gdy system zbliża się do limitu.

Dla polskich zespołów to cenna wskazówka przy projektowaniu integracji z modelami i usługami o twardych limitach. Retry nadal ma sens, ale nie jako podstawowy mechanizm sterowania ruchem. Najpierw trzeba kontrolować wejście do systemu, potem dopiero obsługiwać wyjątki. W praktyce oznacza to potrzebę telemetrii czasu rzeczywistego, polityk odraczania i wyraźnego rozdzielenia etapów draft, approval i send. Przy rosnącej liczbie agentów i automatyzacji warto też równolegle myśleć o governance, bo bez tego szybko pojawia się agent sprawl i niekontrolowana konkurencja o zasoby.

Zakończenie

Persistent queue w Agentforce pokazuje, że skala AI w Salesforce zależy dziś bardziej od jakości orkiestracji niż od samego modelu. Fair-share, priorytety, dual-path execution i proactive admission control tworzą razem wzorzec, który można przenieść do wielu procesów opartych na LLM. Jeśli w twoim orgu AI ma działać stabilnie pod realnymi limitami, pytanie nie brzmi już tylko „co zautomatyzować”, ale „kto i na jakich zasadach dostaje przepustowość”. Czy twoja architektura ma już taką warstwę sterowania, czy nadal liczy na to, że retry rozwiąże problem skali?