Jak zbudować agenta AI, który płaci — architektura i stack

Budowa agenta, który samodzielnie wydaje pieniądze, sprowadza większość zespołów na manowce już na starcie: zaczynają od integracji płatności, a kończą z modelem, który ma zbyt dużą władzę nad firmową kartą. Odwróćmy kolejność i pokażmy architekturę, która jest bezpieczna z założenia.

W skrócie: Agenta płacącego buduje się przez rozdzielenie dwóch warstw. Warstwa decyzji (model) wybiera, co kupić. Warstwa rozliczenia (dostawca płatności plus mandat i limity) realizuje transakcję i deterministycznie egzekwuje granice. Nie buduj szyny płatniczej od zera — użyj dostawcy (Stripe, PayPal) lub protokołu (x402, AP2, ACP) — a komponenty projektuj wymiennie, żeby móc zmienić dostawcę bez przepisywania logiki agenta.

Dlaczego decyzja i płatność to dwie osobne warstwy?

To jest fundament całej architektury, więc zacznijmy od niego. Model językowy jest probabilistyczny: czasem się myli, czasem da się go zmanipulować spreparowanym promptem na stronie sprzedawcy (tzw. prompt injection), a jego rozumowanie jest trudne do przewidzenia co do grosza. Płatność musi być odwrotnością tego — deterministyczna, audytowalna i ograniczona twardymi regułami.

Jeśli pozwolisz modelowi bezpośrednio wywoływać API płatnicze z pełnym kluczem, jedyną barierą między halucynacją a obciążeniem karty staje się jakość promptu. To za mało. Dlatego model nie dotyka pieniędzy — on jedynie zgłasza intencję zakupu. Osobny, napisany klasycznym kodem komponent sprawdza tę intencję wobec reguł i dopiero wtedy uruchamia płatność albo ją odrzuca.

Praktyczna konsekwencja: nawet idealnie udany atak na model nie przebije limitu, bo limit żyje poza modelem. To samo rozdzielenie ról widać w projektach protokołów agentowych — AP2 wprowadza koncepcję podpisanych mandatów właśnie po to, by oddzielić to, czego użytkownik chce, od tego, co agent faktycznie może wykonać.

Z jakich komponentów składa się stack agenta płacącego?

Architekturę warto rozrysować jako przepływ od intencji do rozliczenia. Każdy komponent ma jedną odpowiedzialność:

• Model / agent (warstwa decyzji) — analizuje zadanie użytkownika, wyszukuje produkty, porównuje oferty i formułuje propozycję zakupu. Wyjściem nie jest płatność, lecz ustrukturyzowana intencja: co, u kogo, za ile, w jakiej walucie.
• Warstwa mandatu i limitów — deterministyczna brama. Sprawdza, czy intencja mieści się w mandacie nadanym przez użytkownika: kwota jednostkowa, budżet dzienny i miesięczny, dozwolone kategorie sprzedawców, lista wykluczeń, wymóg potwierdzenia powyżej progu.
• Integracja z dostawcą lub protokołem — most do realnych pieniędzy: Stripe, PayPal albo protokół agentowy (x402, AP2, ACP). Tu powstaje obciążenie.
• Wirtualne karty / issuing — opcjonalna, ale mocna warstwa. Karta jednorazowa lub z twardym limitem wystawiana per agent, per zadanie albo per sprzedawca.
• Webhooki do rozliczeń — asynchroniczne potwierdzenia od dostawcy: udało się, odrzucono, zwrot, spór. To one zamykają pętlę, a nie odpowiedź modelu.
• Log audytowy — niezmienialny zapis: jaka intencja, jaka decyzja bramy, jaki wynik płatności, z jakim identyfikatorem mandatu. Bez niego nie odtworzysz, dlaczego agent coś kupił.

Zwróć uwagę, że tylko jeden z tych komponentów to model. Reszta to klasyczna, testowalna inżynieria — i to dobrze.

Jak zbudować warstwę mandatu i limitów?

Mandat to cyfrowe pełnomocnictwo: zbiór reguł, na które zgodził się użytkownik, zanim agent ruszył do działania. Dobra warstwa mandatu działa jak lista kontrolna uruchamiana przy każdej próbie płatności, niezależnie od tego, co „uznał” model.

Minimalny zestaw reguł, które warto egzekwować:

Reguła	Przykład	Po co
Limit pojedynczej transakcji	maks. 200 zł na zakup	Blokuje kosztowny błąd jednostkowy
Budżet okresowy	1000 zł na miesiąc	Ogranicza skumulowaną szkodę
Dozwolone kategorie	tylko hosting i API, bez gotówki	Trzyma agenta w jego roli
Lista sprzedawców	allowlista lub blocklista	Eliminuje nieznane podmioty
Próg potwierdzenia	powyżej 500 zł pytaj człowieka	Zostawia kontrolę przy ryzyku
Wygasanie mandatu	ważny 24 godziny	Domyka okno nadużycia

Kluczowa zasada projektowa: ta warstwa musi być deterministyczna i napisana zwykłym kodem, nie promptem. Limit sprawdzony przez model to nie limit, tylko sugestia. Więcej o konstruowaniu samych reguł i ich wygasaniu znajdziesz w osobnym omówieniu mandatów i progów dla agenta.

Dostawca, protokół czy wirtualna karta — co wybrać?

To nie jest wybór „albo–albo”; te warstwy często się uzupełniają. Różnią się natomiast tym, gdzie leży granica zaufania.

Dostawca płatności (Stripe, PayPal). Najszybsza droga do działającego agenta. Stripe udostępnia narzędzia kierowane wprost do agentów — model dostaje wąski zestaw funkcji zamiast surowego klucza API, a Ty kontrolujesz, co wolno wywołać. Jak to spiąć w praktyce, rozkłada na czynniki przewodnik po Stripe Agent Toolkit.

Protokół agentowy (x402, AP2, ACP). Warstwa standaryzująca samą rozmowę o płatności między agentem a sprzedawcą. x402 ożywia kod HTTP 402 „Payment Required”, tak by usługa mogła zażądać zapłaty w odpowiedzi na żądanie, a agent zapłacił programowo. AP2 skupia się na podpisanych mandatach i weryfikowalnej intencji użytkownika. Protokoły są wartościowe, gdy zależy Ci na interoperacyjności — agent i sprzedawca nie muszą znać się nawzajem, jeśli oba mówią tym samym językiem.

Wirtualne karty (issuing). Najbardziej uniwersalny mechanizm egzekwowania limitu, bo działa wszędzie, gdzie przyjmują kartę — także u sprzedawców, którzy o agentach nigdy nie słyszeli. Wystawiasz kartę z twardym limitem i zawężoną kategorią, a kontrola dzieje się po stronie wydawcy karty, nie w Twoim kodzie. To świetne uzupełnienie: protokół albo dostawca obsługuje przepływ, a karta stanowi ostatni, niezależny bezpiecznik.

Reguła kciuka: zacznij od dostawcy, dołóż issuing dla twardego limitu, a po protokoły sięgaj, gdy potrzebujesz dogadać się ze światem poza własnym backendem.

Po co webhooki i log audytowy, skoro płatność „się udała”?

Bo odpowiedź modelu nie jest dowodem rozliczenia. Płatności bywają asynchroniczne: autoryzacja, przechwycenie, zwrot i spór mogą nastąpić minuty albo dni po akcji agenta. Stan transakcji utrzymujesz na podstawie webhooków od dostawcy, a nie tego, co agent „myśli”, że się stało. To one mówią, czy obciążenie weszło, czy przyszedł refund i czy sprzedawca nie zgłosił sporu.

Log audytowy to z kolei warstwa, bez której nie przejdziesz żadnego poważnego przeglądu bezpieczeństwa. Dla każdej płatności zapisuj: identyfikator mandatu, pełną intencję modelu, decyzję bramy limitów wraz z powodem, wynik od dostawcy i znacznik czasu. Dzięki temu na pytanie „dlaczego agent wydał te pieniądze?” odpowiadasz faktem, a nie rekonstrukcją. Jak poskładać odbiór zdarzeń, idempotentność i uzgadnianie stanu, opisuje praktyka webhooków i rozliczeń płatności agentowych.

Jakich błędów architektonicznych unikać?

Kilka pułapek powtarza się w niemal każdym pierwszym projekcie:

• Budowa szyny płatniczej od zera. Zgodność z PCI DSS, obsługa sporów i sieci kartowych to dziedziny, w których dostawcy mają lata przewagi. Twoja przewaga jest gdzie indziej — w logice agenta.
• Klucz API w rękach modelu. Pełny klucz to pełna władza. Daj agentowi wąski zestaw narzędzi i bramę limitów.
• Limit jako prompt. „Nie wydawaj więcej niż 200 zł” w instrukcji systemowej nie jest zabezpieczeniem, tylko prośbą.
• Twarde przywiązanie do jednego dostawcy. Schowaj realizację płatności za własnym interfejsem (port). Wtedy zmiana Stripe na PayPal albo dołożenie protokołu nie rusza warstwy decyzji.
• Brak człowieka w pętli przy ryzyku. Próg potwierdzenia dla większych kwot to tani bezpiecznik o dużej wartości.

Projektowanie wymienne to nie przedwczesna optymalizacja, lecz uznanie, że krajobraz protokołów agentowych dopiero się stabilizuje. Jeśli warstwa decyzji nie wie, czy pod spodem jest Stripe, karta wirtualna czy x402, możesz ewoluować stack bez przepisywania mózgu agenta.

Od czego zacząć budowę?

Najpierw narysuj przepływ intencja → mandat → realizacja → webhook → log i nazwij, kto za co odpowiada. Potem zbuduj deterministyczną bramę limitów — to ona, a nie model, jest sercem bezpieczeństwa. Dopiero na końcu podłącz dostawcę przez wąski zestaw narzędzi i dołóż wirtualną kartę jako niezależny bezpiecznik. Szerszy kontekst całego nurtu i to, jak te elementy układają się w rynek, znajdziesz we wprowadzeniu do agentic commerce.

Agent, który płaci dobrze, to nie sprytniejszy model. To architektura, w której model wybiera, a deterministyczny kod pilnuje, żeby ten wybór nigdy nie wyszedł poza granice nadane przez człowieka.