Multi-agent AI w danych: lekcja dla praktyka Salesforce

Procesy zarządzania danymi, które wcześniej trwały nawet trzy miesiące, można skrócić do dni dzięki architekturze multi-agent AI (Salesforce Engineering). Dla zespołów Salesforce to ważny sygnał, bo największa wartość agentów nie leży w pojedynczym czacie z LLM, ale w przejęciu złożonych, wieloetapowych workflow obejmujących dane, jakość i integracje. To także praktyczna lekcja, gdzie kończy się skuteczność jednego agenta, a zaczyna potrzeba orkiestracji, walidacji i kontroli wykonania. Jeśli w orgu AI ma działać na procesach krytycznych, sam model nie wystarczy – potrzebna jest architektura.

Dlaczego jeden agent nie wystarcza przy złożonych workflow danych

Największy problem w procesach danych nie wynikał z pojedynczej czynności, ale z ich rozproszenia. Odkrywanie danych, governance, jakość i orkiestracja przepływów działały w różnych narzędziach i wymagały specjalistycznej wiedzy. Taki układ powodował utratę kontekstu między etapami, opóźnienia i wysoką zależność od ekspertów, którzy potrafią spiąć całość ręcznie.

W tym modelu podejście single-agent okazało się niewystarczające. Jeden agent miał zbyt szeroki kontekst do utrzymania, musiał korzystać z wielu narzędzi i przechodzić przez etapy wymagające odmiennych sposobów rozumowania. To ważna obserwacja także dla ekosystemu Salesforce: jeśli próbujemy jednym agentem obsłużyć analizę intencji, wybór narzędzia, transformację danych, walidację i wykonanie, szybko pojawiają się błędy, niestabilność i słaba przewidywalność.

Lepszym podejściem okazała się dekompozycja na agentów wyspecjalizowanych domenowo. Każdy z nich dostaje ograniczony kontekst, dedykowane narzędzia i jasno określoną odpowiedzialność. Dzięki temu spada obciążenie poznawcze modelu, poprawia się precyzja działania i rośnie stabilność wykonania. To ten sam kierunek, który widać przy projektowaniu architektury rozmów i pamięci operacyjnej w systemach AI działających na dużą skalę – podobny problem analizowaliśmy przy skalowaniu architektury rozmów AI w Salesforce.

Dla praktyka Salesforce wniosek jest prosty: nie warto zaczynać od pytania, jaki model wybrać. Najpierw trzeba ustalić, czy proces faktycznie da się rozbić na kroki z osobnymi odpowiedzialnościami. Jeśli tak, większy sens ma orkiestracja kilku agentów niż rozbudowywanie jednego uniwersalnego asystenta.

Jak działa architektura multi-agent i skąd bierze się kontrola

Rdzeniem systemu jest agent orkiestracji. To on rozpoznaje intencję użytkownika, buduje plan działania i deleguje zadania do agentów specjalistycznych. W praktyce nie chodzi więc o swobodną rozmowę z AI, ale o kontrolowane przejście od intencji do planu, a potem do wykonania. Podczas realizacji pojedynczego zadania system może wywołać 50-60 modeli AI, co pokazuje skalę ukrytej złożoności pod prostym interfejsem użytkownika.

Żeby taka architektura nie zamieniła się w czarną skrzynkę, użytkownik ma wgląd w plan i może go modyfikować przed wykonaniem. To istotny element równowagi między elastycznością a przewidywalnością. W środowisku Salesforce taka zasada ma duże znaczenie zwłaszcza tam, gdzie agent dotyka danych klientów, reguł biznesowych albo automatyzacji operacyjnych. Human-in-the-loop nie jest tu dodatkiem, ale mechanizmem ograniczania ryzyka.

Drugim filarem jest warstwa semantyczna. Jej zadaniem jest rozpoznanie kontekstu i rozłożenie intencji na kroki zrozumiałe dla poszczególnych agentów. Zamiast przekazywać modelom pełny, nadmiarowy kontekst, system dostarcza tylko informacje potrzebne do konkretnego zadania. To podejście dobrze koresponduje z tym, jak rozwija się bezpieczny RAG i praca na danych nieustrukturyzowanych – podobne napięcie między użytecznością a kontrolą widać w analizie Notebook AI w Data 360.

Dla zespołów wdrożeniowych oznacza to potrzebę projektowania agentów nie jako samodzielnych bytów, ale jako elementów systemu z kontraktami wejścia i wyjścia. Im lepiej zdefiniowany zakres decyzji i zestaw narzędzi, tym łatwiej utrzymać spójność działania.

Co decyduje o niezawodności i jak przenieść te wnioski do Salesforce

Wielostopniowy łańcuch agentów jest wrażliwy na propagację błędów. Pomyłka jednego kroku może zepsuć cały workflow, dlatego kluczowe okazały się walidacje i kontrakty danych pomiędzy agentami. Każdy etap musi oddawać wynik w formie, którą kolejny etap potrafi bezpiecznie zinterpretować. To praktyka bliska klasycznej integracji systemowej, tylko przeniesiona do architektury AI.

System przeszedł rygorystyczne testy dokładności, wiarygodności i spójności, ale nie ograniczano się do standardowych metryk AI. Dla każdej funkcji agenta przygotowano osobne miary jakości efektu końcowego. W obszarze jakości danych osiągnięto 90% skuteczności realizacji zadań, 98% dokładności osadzenia wyników w rzeczywistych metadanych i 1% przypadków generowania nieprawidłowych informacji. To ważna wskazówka dla zespołów Salesforce: ocena agenta nie może kończyć się na jakości odpowiedzi tekstowej. Trzeba mierzyć, czy wynik da się bezpiecznie osadzić w realnym procesie i danych.

Dodatkowo zastosowano wielowarstwową kontrolę poprawności, w tym ocenę generowanego kodu przez modele LLM oraz mechanizmy przeglądu i walidacji. W praktyce przypomina to rozbudowane guardrails dla agentów wykonujących zadania operacyjne. Jeśli planujesz AI nad procesami CRM, podobne zasady warto połączyć z twardą dyscypliną jakości danych, bo bez niej agent tylko szybciej rozprowadza błędy. Ten temat dobrze uzupełnia podejście opisane w materiale o Validation Rules przygotowujących org pod AI.

Najciekawszy wniosek jest jednak szerszy. Autonomiczne działanie agentów ma sens nie tylko w trybie na żądanie, ale też ciągłym – przy monitorowaniu jakości danych, walidacji reguł czy kontroli zdrowia przepływów. Dla organizacji pracujących na Salesforce to podpowiedź, by patrzeć na agentów nie wyłącznie jak na interfejs konwersacyjny, ale jak na warstwę operacyjną stale pilnującą kondycji danych i automatyzacji.

Największa lekcja z tej architektury nie dotyczy samego AI, lecz sposobu modelowania pracy. Skuteczne systemy agentowe nie próbują być wszechwiedzące – są podzielone, ograniczone i stale kontrolowane. Właśnie to pozwala skrócić złożone workflow z miesięcy do dni bez utraty przewidywalności. Pytanie dla zespołów Salesforce brzmi więc nie czy wdrażać agentów, ale które procesy są już na tyle dobrze opisane, by dało się je bezpiecznie rozbić na agentową orkiestrację.