Salesforce Headless 360: co zmienia dla zespołów CRM

Ponad 60 nowych narzędzi MCP i ponad 30 prekonfigurowanych umiejętności programistycznych to sygnał, że Salesforce przestaje być głównie interfejsem w przeglądarce, a staje się warstwą usług wywoływanych przez kod i agentów (Apex Hours). Dla polskich zespołów oznacza to zmianę praktyczną: coraz mniej pracy będzie dotyczyć klikania po setupie, a coraz więcej projektowania kontraktów, guardrails i jakości metadanych. TDX 2026 pokazał też, że cykl od prototypu do produkcji ma być krótszy, ale tylko tam, gdzie org jest gotowy na development sterowany agentami. Największa zmiana nie dotyczy więc pojedynczej funkcji, tylko nowego modelu budowania na platformie.

Headless 360 przesuwa Salesforce w stronę API-first

Salesforce Headless 360 to deklaracja, że cały ekosystem platformy ma być dostępny jako API, narzędzia MCP i komendy CLI. W praktyce oznacza to, że dane, metadane, logika biznesowa, approvale i zestawy uprawnień stają się interfejsem dla kodu, który można odkrywać, wywoływać i łączyć bez otwierania przeglądarki. To wyraźne przesunięcie akcentu – platforma ma działać jako infrastruktura dla agentów programistycznych, a nie tylko jako UI dla człowieka.

W skład tego podejścia wchodzą integracje z Claude Code, Cursor, Codex i Windsurf, ponad 60 narzędzi MCP oraz ponad 30 gotowych umiejętności rozumiejących wzorce developerskie Salesforce. Dochodzi do tego natywne wsparcie React, które otwiera drogę do budowania własnych front-endów poza standardowym UI Salesforce. Dla architekta to ważny sygnał: granica między aplikacją na Salesforce a aplikacją obok Salesforce staje się dużo bardziej płynna.

Dla praktyka najważniejsze są trzy konsekwencje. Po pierwsze, rośnie znaczenie spójnych metadanych i przewidywalnej konfiguracji orga, bo agent może działać tylko na tym, co da się jednoznacznie odczytać i wywołać. Po drugie, admin i developer zaczynają pracować na wspólnej warstwie kontraktów platformowych, a nie na dwóch osobnych światach – klikanym i kodowym. Po trzecie, governance musi objąć nie tylko aplikacje, ale też agentów, którzy będą wykonywać zmiany i operacje na orgu. Ten kierunek dobrze łączy się z wcześniejszym otwarciem metadata layer dla AI i MCP Server, które opisaliśmy w analizie zmiany AI w Spring ’26.

Jeśli zespół chce przygotować się na ten model, warto zacząć od przeglądu procesów, które dziś wymagają ręcznego przechodzenia po setupie. Tam, gdzie da się je opisać jako zestaw wywołań, pojawia się kandydat do automatyzacji przez agentów. Bez porządku w naming convention, permission modelu i jakości metadanych Headless 360 przyspieszy chaos zamiast delivery.

Agentforce Vibes 2.0 skraca budowę, ale podnosi wymagania jakościowe

Agentforce Vibes 2.0 jest już dostępny i ma działać jako ulepszone środowisko IDE dla deweloperów. Najważniejsze elementy to obsługa wielu modeli językowych, świadomość metadanych organizacji oraz dwa tryby pracy – Plan i Act. Plan pozwala zasymulować zmiany przed wykonaniem, a Act przejść od razu do działania. To nie jest kosmetyczne rozszerzenie edytora, tylko próba zamknięcia całego cyklu budowania w jednym środowisku.

Salesforce deklaruje do 40% szybszy proces budowy dzięki ograniczeniu przełączania się między narzędziami. Tę obietnicę trzeba czytać ostrożnie: zysk czasu pojawi się tam, gdzie org ma czytelny model danych, sensownie opisane komponenty i niewielki dług techniczny. Tam, gdzie metadane są niespójne, agent wygeneruje kod szybciej, ale niekoniecznie lepiej. Dlatego Vibes 2.0 jest bardziej wzmacniaczem jakości orga niż automatycznym lekarstwem na problemy delivery.

Istotne jest też to, że każda Developer Edition zawiera teraz IDE Agentforce Vibes, domyślny model Claude Sonnet 4.5 oraz hostowane przez Salesforce serwery MCP. Wejście jest więc niemal natychmiastowe i nie wymaga skomplikowanej konfiguracji. To obniża próg eksperymentów, ale jednocześnie zwiększa ryzyko szybkiego narastania długu technicznego, jeśli zespół nie zdefiniuje zasad użycia AI w developmentcie. Ten problem szerzej omawialiśmy w tekście o tym, jak Agentforce Vibes zmienia sposób budowania aplikacji.

Najrozsądniejszy ruch na teraz to wykorzystanie trybu Plan do zadań o niskim ryzyku i wysokiej powtarzalności – analizy metadanych, scaffoldingu komponentów, refaktoru prostych fragmentów czy przygotowania zmian technicznych do review. Tryb Act powinien wejść do użycia dopiero wtedy, gdy zespół ma jasne reguły code review, testów i odpowiedzialności za zmiany generowane przez AI.

Agent Script, AXL i Slack budują nową warstwę operacyjną

Najciekawsza zmiana z perspektywy architektury dotyczy nie samego generowania kodu, ale sposobu definiowania zachowania agentów. Agent Script został otwarty jako open source i ma służyć do opisu tego, kiedy agent korzysta z rozumowania LLM, kiedy przechodzi na logikę deterministyczną, jakie subagenty może wywołać, jakie zmienne śledzi i jakie ograniczenia obowiązują. To przypomina infrastrukturę jako kod, ale przeniesioną na warstwę zachowania agentowego.

Dzięki temu agent przestaje być tylko promptem z doklejonymi narzędziami. Staje się artefaktem, który można wersjonować, analizować lokalnie w IDE i poddawać przeglądom bezpieczeństwa wspieranym przez AI. Dla zespołów pracujących w regulated environments to ważna różnica – pojawia się szansa na bardziej kontrolowany model wdrażania agentów niż zwykłe prompt engineering. W kontekście governance to naturalnie łączy się z pytaniami o agent sprawl i kontrolę nad autonomią, które rozwijaliśmy w analizie ryzyka rozrostu agentów w ekosystemie Salesforce.

Drugim elementem jest Agentforce Experience Layer, czyli AXL. Ta warstwa oddziela logikę agenta od prezentacji i pozwala wyświetlać tego samego agenta natywnie w Slacku, Salesforce Mobile, ChatGPT, Claude, Microsoft Teams czy w kliencie MCP. To upraszcza utrzymanie, bo zachowanie agenta nie musi być przepisywane dla każdego kanału osobno. Dla polskich zespołów oznacza to mniej duplikacji i łatwiejsze projektowanie omnichannel dla agentów.

Na końcu tego układu stoi Slack jako nowy front door dla agentowego przedsiębiorstwa. Slackbot ma działać jako klient MCP, Slack Agent Kit ma umożliwiać podpinanie agentów z dowolnej platformy bez przebudowy backendu, a natywne funkcje CRM w Slacku mają obniżać próg użycia. Do tego dochodzi preview Project Albert – lokalnego agenta do autonomicznej interakcji na pulpicie w Slacku i aplikacjach Salesforce. To pokazuje, że interfejs pracy przesuwa się z rekordów i layoutów w stronę konwersacji oraz akcji wykonywanych przez agentów.

Wniosek z TDX 2026 jest prosty: przyszły backlog Salesforce będzie coraz mniej przypominał listę ekranów do zbudowania, a coraz bardziej katalog usług, kontroli i zachowań agentów. Pytanie nie brzmi już, czy wejść w ten model, tylko jak zrobić to bez utraty kontroli nad bezpieczeństwem, jakością i kosztami. W polskich orgach wygrają te zespoły, które potraktują AI nie jako skrót do szybszego developmentu, ale jako nową warstwę architektury. Czy Twój org ma już fundamenty, by agent mógł działać na produkcji równie przewidywalnie jak człowiek?