Multi‑agent AI w sprzedaży: architektura, która w końcu się scala

Jedna z najbardziej niedocenianych informacji w ekosystemie Salesforce w 2026 brzmi tak: Engagement Agent obsługuje już ponad 1 mln akcji miesięcznie (Salesforce). To pierwszy realny dowód, że generatywni agenci AI potrafią działać nie tylko w małych eksperymentach, ale w skali enterprise. Dla polskich firm oznacza to koniec fazy PoC i początek decyzji architektonicznych, które będą decydować o tym, czy AI faktycznie skróci cykle sprzedaży, czy wpadnie w limity Gmaila. W tym artykule wyjaśniam, jak Salesforce przeskalował MVP jednego agenta do wieloagentowej platformy i co praktycy w Polsce mogą z tego wyciągnąć na poziomie architektury, limitów i wdrożenia.

Dlaczego architektura jednego agenta nie działa w realnym CRM

W testach MVP wszystko działało poprawnie, dopóki wolumen nie przekroczył kilkudziesięciu tysięcy leadów. W produkcyjnych orgach pojawiły się jednak klasyczne problemy: jednowątkowe przypisywanie zadań blokowało priorytetowe follow-upy, ciężkie batchowe zadania monopolizowały limity LLM i providerów, a brak kolejki utrudniał kontrolę nad burstami. Efekt był przewidywalny: retry storm, opóźnienia, niewyjaśnione timeouts. Salesforce rozwiązał to, wprowadzając trwałą kolejkę, która oddziela przyjmowanie pracy od jej przetwarzania, oraz dispatcher, który aktywnie wybiera kolejność, priorytet i agenta.

Od strony technicznej zmienia to wszystko. Kolejka nadaje systemowi deterministyczny rytm: przyjmuje tyle, ile wpadnie, ale wykonuje zgodnie ze strategią pracy i limitami. Dispatcher pilnuje priorytetów, w tym P0 dla zadań czasoczułych i P3 dla wolniejszych sekwencji nurturingowych. Do tego dochodzą algorytmy fairness, jak Round‑Robin i Least‑Recently‑Used, które równoważą obciążenie. Constraint engine pilnuje limitów organizacji i per agenta przed każdym dispatchowaniem.

W praktyce oznacza to, że agent AI nie jest już procesem, który „pisze maile na żądanie”, tylko elementem dużego orkiestru. Admin i architekt muszą go traktować jak system rozproszony, którego działanie zależy od limitów providerów, platformy AI i własnych automatyzacji w CRM. Tego typu wzorzec coraz częściej powtarza się także w skomplikowanych wdrożeniach Agentforce, gdzie kolejki i orkiestracja stają się warstwą obowiązkową. Rynek szybko zmierza do modelu, w którym agenci nie są pojedynczymi botami, lecz systemem współpracujących workerów.

Limity, które realnie blokują AI, i dlaczego provider quotas są ważniejsze niż limity Salesforce

Największym zaskoczeniem w skalowaniu Engagement Agent okazały się nie limity Salesforce, lecz skrzynki mailowe użytkowników. Gmail z capem około 2000 wiadomości dziennie i O365 z limitem około 10 000 stały się twardymi granicami całej automatyzacji. Nawet jeśli model AI generował więcej treści, email provider po prostu blokował wysyłki. W dodatku pojedynczy agent nie był w stanie utrzymać stabilności LLM, bo batch powyżej 40 rekordów wywoływał throttling gatewaya. Efekt: system, który w teorii robił dużo, w praktyce kończył z throughputem około 15 tys. leadów miesięcznie.

Przełom przyszedł dopiero wtedy, gdy Salesforce zrezygnował z podejścia „jeden limit dla całej organizacji” na rzecz channel-aware quotas. To mechanizm, który dopasowuje tempo wysyłek do faktycznych możliwości Gmaila, O365 i innych kanałów. W połączeniu z persistent queue i dispatcherem udało się osiągnąć skalę ponad 1,08 mln wiadomości miesięcznie przy 20 agentach. W architekturze CRM to fundamentalna zmiana: AI nie liczy parametrów swoich modeli, ale odczytuje i szanuje limity infrastruktury komunikacyjnej.

Dla polskich firm to kluczowa lekcja. Skalowanie agentów AI blokuje najczęściej nie Salesforce, a infrastruktura komunikacyjna i brak warstwy orkiestracji. To dokładnie ten sam problem, który widzimy przy wdrożeniach Data 360 i dynamicznej segmentacji, gdzie wolumen i limity providerów wymuszają architektury kolejkowe – opisaliśmy to w analizie o GRL i precyzyjnych filtrach Data 360. Z punktu widzenia architekta CRM to kolejny dowód, że AI trzeba projektować z myśleniem o przepustowości, a nie tylko o logice biznesowej.

Reliability i observability: AI nie działa bez telemetrycznej jasności

Największym problemem MVP była nieprzewidywalność przy burstach. Jednoobsługowy agent blokował się na pojedynczym dużym batchu, co wywoływało timeouts i masowe retrysy. Backlog rósł, a inboundy, które powinny być obsłużone natychmiast, czekały razem z low‑priority nurtures. Po stronie operacyjnej wyglądało to jak chaos, bo system nie pokazywał, czy zadanie utknęło przez limit providera, throttling LLM, czy opóźnienie w samym procesie agenta.

Wersja enterprise wprowadziła dwie rzeczy: separation of concerns (intake vs processing) oraz pełną telemetrię opartą o Trino. Kolejka stała się buforem diagnostycznym, a dispatcher granicą, która jasno mówi, czy rekord jest waiting, running czy completed. Pipeline Trino pozwala korelować eventy z czterech backendowych systemów i analizować je w Cursorze bez potrzeby budowania skomplikowanych raportów. To pierwszy raz, kiedy widzimy agentów AI z tak klarownym modelem obserwowalności.

W polskich orgach to będzie konieczność, nie opcja. Wraz z automatyzacją procesów, które mają konsekwencje prawne i operacyjne, firmy muszą widzieć dokładnie, dlaczego AI podjęło konkretną decyzję i gdzie ewentualnie utknęło. Ten kierunek jest spójny z globalnymi trendami AI governance, o których pisaliśmy w analizie jak CIO zaczynają płacić za autonomię agentów. W skrócie: agent bez telemetrii jest ryzykiem, agent z telemetrią jest procesem enterprise.

Strategia adopcji: jak projektować multi-agentowe workflow w polskich orgach

Wdrożenie Engagement Agent w wersji enterprise to nie jest wdrożenie „kolejnego narzędzia”, tylko zmiana w podejściu do automatyzacji. Po pierwsze, trzeba przejść z myślenia „AI działa per rekord” na „AI działa per zadanie w kolejce”. To oznacza redesign flowów, batchy i sekwencji komunikacyjnych. Po drugie, kluczowe jest modelowanie priorytetów. Jeśli P0 inbound ma być natychmiastowy, to P2 nurtures nie mogą być obsługiwane przez te same limity.

Technicznie Quick Wins to: identyfikacja kanałów z wysoką przepustowością, uruchomienie channel-aware quotas, wdrożenie mechanizmu kolejkowania dla innych elementów orga (np. w procesach Service), oraz zdefiniowanie real-time SLAs dla agentów. Długoterminowo trzeba będzie wprowadzić pipeline telemetrii, bo architektura multi-agentowa bez obserwowalności prowadzi do chaosu. W tym kierunku zmierza cały rynek CRM i to właśnie takie projekty pokazują, jak będzie wyglądać praca architekta Salesforce w 2026.

Podsumowanie

Architektura Engagement Agent to pierwszy w Salesforce dowód, że agentic AI może działać w dużej skali, ale tylko pod warunkiem, że jest traktowane jak system rozproszony, a nie funkcja w UI. Multi-agentowość, kolejki, priorytety i channel-aware quotas będą w 2026 podstawowymi elementami architektury automatyzacji. Pytanie, które warto dziś zadać, brzmi: czy twój org jest przygotowany na agentów, którzy działają równolegle, korzystają z tych samych limitów i wymagają podobnej telemetrii jak duże systemy klasy enterprise?