stripe ma w cli komendę pay. z poziomu terminala można wysłać pieniądze do innego biznesu, wskazując jego profil w stripe, czyli handle w stylu @nazwa albo identyfikator profilu. obie strony muszą mieć odpowiednią konfigurację: nadawca zasilony rachunek, a odbiorca podpięte miejsce odbioru środków. stripe przygotował też instrukcję dla agentów, która opisuje korzystanie z tej komendy i wymaga, żeby przed wysłaniem pokazać człowiekowi odbiorcę, kwotę, walutę i źródło pieniędzy, a przelew puścić dopiero po jego potwierdzeniu.
na pierwszy rzut oka to po prostu przelew, tylko bez klikania w dashboardzie. dla mnie ciekawsze jest to, gdzie ten przelew się pojawia: w tym samym środowisku, w którym agent pisze kod, odpala narzędzia i wykonuje zadania. zapłacenie komuś staje się kolejną dostępną operacją, obok uruchomienia testów czy wrzucenia pliku na serwer.
dotychczas agent mógł dojść najwyżej do momentu „potrzebuję płatnej usługi, wejdź tutaj, załóż konto i podepnij kartę”. teraz infrastruktura coraz wyraźniej idzie w kierunku „potrzebuję płatnej usługi, oto koszt i prośba o zgodę”. a docelowo, tam gdzie damy mu takie uprawnienia: „zmieściłem się w przyznanym budżecie, zadanie gotowe”.
i tutaj zaczyna się znacznie ciekawszy temat niż samo płacenie z terminala.
agent, który kupuje po drodze
jeśli agent ma wykonać zadanie i może kupować potrzebne do tego usługi, zmienia się sposób, w jaki możemy sprzedawać software.
wyobraźmy sobie, że zlecamy mu analizę kilkudziesięciu sklepów internetowych. musi pobrać strony, uruchomić przeglądarkę, odczytać część treści ze zdjęć i sprawdzić jakieś dane. nie wszystko musi robić sam. może skorzystać z wyspecjalizowanych usług, jeśli dostał zgodę i budżet na ich użycie. jedna pobierze dane, druga przetworzy dokument, trzecia udostępni przeglądarkę na czas zadania. my dostajemy raport, a po drodze kilka firm dostaje zapłatę za konkretny fragment pracy.
to przykładowy scenariusz, ale sam mechanizm już powstaje. w marcu 2026 stripe razem z tempo przedstawił machine payments protocol, w skrócie mpp, czyli otwarty standard programowego uzgadniania płatności między agentami i usługami. wygląda to mniej więcej tak:
- agent prosi usługę o zasób, na przykład wynik wywołania api albo sesję przeglądarki,
- usługa zamiast wyniku odpowiada kodem 402 i żądaniem zapłaty, w którym jest cena i sposób płatności,
- agent autoryzuje płatność i ponawia prośbę, dołączając dowód zapłaty powiązany z tym konkretnym żądaniem,
- usługa sprawdza dowód, oddaje zasób i dorzuca potwierdzenie, że płatność przeszła.
w protokole jest też coś, co uważam za ważniejsze od samego „zapłać i dostań”: obok jednorazowej opłaty są sesje, czyli rozliczanie na bieżąco według zużycia, z automatycznym zwrotem niewykorzystanej części depozytu. stripe pokazuje już przykłady płacenia za sesję przeglądarki, za pojedyncze wywołania api do przeszukiwania sieci, a nawet za wydrukowanie i wysłanie zwykłego listu. po stronie sprzedawcy taka płatność ląduje w stripe jak każda inna transakcja, z tymi samymi wypłatami, zwrotami i raportami.
stripe pay i taki zakup dostępu do api to różne mechanizmy. pierwszy dotyczy transferu pieniędzy między biznesami. drugi pozwala powiązać płatność z uzyskaniem konkretnej usługi. ale oba pasują do świata, w którym software uczestniczy również w wydawaniu pieniędzy.
agent2agent brzmi futurystycznie, ale pod spodem dalej ktoś komuś sprzedaje usługę
agent nie staje się nagle osobnym przedsiębiorcą. za nim stoi człowiek albo firma, ich pieniądze i ich uprawnienia. zresztą po drugiej stronie wcale nie musi być drugiego modelu ai. może być zwykłe api, które robi jedną rzecz bardzo dobrze. „agent do agenta” to w praktyce często „program klienta do programu dostawcy”, tylko z płatnością wbudowaną w samo zapytanie.
i moim zdaniem właśnie tutaj jest najciekawszy fragment dla ludzi budujących małe produkty. możemy mieć biznes, którego użytkownikami będą głównie inne programy. człowiek zdecyduje, że chce raport, analizę albo gotowy plik, a wybór części wykonawców zostawi agentowi. nasza usługa może zarobić, mimo że ten człowiek nigdy nie zobaczy naszego dashboardu. nie obejrzy onboardingu, nie doceni animacji na homepage i nie przeczyta, że jesteśmy all-in-one platformą, która rewolucjonizuje workflow. może nawet nie wiedzieć, że istniejemy xd
agent będzie musiał za to ustalić, co robimy, ile to kosztuje, jakie dane trzeba przesłać i co dokładnie dostanie w odpowiedzi. stripe rozwija pod ten sposób zakupów również discovery, czyli katalog, w którym agenci mogą znajdować usługi i poznawać dostępne sposoby korzystania z nich oraz płacenia. w dokumentacji dla dostawców software’u opisuje też programowe zakładanie kont, uzyskiwanie danych dostępowych i zarządzanie billingiem, tak żeby agent mógł przejść całą drogę od „potrzebuję bazy danych” do działających kluczy bez wypełniania formularzy.
czyli samo wystawienie api może nie wystarczyć. ktoś jeszcze musi umieć je znaleźć i bezpiecznie kupić.
koszt poprawnie wykonanego zadania
to jest miejsce na zupełnie nową konkurencję. załóżmy, że mamy trzy usługi do wyciągania tabel z pdfów. pierwsza jest najtańsza, ale często zwraca błędne dane. druga jest droższa, ale działa przewidywalnie. trzecia wymaga rozmowy z handlowcem, żeby poznać cenę.
jeśli agent ma skończyć zadanie teraz, trzecia może w ogóle wypaść z rozważań, bo nie ma z kim umówić się na demo w środku wykonywania zadania. pierwsza też nie musi wygrać. jeżeli po jej użyciu trzeba trzy razy poprawiać wynik, ponownie przetwarzać plik i zużywać kolejne tokeny, oszczędność na samym wywołaniu szybko znika.
spodziewam się więc, że ważniejszy stanie się koszt poprawnie wykonanego zadania, razem z opóźnieniami, poprawkami i ryzykiem błędu, a nie cena pojedynczego wywołania z cennika.
oczywiście agent nie będzie magicznie znał jakości wszystkich dostawców. ktoś musi ją zmierzyć, udokumentować albo zbudować historię udanych zleceń. rekomendacje, domyślne integracje i dostęp do dystrybucji nadal mogą decydować o tym, kto dostanie zamówienie. „będę miał najlepsze api, więc agenci sami mnie znajdą” brzmi podejrzanie podobnie do „zrobię najlepszą aplikację, więc marketing zrobi się sam”.
a co z abonamentami?
widzę tutaj presję na sprzedawanie mniejszych jednostek pracy. człowiek kupuje narzędzie za 29 dolarów miesięcznie, bo przewiduje, że będzie go potrzebował. agent wykonujący jedno zadanie może potrzebować jednej konwersji pliku. kupowanie całego abonamentu na tę okazję jest dla niego dodatkowym kosztem i zobowiązaniem, które musi przed kimś uzasadnić.
nie oznacza to końca subskrypcji. przy regularnym użyciu pakiet albo umowa z jednym dostawcą mogą być znacznie sensowniejsze, a sam mpp przewiduje zresztą również płatności cykliczne. ale pojawia się szansa na obsługiwanie zakupów, które wcześniej były za małe, żeby człowiek chciał przechodzić przez cały proces rejestracji, wyboru planu i wpisywania karty.
trzeba tylko policzyć, czy po opłatach za płatność, infrastrukturę i obsługę błędów zostaje z tego biznes. możliwość pobrania grosza nie oznacza jeszcze, że opłaca się go pobierać.
najtrudniejszy może się okazać moment po zapłaceniu
co jeśli usługa pobierze pieniądze i nie odda wyniku? co jeśli agent ponowi żądanie, bo nie dostał odpowiedzi, a pierwsze wykonanie jednak się udało? co jeśli wyda cały budżet na poprawianie błędów poprzedniego narzędzia?
sam opis „agent może wydać do 100 zł” jest mało satysfakcjonujący, jeśli po godzinie mamy 100 zł mniej i siedem niedokończonych prób. przy płacącym software’ze potrzebujemy jasnych limitów, historii transakcji i sposobu ustalenia, czy dane zlecenie już zostało opłacone. potrzebujemy też wiedzieć, co właściwie kupiliśmy i czy to zostało dostarczone.
ciekawe jest to, jak stripe pisze o tym na swoim blogu dla developerów. w przykładzie z lodówką, która sama zamawia brakujące zakupy, agent nie dostaje numeru karty, tylko ograniczone uprawnienie do zapłaty: limit na jedno zamówienie, limit tygodniowy, listę dozwolonych sklepów i kategorii. ewentualna wirtualna karta ma ustalony limit i wygasa po kilku godzinach. kluczowe jest tam też to, że o tym, czy płatność jest dozwolona, nie decyduje model, tylko zwykłe reguły, które ktoś wcześniej przejrzał i zatwierdził. wynik ma być jeden z trzech: zatwierdzone, wymaga zgody domownika albo odrzucone. a jeśli koszyk przekracza limit, agent ma szukać zamiennika albo zapytać człowieka, zamiast po cichu zaakceptować wyższą kwotę.
w innym wpisie stripe opisuje reguły zatwierdzania dla kluczy używanych przez agentów: zwroty poniżej 50 dolarów przechodzą automatycznie, powyżej 500 wymagają podpisu kogoś z zespołu, nikt, ani człowiek, ani agent, nie może domyślnie zatwierdzić własnej prośby, a niezatwierdzone prośby wygasają po 14 dniach. do tego ponawianie płatności ma być idempotentne, czyli drugie wysłanie tego samego zlecenia nie może obciążyć nas drugi raz.
to nie są fajerwerki. to jest nudna księgowość i kontrola dostępu, tylko przeniesiona do świata, w którym zlecenie wysyła program. dlatego spodziewam się biznesów również wokół samej kontroli tych wydatków: rozliczania kosztu zadania, wykrywania podwójnych obciążeń, wyboru dostawców i weryfikowania efektów.
płatność odblokowuje handel. dopiero reszta sprawia, że chcemy go powtarzać.
jak spojrzałbym na swój produkt oczami agenta
dla mnie wniosek ze stripe pay jest taki, że warto zacząć patrzeć na własny produkt również z perspektywy programu, który dostał zadanie i pieniądze na jego wykonanie. zadałbym sobie cztery pytania:
- czy potrafi ustalić, co sprzedajemy, bez czytania marketingowych haseł i oglądania wideo na stronie głównej?
- czy zna cenę przed zakupem, a nie dopiero po rozmowie z handlowcem albo założeniu konta?
- czy może kupić dokładnie tyle, ile potrzebuje, czyli jedno wywołanie albo jedną sesję, a nie od razu roczny plan?
- czy potrafi sprawdzić, że dostał wynik, i co się stanie, jeśli zapyta drugi raz o to samo?
jeśli na któreś odpowiadamy „to zależy” albo „napisz do nas”, to dla człowieka może być jeszcze w porządku. dla agenta, który ma budżet i termin, często oznacza po prostu przejście do następnego dostawcy na liście.
bo możemy dalej dopracowywać stronę pod człowieka, który porównuje trzy zakładki. a część przyszłych zamówień może przychodzić od software’u, który nigdy tej strony nie otworzy.