Platforma z agentami AI dla uczestników programu Michała Połucha

Kto to był i co go bolało

Michał Połuch prowadzi program edukacyjny sprzedawany w formie produktu cyfrowego. Uczestnicy mieli dostać do ręki zestaw agentów AI wspierających konkretne zadania z programu, na przykład generator pomysłów na bonusy. Do tej pory takie rzeczy żyły w rozproszeniu i za każdym razem ktoś musiał ręcznie ogarnąć dostęp.

Pierwszym wyzwaniem była spójna całość. Chat z agentami, konta użytkowników, subskrypcje i obsługa po sprzedaży musiały być jedną aplikacją, a nie zbiorem narzędzi posklejanych linkami. Uczestnik ma się zalogować w jednym miejscu i tam znaleźć wszystko.

Drugie: kontrola dostępu. Agenci kosztują przy każdym zapytaniu, więc dostęp musiał zależeć od aktywnej subskrypcji, a korzystanie mieć dzienny limit. Do tego komunikaty o wyczerpaniu limitu albo o braku aktywnego dostępu muszą być zrozumiałe, bo inaczej każdy taki przypadek wraca jako zgłoszenie do obsługi.

Trzecie: droga od zakupu do działającego konta miała nie wymagać żadnego kliknięcia po stronie właściciela programu. Czwarte: prompty i modele poszczególnych agentów miały dać się zmieniać bez wypuszczania nowej wersji aplikacji, a awaria zewnętrznej usługi konfiguracyjnej nie mogła oznaczać, że platforma przestaje działać.

Co zrobiliśmy

Aplikację zbudowaliśmy w Next.js, a warstwę kont, bazy i uprawnień oparliśmy na Supabase - łącznie z regułami dostępu na poziomie wierszy, żeby żaden użytkownik nie sięgnął do cudzych rozmów. Powstały moduły logowania i rejestracji, ekran konta z profilem oraz interfejs czatu obsługujący wielu agentów naraz.

Zanim jakiekolwiek zapytanie pójdzie do modelu, przechodzi przez dwie kontrole: czy subskrypcja jest aktywna i czy dzienny limit nie został wyczerpany. Sprawdzenie dzieje się po stronie serwera, więc nie da się go obejść z poziomu przeglądarki.

Odpowiedzi generujemy przez OpenRouter, ze strumieniowaniem, żeby tekst pojawiał się na bieżąco, a nie po kilkunastu sekundach ciszy. Prompt i model dla każdego agenta trzymamy w Agenta Cloud, dzięki czemu zmiana zachowania agenta to zmiana konfiguracji, a nie wdrożenie. Na wypadek niedostępności tej usługi wpięliśmy zachowanie awaryjne: platforma używa ostatniej znanej konfiguracji zamiast odmawiać obsługi.

Sprzedaż spięliśmy webhookiem z Publigo. Zdarzenie zakupu jest podpisane i weryfikowane, a po sprawdzeniu podpisu system sam zakłada konto i włącza subskrypcję. Historia rozmów jest zapisywana, więc uczestnik wraca do swojego wątku, a nie zaczyna od zera. Na koniec dołożyliśmy automatyczną odpowiedź na wiadomości przychodzące poza godzinami pracy, wysyłaną przez Resend, z ograniczeniem częstotliwości, żeby nikt nie dostał tej samej wiadomości pięć razy.

Jak to działa dzisiaj

Prace zajęły około tygodnia i podzieliliśmy je na cztery etapy: mapowanie procesu zakupu i dostępu wraz z modelem danych, budowa aplikacji i logowania, integracje z modelami oraz automatyzacje sprzedażowe, a na końcu stabilizacja i wdrożenie produkcyjne.

Dzisiaj uczestnik kupuje program i po chwili ma gotowe konto, bez kontaktu z obsługą. Loguje się, wybiera agenta, prowadzi rozmowę, a odpowiedzi płyną na bieżąco. Wątki zostają zapisane. Limity dzienne pilnują kosztów po cichu i odzywają się tylko wtedy, gdy ktoś naprawdę dobije do granicy. Właściciel programu zmienia prompty i modele agentów z poziomu konfiguracji, kiedy uzna, że któryś agent powinien odpowiadać inaczej.

Co z tego wyszło

Powstała jedna platforma zamiast zestawu luźnych narzędzi. Aktywacja dostępu po zakupie dzieje się sama, więc obsługa nie jest wąskim gardłem sprzedaży. Dostęp do agentów jest kontrolowany subskrypcją i dziennym limitem, co trzyma koszty modeli w ryzach. Konfiguracja agentów jest odłączona od kodu, a awaria usługi konfiguracyjnej nie zatrzymuje platformy.

Co zrobilibyśmy inaczej

Najbardziej wrażliwym punktem okazał się webhook sprzedażowy. To jedyne miejsce, w którym zewnętrzny system może utworzyć konto, więc weryfikacja podpisu i odporność na powtórzone zdarzenia były obowiązkowe od pierwszej linijki. Zrobiliśmy to dobrze, ale testowaliśmy dopiero pod koniec, na żywym procesie zakupowym. Przy kolejnym wdrożeniu przygotowujemy sobie sposób odtwarzania takich zdarzeń w środowisku testowym na samym początku.

Nie doceniliśmy też zachowania awaryjnego przy zewnętrznej konfiguracji agentów. Pierwsza wersja zakładała, że usługa jest dostępna zawsze. Wystarczyła jedna chwila niedostępności, żeby stało się jasne, że domyślną odpowiedzią systemu ma być ostatnia znana konfiguracja, a nie komunikat o błędzie.