Agentforce po TDX 2026: wzorce buildów dla praktyka

11 nagrodzonych rozwiązań z hackathonu TDX 2026 pokazuje, że Agentforce daje największą wartość nie wtedy, gdy odpowiada na pytania, ale gdy spina dane, workflow i człowieka w jednym procesie.

Dla admina, developera i architekta to ważny sygnał, bo większość wyróżnionych buildów nie opierała się na samym interfejsie konwersacyjnym, tylko na połączeniu Agentforce z Data 360, Slackiem, Tableau i automatyzacją (Salesforce Admins). W praktyce oznacza to przesunięcie akcentu z budowy pojedynczego bota na projektowanie pełnego przepływu decyzji, danych i eskalacji. To właśnie ten model warto dziś analizować, jeśli zespół planuje pierwszy use case produkcyjny albo porządkuje istniejące eksperymenty z AI.

Najmocniejszy wzorzec: agent jako warstwa orkiestracji pracy

Najciekawsze projekty z TDX 2026 rozwiązywały problemy operacyjne, w których liczy się czas, koordynacja i kontekst. City Pulse Agent porządkował zgłoszenia miejskie, wykrywał trendy w danych historycznych i wspierał działania zapobiegawcze. HarvestBridge zbudowano jako system wieloagentowy, w którym osobne role odpowiadały za przyjęcie zgłoszenia, dopasowanie odbiorcy, logistykę i analizę wpływu. Purple 11 skracał proces łączenia uczniów z opiekunami po sytuacjach awaryjnych dzięki workflow prowadzonemu przez agenta, kodom QR i weryfikacji tożsamości.

To ważne, bo wspólny mianownik tych rozwiązań nie sprowadza się do generowania odpowiedzi. Agent działa tu jako warstwa orkiestracji – zbiera sygnały, uruchamia kolejne kroki, przydziela zadania i utrzymuje proces w ruchu. W części przypadków oznacza to model human-in-the-loop, gdzie człowiek pozostaje w krytycznym punkcie decyzyjnym. KnowledgeForce dobrze pokazuje ten mechanizm: gdy agent nie zna odpowiedzi, eskaluje sprawę do eksperta na Slacku, a po uzyskaniu odpowiedzi zapamiętuje ją na przyszłość.

Dla praktyka Salesforce to wskazówka, by nie zaczynać projektu od pytania „jakiego agenta zbudować”, tylko od pytania „który proces dziś traci najwięcej czasu na przekazanie kontekstu między ludźmi i systemami”. Jeśli problemem jest koordynacja, Agentforce ma sens. Jeśli problemem jest tylko brak jednego ekranu lub prostego formularza, klasyczny Flow albo Experience Cloud mogą wystarczyć. W tym kontekście przydaje się też analiza architektury systemów wieloagentowych i sposobu ich orkiestracji, jak w materiale o multi-agent AI w danych.

Drugi praktyczny wniosek dotyczy podziału odpowiedzialności. HarvestBridge nie próbował budować jednego uniwersalnego agenta do wszystkiego. Rozdzielenie ról na DonorBot, MatchMaker, LogisticsCoordinator i ImpactAnalyst upraszcza logikę, testowanie i kontrolę jakości. W polskich orgach to oznacza, że lepiej projektować mniejsze, jasno ograniczone capability niż jednego agenta z nadmiarem promptów, wyjątków i akcji.

Dane i kanały są ważniejsze niż sam model rozmowy

Wyróżnione rozwiązania bardzo często opierały się na Data 360 jako warstwie profilu i kontekstu. VA Benefits Processing Agent używał profilu Data 360 do wsparcia zarówno weterana, jak i pracownika obsługującego wniosek. EdAdmit Evaluation Agent scalał dane kandydatów w jeden profil, aby ocena eseju i materiałów aplikacyjnych była osadzona w pełnym obrazie kandydata. VINtelligence zapisywał interakcje klienta z agentem wokół konkretnego pojazdu, co dawało dealerowi wgląd w zachowania kupujących.

To pokazuje prostą zależność: skuteczność agenta rośnie wtedy, gdy ma dostęp do aktualnego, spójnego kontekstu. Bez tego nawet dobrze zaprojektowana rozmowa szybko zamienia się w kolejną warstwę zgadywania. Dlatego przygotowanie danych nadal pozostaje warunkiem wdrożenia, a nie zadaniem pobocznym. Dobrze koresponduje z tym podejście opisane w tekście o przygotowaniu danych Salesforce pod AI, gdzie jakość wejścia decyduje o jakości automatyzacji.

Drugim stałym elementem był Slack jako kanał pracy operacyjnej, a nie tylko komunikator. CareRoute przetwarzał dokumenty PDF przesłane w Slacku, wydobywał dane przez Document AI i dobierał terapeutę według specjalizacji, języka i dostępności. KnowledgeForce używał Slacka do eskalacji braków wiedzy. HarvestBridge koordynował wolontariuszy właśnie przez ten kanał. To ważne dla zespołów, które wciąż traktują integrację Slacka z Salesforce jako dodatek do powiadomień. W tych buildach Slack staje się interfejsem wykonania procesu.

W praktyce warto więc ocenić trzy elementy przed startem wdrożenia: gdzie powstaje kontekst danych, gdzie człowiek podejmuje decyzję i w jakim kanale naprawdę pracuje zespół. Jeśli pracownicy działają głównie w Slacku, przenoszenie wszystkiego do niestandardowego UI może tylko zwiększyć tarcie. Jeśli zaś dane wejściowe przychodzą jako dokumenty, obrazy lub głos, trzeba od razu zaprojektować ich ekstrakcję i walidację. W tym obszarze pomocny będzie też materiał o AI voice recognition w Salesforce, bo część projektów z TDX korzystała z wejścia głosowego i obrazowego.

Najlepsze use case’y nie eliminują ludzi, tylko precyzyjnie ustawiają ich rolę

Wśród nagrodzonych projektów widać wyraźnie, że najwyżej oceniane rozwiązania nie próbowały całkowicie usuwać człowieka z procesu. Purple 11 wygrał kategorię Best Use of Humans and Agents Together właśnie dlatego, że agent prowadził pracowników przez ustrukturyzowany workflow, zamiast zastępować ich w krytycznej operacji. KnowledgeForce budował trwały mechanizm przechwytywania wiedzy eksperckiej. Agentforce MSL Copilot w obszarze life sciences ograniczał się do zatwierdzonych materiałów i wykrywania sygnałów bezpieczeństwa do raportowania, co dobrze pokazuje znaczenie kontroli w środowisku regulowanym.

To istotna lekcja dla zespołów wdrożeniowych. Im większe ryzyko operacyjne, prawne lub reputacyjne, tym bardziej agent powinien być projektowany jako asystent decyzji, warstwa kwalifikacji albo akcelerator przygotowania sprawy – nie autonomiczny wykonawca bez nadzoru. CareRoute, VA Benefits Processing Agent czy Relief Bridge nie wygrywały dlatego, że usuwały człowieka, tylko dlatego, że skracały czas dojścia do poprawnej decyzji i redukowały chaos danych.

Z technicznego punktu widzenia widać też dwa równoległe kierunki budowy. Część rozwiązań korzystała z low/no code, jak Relief Bridge oparty na Agentforce, Data 360, Apex i Flow, a część stawiała na pro code, jak Agentforce MSL Copilot z architekturą opartą na Apex. Nie ma tu jednego właściwego wzorca. Jeśli proces jest stabilny i dobrze opisany, Flow oraz konfiguracja mogą wystarczyć. Jeśli potrzebna jest ścisła kontrola logiki, ograniczeń materiałów lub integracji, rośnie rola kodu. To spójne z szerszym kierunkiem platformy, w którym warto świadomie wybierać między konfiguracją a custom development, zamiast zakładać jedno podejście dla wszystkich przypadków.

Najbardziej użyteczny wniosek z całej listy jest więc prosty: dobry projekt Agentforce zaczyna się od procesu z realnym kosztem opóźnienia, ma wyraźnie zdefiniowany kontekst danych i precyzyjnie określa moment wejścia człowieka. Dopiero potem dobiera się kanał, automatyzację i poziom autonomii agenta.

Jeśli zespół planuje własny build na Agentforce, warto szukać nie najbardziej efektownego dema, ale procesu, w którym dziś giną minuty, wiedza albo odpowiedzialność. TDX 2026 pokazał, że największą wartość dają rozwiązania łączące dane, workflow i decyzje, a nie tylko rozmowę z modelem. Pytanie brzmi więc nie czy wdrożyć agenta, ale gdzie w Twoim orgu agent może stać się warstwą operacyjnej koordynacji zamiast kolejnym interfejsem.