Agenci AI w panelu sklepu: co robią w poniedziałek rano

Kiedy ktoś mówi „agent AI prowadzi sklep”, zwykle ma na myśli dwie różne rzeczy naraz. Pierwsza to workflow: proces uruchamiany zdarzeniem albo harmonogramem, który robi jedno zadanie i zostawia ślad w historii uruchomień. Druga to agent: rozmowa, w której człowiek pyta, a system sam dobiera narzędzie i sięga po dane.

Ta różnica jest praktyczna, nie akademicka. Workflow zdejmuje pracę powtarzalną, którą dziś ktoś klika ręcznie. Agent skraca drogę do odpowiedzi, gdy pytanie jest zbyt rzadkie, żeby budować pod nie osobny raport. Zdecydowana większość codziennej wartości siedzi w tej pierwszej warstwie i w samym odczycie danych.

Poniżej konkrety: co dzieje się, gdy przychodzi 200 nowych produktów, gdy feed odrzuca 30 pozycji, gdy klient pyta o paczkę i gdy katalog wchodzi na drugi rynek. Plus warstwa inżynierska, która decyduje, czy AI w panelu z zamówieniami jest narzędziem, czy ryzykiem.

Poniedziałek rano: cztery sytuacje, nie jedna wizja

Zacznijmy od tego, co realnie ląduje na biurku zespołu na początku tygodnia. Cztery sytuacje wracają w każdym rosnącym sklepie i wszystkie mają tę samą cechę: są powtarzalne, mają jasne wejście i jasne wyjście.

Każda z tych czterech rzeczy jest workflow: ma wyzwalacz, zamknięty zakres, regułę postępowania przy braku danych i historię uruchomień.

Zwróć uwagę, czego w tej tabeli nie ma. Nie ma „agent prowadzi sklep”. Jest cztery razy to samo: zadanie powtarzalne przechodzi na proces, a decyzja kosztowna albo nieodwracalna zostaje przy człowieku. To cała mechanika, i ona jest nudniejsza, niż obiecuje większość tekstów o agentach.

Workflow i agent: co je naprawdę różni

Obie warstwy używają tego samego modelu, ale zachowują się inaczej i inaczej się psują. Cztery różnice, które mają znaczenie przy planowaniu:

• Wyzwalacz: workflow rusza po zdarzeniu (nowy produkt, zmiana statusu, świeży eksport) albo o ustalonej godzinie. Agenta uruchamia pytanie człowieka.
• Zakres: workflow ma jedno zadanie i zamkniętą listę pól, których dotyka. Agent sam decyduje, po które dane sięgnąć, w granicach nadanych mu uprawnień.
• Ślad: workflow zostawia historię uruchomień, którą da się porównywać między dniami. Agent zostawia log rozmowy i log zapytania, które faktycznie wykonał.
• Rodzaj awarii: workflow psuje się systemowo, czyli ten sam defekt trafia w każdy wiersz. Agent psuje się punktowo, w pojedynczej odpowiedzi.

Ostatnia różnica jest najważniejsza operacyjnie. Cicha awaria workflow potrafi tydzień siedzieć w katalogu, bo każdy wynik z osobna wygląda poprawnie, a defekt widać dopiero w zestawieniu. Rozłożyliśmy to na trzech zmierzonych przypadkach w tekście o tym, dlaczego automatyzacje AI zawodzą po cichu.

Co obejmuje etap AI Automation

To jest warstwa, która w sklepie zdejmuje najwięcej pracy, i jednocześnie ta najmniej efektowna. Workflow, które budujemy najczęściej:

• Opisy produktów: generowanie w zadanym zakresie znaków, ze słownikiem twierdzeń zakazanych i pól wymaganych (opisy z AI).
• Tłumaczenia katalogu: przeniesienie asortymentu na kolejny język razem z lokalizacją jednostek, rozmiarów i nazw kategorii (tłumaczenia katalogu).
• Feedy marketplace: lokalizacja i walidacja pod wymagania konkretnego kanału, zanim plik pójdzie na produkcję (automatyzacja feedów). Samą sprzedaż na tych kanałach prowadzi u nas Amazonway, więc automat i obsługa konta stoją po tej samej stronie.
• Analiza błędów listingów: grupowanie odrzuceń po przyczynie i propozycja poprawki zamiast surowego raportu (analiza błędów ofert).
• Obsługa klienta: sugestie odpowiedzi oparte na realnym statusie zamówienia, zatwierdzane przez zespół (AI w obsłudze klienta).
• Dane produktowe: mapowanie atrybutów i kategoryzacja, czyli sprowadzanie „czarny”, „black” i „BLK” do jednej wartości kanonicznej.

Każdy z tych procesów ma tę samą anatomię: wyzwalacz, reguły zapisane jako liczby i słowniki zamiast przymiotników, polecenie postępowania przy braku danych oraz historia uruchomień do sprawdzenia. Bez czwartego elementu nie wiadomo, czy proces działa, czy tylko nikt się jeszcze nie poskarżył.

Rozliczamy to per workflow, od 6 000 zł netto. To zakres, a nie oferta: konkretna liczba wychodzi z rozmowy o Twoim katalogu, kanałach i o tym, ile pracy te zadania dziś realnie zjadają. Cały model rozliczeń opisujemy w cenniku, a zakres etapu na stronie AI Automation i w automatyzacjach AI.

Dlaczego naiwny czat po danych nie działa

Najczęstszy pomysł na agenta w panelu wygląda tak: weź dane sklepu, wrzuć je do bazy wektorowej i pozwól modelowi je przeszukiwać. To podejście sprawdza się na dokumentach i rozbija się o dane operacyjne.

Powód jest prosty. Zamówienia, stany i ceny są strukturalne: siedzą w tabelach, mają relacje i zmieniają się co minutę. Wyszukiwanie po podobieństwie tekstu zwraca fragmenty, które brzmią podobnie do pytania, a nie konkretne rekordy, o które pytasz.

Model dostaje wtedy strzępy zamiast danych i robi jedną z dwóch rzeczy: mówi „nie wiem” albo zgaduje. Druga jest gorsza, bo zgadnięta liczba brzmi dokładnie tak samo wiarygodnie jak prawdziwa.

Co robimy zamiast tego

Budujemy agenta, który wykonuje kod, zamiast przeszukiwać tekst. Na pytanie o wstrzymane zamówienia agent układa zapytanie do realnego schematu bazy, uruchamia je w piaskownicy i odpowiada na tym, co faktycznie wróciło.

Skutek jest praktyczny, nie teoretyczny. Odpowiedź pochodzi z tej minuty, a nie z ostatniej indeksacji, i da się ją sprawdzić, bo pokazujemy, jakie zapytanie agent uruchomił i na czym oparł wynik. To ta sama dyscyplina, którą opisywaliśmy przy różnicy między AI-native a vibe codingiem.

Model uprawnień to sedno, nie dodatek

Pytanie pada zawsze i słusznie: co ten agent może popsuć. Odpowiedź nie leży w tym, jak grzecznie sformułujemy polecenie, tylko w tym, do czego agent w ogóle ma dostęp. Dlatego rozdzielamy dwa tryby:

• Tryb „pytaj i czytaj”: agent wyłącznie odczytuje dane. Odpowiada na pytania o zamówienia, stany, klientów i sprzedaż, ale nie może zmienić niczego. Tu siedzi zdecydowana większość codziennej wartości.
• Tryb „działaj”: wąska, wcześniej zatwierdzona lista akcji, na przykład oznaczenie zamówienia do wysyłki albo dodanie notatki. Każda za jawnym potwierdzeniem człowieka i z wpisem do audytu.

Akcje finansowe i destrukcyjne, czyli zwroty, zmiany cen i operacje na danych osobowych, zostają w drugim trybie zawsze. Niezależnie od tego, jak dobrze agent radzi sobie z resztą. To nie jest kwestia zaufania do modelu, tylko kosztu jednej pomyłki.

Dla kogoś, kto wpuszcza AI do panelu z zamówieniami, ta różnica jest fundamentalna. Prompt da się nagiąć nietypowym pytaniem albo treścią wklejoną z zewnątrz, bo prompt jest tekstem i podlega interpretacji. Warstwy uprawnień nie da się wygadać, bo ona nie czyta języka naturalnego.

Do tego dochodzi higiena, która nie jest opcjonalna: endpoint agenta wyłącznie za uwierzytelnieniem, każde zapytanie ograniczone do zalogowanego użytkownika i jego roli, osobne środowiska dla stagingu i produkcji, minimalizacja danych osobowych w odpowiedziach oraz audyt każdego wywołania.

Manifest dostępu: jeden artefakt, trzy funkcje

Manifest dostępu to konfiguracja mówiąca wprost, do jakich modułów i pól agent ma wgląd, jakie akcje może wykonać i które z nich wymagają zgody. Nie jest akapitem w prompcie, tylko plikiem egzekwowanym w warstwie narzędzi. Robi trzy rzeczy naraz:

• Kontrola bezpieczeństwa: czego nie ma w manifeście, tego nie ma w ogóle. Rozszerzenie zakresu jest zmianą konfiguracji, którą ktoś zatwierdza, a nie efektem sprytnie zadanego pytania.
• Artefakt zgodności: audytor nie musi wierzyć w opowieść o polityce dostępu, tylko czyta jej zapis. Przy danych osobowych to różnica między deklaracją a dowodem.
• Argument dla klienta: zespół widzi na piśmie, czego AI dotyka, a czego nie. To zwykle rozstrzyga rozmowę o tym, czy w ogóle wpuszczamy agenta do panelu.

Manifest ma jeszcze jedną zaletę, mniej oczywistą. Zamienia ogólną dyskusję o ryzyku AI w konkretny przegląd listy: to zostaje, to wypada, to wymaga potwierdzenia. Rozmowa, która bez niego trwa miesiąc i kończy się niczym, z nim trwa godzinę i kończy się decyzją.

Osobno warto rozbroić jedno nieporozumienie. „AI uczy się z naszych danych” brzmi groźnie, bo sugeruje trenowanie modelu na danych klientów. W tej architekturze nic takiego nie ma miejsca: agent wykonuje zapytanie na żądanie i zwraca wynik, a polityka retencji logów i podstawa prawna są ustalane osobno.

Gdzie w tym wszystkim jest BEAM

Workflow i agenci nie są u nas osobnym produktem obok platformy. To litera A w BEAM, czyli etap AI Automation, który przychodzi po zbudowaniu platformy, a nie zamiast niej.

Ta kolejność nie jest handlowa, tylko architektoniczna. Agent, który ma odpowiadać na pytania o Twoje zamówienia, potrzebuje dostępu do realnego schematu danych i do własnego backendu. Na zamkniętym SaaS takiego dostępu nie ma i nie da się go dokupić żadną wtyczką.

Dlatego rozmowa o agentach prowadzi do rozmowy o platformie, a nie odwrotnie. Nie dlatego, że wolimy sprzedać większy projekt, tylko dlatego, że warstwa, po której agent ma chodzić, musi najpierw istnieć i być pod Twoją kontrolą.

Ten fundament budujemy na etapie Engineering: model danych, integracje, order flow i backend, do którego mamy pełny dostęp. W praktyce najczęściej na Medusie, bo daje własne moduły i własne endpointy admina, a nie tylko API do odczytu.

Jedno miejsce zamiast siedmiu zakładek

Praktyczna różnica nie polega na tym, że agent umie odpowiadać. Polega na tym, ile widzi. W typowym sklepie katalog jest w panelu, zamówienia w drugim systemie, stany w ERP, ceny kontraktowe w arkuszu, a feedy w narzędziu marketingowym. Żaden asystent nie połączy tych światów, bo nie ma do nich jednego wejścia.

BEAM jest tym wejściem. Platforma, którą wdrażamy, scala katalog, zamówienia, stany, cenniki, kanały sprzedaży i automatyzacje w jednym backendzie, do którego agent ma opisany dostęp. Dlatego pytanie „które produkty z zeszłego tygodnia nie mają jeszcze opisu po niemiecku i wisiały wczoraj na feedzie" ma w ogóle szansę na odpowiedź.

Do tego dochodzi warstwa, o której mało kto myśli przy AI: kontekst nietechniczny. Struktura firmy i to, kto o czym decyduje. Ustalenia z Blueprintu. Powody, dla których odrzuciliśmy jakiś wariant. Plan wejścia na kolejny rynek. Te rzeczy zwykle żyją w głowach i w mailach, a jeżeli agent ma podpowiadać sensownie, muszą być zapisane tam, gdzie sięga.

Dlatego u nas decyzje trafiają do repozytorium projektu razem z kodem, a nie do prezentacji. To ten sam materiał, z którego korzysta zespół przy kolejnej zmianie, i ten sam, do którego sięga agent. Nowa osoba w zespole i nowy agent wdrażają się z tego samego źródła.

Moduł, nie jednorazowa funkcja

Warstwę agentową budujemy jako moduł reużywalny u kolejnych klientów. Sam moduł, narzędzia, tryby uprawnień i zestaw testów zostają te same. Per klient różni się overlay: mapa jego schematu, manifest dostępu i lista pierwszych pytań, na które agent musi odpowiadać bezbłędnie.

To ma jeszcze jeden skutek, który widać dopiero po roku. Gdy dokładasz do platformy kolejną funkcję (livechat, zwroty, recenzje), a jest ona modułem w tym samym backendzie, agent odpytuje ją tą samą warstwą. Nie trzeba osobnej integracji z AI za każdym razem.

Kiedy agent nie ma sensu

Teraz uczciwa granica, bo bez niej cały tekst byłby ulotką. Przy małym katalogu i niskim wolumenie automatyzacja nie zwróci się nigdy, ponieważ koszt zbudowania i utrzymania reguł przewyższa czas, który te reguły zdejmują.

Trzysta produktów zmieniających się raz na kwartał opiszesz szybciej ręcznie, niż zbudujesz pod nie proces. Kilkanaście zamówień dziennie obsłuży jedna osoba bez żadnego agenta, a odpowiedź na pytanie o wstrzymane zamówienie znajdzie w panelu w dziesięć sekund.

Dlatego trzymamy jedną zasadę kwalifikacji: jeśli workflow nie oszczędza czasu, nie poprawia jakości albo nie wspiera sprzedaży, nie budujemy go. Mówimy to również wtedy, gdy klient przychodzi z gotowym budżetem na AI i konkretnym pomysłem.

Trzy sygnały, że próg jednak został przekroczony:

• Powtarzalność: to samo zadanie wraca co tydzień, w tej samej formie, na kilkuset pozycjach naraz.
• Wielokanałowość: te same dane trzeba wystawić w kilku miejscach, każde z innym zestawem wymagań i limitów.
• Koszt błędu: pomyłka w danych produktowych trafia od razu do kanału sprzedaży, więc kontrola jakości i tak musi być procesem, nie pamięcią jednej osoby.

Jeśli żaden z tych trzech nie występuje, lepszą inwestycją jest uporządkowanie danych produktowych. Ono i tak jest warunkiem wstępnym każdej automatyzacji, a przy okazji robi to samo dla widoczności w agentic commerce, gdzie kupujący coraz częściej wysyła po ofertę maszynę.

Agent AI prowadzący sklep nie wygląda jak film. Wygląda jak proces, który w poniedziałek rano domyka opisy 200 nowych produktów, grupuje 30 odrzuconych pozycji feedu po przyczynie i podsuwa gotową odpowiedź o paczce, zostawiając człowiekowi decyzje, których nie wolno oddać maszynie.

Reszta to inżynieria, która rozstrzyga, czy to narzędzie, czy ryzyko: dane pobierane zamiast zgadywanych, dwa tryby uprawnień, manifest dostępu i zabezpieczenia zapisane w kodzie, nie w prompcie. Tak to budujemy i tak radzimy do tego podchodzić, niezależnie od tego, kto Wam to ostatecznie zbuduje.