O rynek infrastruktury dla agentów wewnętrznych rywalizują dziś gracze startujący z czterech różnych pozycji: dostawcy tożsamości (Okta), hiperskalerzy chmurowi (Google, AWS), platformy aplikacji biznesowych (Salesforce, ServiceNow) i laboratoria modeli (OpenAI, Anthropic). Każdy próbuje uczynić centrum zarządzania agentami to, co już posiada — i właśnie punkt wyjścia, nie funkcje z ulotki, najlepiej przewiduje, czym każde z tych rozwiązań będzie za dwa lata.
W tym hubie konsekwentnie używamy Microsoftu jako punktu odniesienia — zapowiedzieliśmy to we wstępie i wyjaśniliśmy dlaczego: katalog tożsamości, w którym korporacje już trzymają ludzi, to pozycja nie do skopiowania. Ale mapa z jednym punktem to nie mapa. Ta strona domalowuje resztę — nie jako przegląd produktów (te zestarzeją się przed końcem kwartału), lecz jako przegląd strategii, bo strategie starzeją się wolniej.
Zasada lornetki: patrz na punkt wyjścia, nie na ulotkę
Wszyscy gracze na tym rynku obiecują dziś to samo — słowa „governance”, „identity”, „control plane” i „fleet” występują w każdym materiale marketingowym, w niemal losowej kolejności. Porównywanie list funkcji jest więc jałowe: listy się zrównają, bo każdy dopisze to, co ma konkurencja.
Nie zrównają się punkty wyjścia. Firma, która ma katalog tożsamości, będzie rozwiązywać problem agentów tożsamościowo. Firma, która ma chmurę — infrastrukturalnie. Firma, która ma CRM — przez pryzmat procesów biznesowych. To nie jest zarzut; to grawitacja. I dla kupującego to najlepsza dostępna heurystyka: wybierając platformę agentową, wybierasz czyjś środek ciężkości — sprawdź, czy pokrywa się z twoim.
Cztery punkty wyjścia
Tożsamość: Okta
Jedyny duży gracz, dla którego agenci to nie rozszerzenie innego biznesu, lecz wprost przedłużenie biznesu głównego. Teza Okty jest lustrem tezy Microsoftu: skoro problem agentów rozstrzyga się w warstwie tożsamości — a tak twierdzimy w tym hubie od pierwszej strony — to wygra ten, kto zarządza tożsamościami najlepiej, a nie ten, kto ma ich najwięcej. Atut Okty: neutralność. Nie sprzedaje ani modeli, ani pakietu biurowego, więc dla organizacji wielochmurowych i niechcących pogłębiać zależności od jednego dostawcy jest naturalnym kandydatem na warstwę spinającą agentów z różnych ekosystemów. Słabość: symetryczna — Okta nie kontroluje środowisk, w których agenci powstają, więc jej widoczność zawsze zależy od integracji, nie od bycia gospodarzem.
Chmura: Google i AWS
Hiperskalerzy wchodzą od strony, którą znają: agent to obciążenie (workload), które trzeba uruchomić, wyskalować, zabezpieczyć i rozliczyć. Google gra dwiema kartami naraz — infrastrukturą (platformy agentowe w Google Cloud, z Gemini jako silnikiem) i miejscem pracy (agenci w Workspace, czyli odpowiednik zagrania Microsoftu, tylko z mniejszym katalogiem korporacyjnych tożsamości). AWS gra klasycznie po swojemu: klocki dla budujących — usługi agentowe w konsoli, z founding-memberstwem w otwartych protokołach komunikacji między agentami. Siła obu: tam, gdzie firma już trzyma dane i obliczenia, tam najtaniej osadzić agentów. Słabość wspólna: perspektywa „agent jako workload” świetnie odpowiada na pytania jak uruchomić, gorzej na pytania tego huba — kto pozwolił, kto nadzoruje, kto odpowiada. Governance u hiperskalerów historycznie doganiał infrastrukturę z opóźnieniem i nic nie wskazuje, żeby tym razem było inaczej.
Aplikacje biznesowe: Salesforce i spółka
Salesforce z Agentforce wchodzi od strony procesu: agent nie jest bytem w katalogu ani workloadem w chmurze — jest pracownikiem działu, osadzonym tam, gdzie żyją dane klienckie i procesy sprzedaży czy obsługi. To podejście daje najkrótszą drogę od zakupu do efektu biznesowego (agent od obsługi zgłoszeń w systemie, w którym zgłoszenia już są) i najbardziej naturalny nadzór merytoryczny — właścicielem agenta jest szef działu, nie IT. Cena tej wygody: granice. Agent Salesforce’a jest obywatelem Salesforce’a; im więcej pracy dzieje się poza platformą, tym bardziej widać, że „flota” w tym modelu to flota jednego akwenu. Analogiczny ruch wykonują pozostałe platformy aplikacyjne (ServiceNow w IT i workflow, SAP w procesach), każda ogłaszając swoich agentów w swoim świecie — co dla kupującego oznacza perspektywę nie jednej floty, lecz kilku flot dziedzinowych, które ktoś kiedyś będzie musiał spiąć.
Modele: OpenAI i Anthropic
Laboratoria modeli wchodzą od strony zdolności: najpierw agent musi umieć pracować, potem można nim zarządzać. Ich produkty enterprise (ChatGPT Enterprise, Claude for Work i warstwy API z narzędziami agentowymi) dostarczają najzdolniejszych agentów i coraz dojrzalsze kontrolki administracyjne — ale zarządzanie flotą w rozumieniu tego huba (rejestr wszystkiego, co działa w firmie, niezależnie od pochodzenia) nie jest ich grą i szczerze mówiąc nie musi być: to oni są tym, co inne platformy zarządzają. Dla organizacji oznacza to proste rozstrzygnięcie: model wybiera się osobno od płaszczyzny kontroli — i lepiej, żeby płaszczyzna kontroli nie wymuszała modelu.
Warstwa, która może unieważnić część tej mapy: protokoły
Nad rywalizacją platform toczy się drugi mecz, o standardy: protokoły komunikacji agent–agent i agent–narzędzie (z MCP na czele, rozkładanym u nas na części, oraz rodziną protokołów interoperacyjności między agentami). Ich znaczenie dla tej strony jest jedno: im silniejsze standardy, tym słabszy argument „kup wszystko u nas”. W świecie dojrzałych protokołów agent z jednego ekosystemu pracuje z narzędziami z drugiego pod nadzorem tożsamości z trzeciego — i wtedy wygrywają gracze warstwowi (tożsamość, control plane), a przegrywają ogrody murowane. W świecie standardów słabych — odwrotnie. Historia informatyki grała ten mecz wielokrotnie i wynik nigdy nie był przesądzony z góry; dlatego obserwowanie protokołów mówi o przyszłości tego rynku więcej niż obserwowanie premier produktowych.
Jak wybierać — pięć pytań zamiast rankingu
Nie damy rankingu, bo ranking wymagałby założenia, że wszystkie organizacje mają ten sam środek ciężkości — a cała teza tej strony mówi, że nie mają. Zamiast tego pięć pytań, które zadane uczciwie, wskazują odpowiedź same:
- Gdzie już są nasze tożsamości? Jeśli w Entra — argument za Microsoftem jest strukturalny. Jeśli w Okcie — analogicznie. Migracja katalogu tożsamości dla agentów to ogon machający psem.
- Gdzie powstanie najwięcej naszych agentów? W pakiecie biurowym, w CRM-ie, w chmurze developerskiej? Płaszczyzna kontroli powinna być gospodarzem tam, gdzie rodzi się flota — inaczej całe zarządzanie wisi na integracjach.
- Ilu dostawców agentów będziemy mieć naprawdę? Jeśli odpowiedź brzmi „kilku” (a zwykle brzmi), rozwiązania zamknięte na cudzych agentów odpadają definicyjnie — rejestr, który nie widzi wszystkiego, nie jest rejestrem.
- Czy płaszczyzna kontroli wymusza model? Jeśli tak — liczcie koszt tej pary za trzy lata, nie dziś. Modele tanieją i zmieniają lidera co kilkanaście miesięcy; kontrakty nie.
- Co z naszymi czterema pytaniami incydentu? Test praktyczny na koniec: poproś dostawcę, żeby na żywo pokazał, jak jego platforma odpowiada na „co agent zrobił, dlaczego, kto pozwolił, kto teraz działa”. Marketing mówi o funkcjach; demo z tych czterech pytań mówi o dojrzałości.
Ostatnia gałąź huba odwraca perspektywę raz jeszcze: zamiast pytać, czym zarządzać agentami, zapyta, jak wygląda organizacja, która już to umie — Frontier Firm.
