A2A w Salesforce zmienia architekturę szybciej niż LWC zastąpiło Aurę

W orgach Salesforce pojawia się nowy typ problemu: pojedynczy Flow lub agent AI zaczyna intensywnie odpytywać dane, bo kolejne moduły nie potrafią ustalić, kto ma wykonać zadanie. To nie błąd implementacji, tylko symptom głębszej zmiany architektury – przejścia z pojedynczych chatbotów do modelu Agent-to-Agent, który Salesforce opisuje jako Agentic Swarm (SalesforceBen). W tym modelu agenci AI nie pracują w izolacji, ale współdziałają, przekazując sobie intencję, dane i wnioski. Dla praktyków oznacza to rewolucję w projektowaniu procesów, integracji, governance i kosztów. Jak A2A działa technicznie pod spodem oraz jak przygotować na to polską organizację?

Fundamenty techniczne A2A – jak naprawdę współpracują agenci

W architekturze A2A Salesforce wprowadza dwa typy agentów: Orchestrator i Specialist. Orchestrator działa jako warstwa planowania, konfigurując reguły w GenAiPlanner i odpowiadając za semantyczny breakdown intencji użytkownika. Kluczowe jest to, że nie posiada głębokiej wiedzy domenowej – jego zadaniem jest dobrać odpowiednich Specialistów, którzy operują na wąskim wycinku danych. To radykalnie różni się od klasycznych chatbotów, które próbowały „znać wszystko”.

Specjaliści działają z kolei na Data 360 z użyciem Retrieval-Augmented Generation, co oznacza, że ich odpowiedzi nie są generowane z pamięci modelu, ale z danych pochodzących z DMOs. Dzięki Zero Copy (źródło: SalesforceBen) agenci mogą analizować dane z hurtowni Snowflake czy AWS bez ETL. To istotne w Polsce, gdzie wiele firm dopiero migruje do Data 360 lub prowadzi dane równolegle w kilku systemach finansowych.

W praktyce to oznacza, że agenci nie przekazują sobie długich promptów czy nieustrukturyzowanych opisów, lecz jednoznaczne identyfikatory i artefakty JSON. Minimalizuje to ryzyko halucynacji oraz zapewnia zgodność z RODO, bo dane wrażliwe są maskowane w Einstein Trust Layer. W polskich wdrożeniach ma to znaczenie szczególnie w branżach finansowych i medycznych, gdzie agent nie może mieć dostępu do danych niezgodnych z polityką przetwarzania.

Ta warstwa planowania i wąskiej specjalizacji jest bliższa temu, co analizujemy w Agentblazer Community, gdzie coraz więcej praktyków pracuje na specjalistycznych agentach z precyzyjnymi kompetencjami. A2A formalizuje to podejście w architekturze enterprise.

Swarm i Sequential – dwa wzorce, które zmieniają procesy w polskich orgach

Wzorzec Swarm uruchamia wielu specjalistów równolegle. To użyteczne w złożonych procesach, np. ocenie ryzyka kredytowego lub ofertowania w B2B, gdzie dział prawny, finanse i supply chain muszą równocześnie sprawdzić swoje segmenty. Apexowy Artifact Collector pozwala każdemu agentowi raportować swoje wnioski w sposób deterministyczny. W kontekście polskich wdrożeń RevOps to oznacza krótszy czas oceny kontraktów i mniejszą presję na działy analityczne.

Z kolei Sequential przypomina linię montażową – każdy agent przekazuje dane kolejnej jednostce. Salesforce proponuje tu guardrails w Apexie, które blokują propagację błędnych założeń. Przykład: zbyt wysoki rabat automatycznie eskaluje ścieżkę do VP Finance Agent. W polskich firmach, gdzie reguły rabatowe są często rozproszone między CPQ, Excelami i custom logic, jest to szansa na wprowadzenie deterministycznej ścieżki decyzji.

Oba wzorce łączy jeden krytyczny element: kontrolowana wymiana danych. Salesforce podkreśla, że pomyłka jednego agenta w Sequential może zniszczyć całą linie przetwarzania. To dokładnie ten sam problem opisany w nowym workflow admina, gdzie błędne triggerowanie Flow przez AI może prowadzić do chaosu. W A2A rozwiązaniem są RecordId jako jedyny klucz wymiany, Timeouts i Max Hop Count – czyli coś, czego Flow nadal nie zapewnia natywnie.

Nowe ryzyka i failure modes – realne zagrożenia w polskich wdrożeniach

A2A wprowadza nowe typy awarii, których architekci wcześniej praktycznie nie musieli brać pod uwagę. Token Storm to sytuacja, w której dwa agenty zaczynają przerzucać między sobą odpowiedzialność – przykład realny to opisany w źródle konflikt na tle ustalenia, kto odpowiada za shipping. W polskich orgach podobny problem widzimy w procesach magazynowych zewnętrznych integracji, gdzie ERP i Salesforce walczą o prawo do decydowania o statusie zamówienia.

Deadlock to kolejny problem: Agent A czeka na dane od B, a B na zatwierdzenie od A. Klasyczne BPMN nie obejmuje takiego scenariusza, dlatego Salesforce proponuje Orchestrator-led timeouts i przejście do Human-in-the-Loop. To podobne podejście do mechanizmu incydentów opisanego w automatyzacji incident response, gdzie AI przejmuje zadania do momentu, aż nie osiągnie progu ryzyka.

Trzecia kategoria problemów to halucynacja propagowana po łańcuchu. Tu Data 360 i RAG są kluczowe, ponieważ agent nie może zgadywać statusu klienta – musi go pobrać z DMOs. W Polsce ma to dodatkowy wymiar: wiele firm trzyma dane klientów w księgowości, ERP, CRM i jeszcze marketing automation. Jeżeli nie połączą ich w Data 360, agenci będą operować na sprzecznych źródłach.

Dla architektów oznacza to jedno: A2A wymaga dojrzałości danych i deterministycznych reguł bardziej niż klasyczne Flow czy Apex. Bez tego nie da się uniknąć spirali kosztów API i eskalacji do ludzi.

Strategia adopcji A2A – jak wdrożyć agentów, żeby nie zniszczyć procesów

Pierwszym krokiem jest wprowadzenie Atomic Specialists. To oznacza, że nie tworzymy jednego agenta, który „obsługuje billing”, ale dzielimy go na wyspecjalizowane jednostki, np. PaymentStatus_Agent, InvoiceRAG_Agent, SubscriptionEligibility_Agent. Ogranicza to koszty tokenów i poprawia trafność reasoning. W polskich orgach to dobry moment, by pozbyć się custom logic, która latami kumulowała się w Apexie czy CPQ.

Kolejnym krokiem jest budowa warstwy state management poprzez sessionId i correlationId. W wielu firmach w Polsce nadal brakuje porządnego systemu logowania korelacyjnego, więc wprowadzenie A2A i tak wymusi zmianę. Salesforce sugeruje też Turn Limit na poziomie Orchestratora – pięć przekazań maksymalnie. W organizacjach o skomplikowanych procesach sprzedażowych pozwala to uniknąć niekontrolowanej ekspansji agentów.

Trzecim filarem jest governance: Trust Layer, HITL, instrukcje semantyczne i audyt reasoning path. To ostatnie szczególnie przydatne w RODO, bo każdą decyzję AI można uzasadnić na podstawie ścieżki wywołań. Warto już dziś zablokować agenta, który może wywołać krytyczne akcje bez HITL, podobnie jak Salesforce robi to w kodzie przykładowym z Approval Tasks.

Wreszcie – integracja z istniejącymi systemami. Polskie firmy mają ERP-y, WMS-y i systemy finansowe, które nie są gotowe na agentic handoffs. Strategia musi uwzględniać to, że A2A nie zastąpi integracji – jedynie ją usystematyzuje i przyspieszy. Organizacje, które mają już Data 360, mają tu przewagę.

Wnioski – jak zmieni się praca architekta Salesforce

A2A to największa zmiana architektury Salesforce od czasów wejścia Lightning. To przesunięcie uwagi z pojedynczych automatyzacji na projektowanie interakcji między autonomicznymi modułami. Dla polskich zespołów oznacza to konieczność ujednolicenia danych, wprowadzenia guardrails i rezygnacji z rozbudowanych Flow, które nie są kompatybilne z modelem agentic. Najbliższe miesiące pokażą, że różnica między firmami, które przygotują architekturę pod A2A, a tymi, które zostaną przy klasycznym podejściu, będzie równie duża jak różnica między Orgami, które przeszły na LWC, a tymi, które nadal wspierają Aurę. Pytanie, które powinieneś sobie zadać: które procesy w Twojej organizacji jako pierwsze staną się agent-to-agent?