Agent AI od PoC do produkcji: spisany proces, dostęp do systemów i decyzja po testach

Wiedzę plemienną i tak trzeba zdobyć od ludzi. Znajdą się osoby, które powiedzą, że procedury powinny być aktualne, ale tak nie jest.

Kryteria mogą się potem zmieniać i będą subiektywne, ale pokazują, do czego zespół zmierza.

Nie. Taki wynik pokazuje, nad czym jeszcze trzeba popracować i co przemyśleć, żeby rozwiązanie spełniło oczekiwania.

Łukasz Kałużny: Chodzi o to, że do tego procesu trzeba czasami ciutkę inaczej podejść, żeby miało to sens. Proces i spisana procedura czy instrukcja to jedno, a to, jak życie jest potem obsługiwane, to druga sprawa.

Mikołaj Szczerbicki: Życie pisze swoje scenariusze.

Łukasz Kałużny: Dokładnie. Większość problemów to dostęp do systemów. To jest zabicie tego eksperymentu, tej inicjatywy. Dlaczego mówię, że to jest sukces? Najważniejszy punkt: tydzień przygotowań i zebrania danych oszczędzi nam dużej ilości pracy, która w ogóle nie powinna się odbyć na zasadzie debugowania.

Mikołaj Szczerbicki: Cześć! Witajcie w Powered by Protopia. Nazywam się Mikołaj Szczerbicki i dzisiaj jest ze mną Łukasz Kałużny.

Łukasz Kałużny: Dzień dobry wszystkim.

Mikołaj Szczerbicki: Łukasz, dzisiaj porozmawiamy o tym, jak budować agenta AI w organizacji, żeby ta inicjatywa zakończyła się sukcesem. Powiem Ci szczerze, że bardzo się cieszę, że mogę porozmawiać o tym z Tobą, bo wiem, jak duże masz doświadczenie. Jest ono prosto z placu boju, a nie oparte na slajdach marketingowych. Powiedz mi, dlaczego akurat dzisiaj poruszamy ten temat?

Łukasz Kałużny: Powody są dwa. Budujemy dużo takich PoC-ów, a na rynku jest teraz moment, w którym wszyscy eksperymentujemy, jak coś wyciągnąć z LLM-ów, z generative AI. Drugim zapalnikiem była pewna wiadomość od klienta. Cytując: prompt jest bardzo precyzyjny, ale odpowiedzi różnią się merytorycznie. Brzmi znajomo, kiedy coś wklepujemy w czat. Chodzi o to, że do tego procesu trzeba czasami ciutkę inaczej podejść, żeby miało to sens, i inaczej wykorzystać wiedzę biznesu, żeby PoC się udał, niż tylko wrzucić to w ChatGPT, Copilota, Gemini czy Claude'a.

Mikołaj Szczerbicki: Dobrze, Łukasz. Skoro używamy słowa „proces”, to każdy proces ma swoje etapy. Jak to się mówi, first things first, zacznijmy od początku. Co według Ciebie powinno być krokiem numer jeden?

Łukasz Kałużny: Jeżeli budujemy PoC-e z generative AI, chcemy dojść do działającego rozwiązania. Trzeba też powiedzieć, że obok proof of concept często mówimy proof of value, bo koncepcję wypadałoby sprawdzić, zanim zainwestujemy w budowę pełnoprawnego rozwiązania. W organizacji jest bardzo dużo niewiadomych: czy to zadziała, czy nie, czy będzie działało powtarzalnie.

Mikołaj Szczerbicki: Z doświadczenia podejrzewam, że to zależy też od tego, jak zdefiniujemy sukces, ale do tego pewnie dojdziemy.

Łukasz Kałużny: Tak. Zanim w ogóle weźmiemy się za budowę rozwiązania, robimy PoC-a. A żeby zrobić PoC-a, najpierw potrzebujemy wiedzieć, jak wygląda proces, który chcemy zautomatyzować. To jest clou problemu. Powinniśmy dokładnie wiedzieć, co teraz jest robione ręcznie i jak to wygląda w systemach.

Mikołaj Szczerbicki: Dobrze, to jak to zweryfikować?

Łukasz Kałużny: Nasze podejście z klientami jest takie, żeby osobę, która ma wiedzę, posadzić do spisania swoich kroków po prostu w Wordzie. Dosłownie. Największy sukces mamy wtedy, kiedy taka osoba usiądzie i dokładnie spisze albo nagra ekran: co robi i dlaczego. Czyli spisujemy proces biznesowy z tak zwanej wiedzy plemiennej. Bo nie oszukujmy się, większość z Was, Ty, Mikołaj, też, wie z doświadczenia, jak to wygląda w życiu: proces i spisana procedura czy instrukcja to jedno, a to, jak życie jest potem obsługiwane, to druga sprawa.

Mikołaj Szczerbicki: Życie pisze swoje scenariusze.

Łukasz Kałużny: Dokładnie. Bardzo często instrukcja nie jest potem aktualizowana, jeżeli zmieniły się warunki biznesowe, konfiguracja systemu albo nasze podejście. Dlatego pierwszym krokiem, i to daje największy sukces, jest spisanie wiedzy plemiennej od ludzi, którzy tę pracę wykonują. Czasami wystarczy dwóch pracowników, dwóch ekspertów, którzy spiszą, co robią w systemie biznesowym. U jednego z klientów ubezpieczeniowych spisano na przykład: biorę dane z systemu X, potem robię research w internecie, kim naprawdę jest ten klient i co możemy mu zaproponować, a potem próbuję do tego dopasować ofertę i robię analizę. Taki Word jest świetnym punktem wyjścia do planowania, bo widać, co faktycznie się dzieje i co robił człowiek.

Mikołaj Szczerbicki: Dobrze. Jeżeli dobrze zrozumiałem, może to być jedna osoba, kilka osób albo warsztat biznesowy. Chodzi o to, żeby to, co chcemy zautomatyzować, przełożyć na papier: opisać, jak obecnie funkcjonuje i jakie mamy oczekiwania. A co w sytuacji, o której wspomniałeś: procedury nie są opisane, dokumentacji nie ma albo jest stara, czyli zostaje wiedza plemienna?

Łukasz Kałużny: Tę wiedzę plemienną po prostu trzeba zdobyć. Znajdą się ludzie, którzy powiedzą, że przecież procedury powinny być aktualne, ale tak nie jest. Przestańmy się oszukiwać w tym miejscu. Proces też nie zawsze jest intuicyjny. Dobrze pokazuje to prawo Conwaya: proces odzwierciedla strukturę komunikacyjną firmy, a nie logikę, którą powinien mieć. Być może to okazja, żeby zastanowić się, czy procesu nie warto uprościć i wysprzątać. Ale to już insight nie na ten odcinek.

Mikołaj Szczerbicki: Bardzo mnie tym zaciekawiłeś, bo zastanawiam się, jak często organizacje faktycznie biorą to pod uwagę. Jak często budowa jednego rozwiązania pociąga za sobą zmiany organizacyjne, czasem też zmiany kultury, i te zmiany są wdrażane? Skoro jednak to nie temat dzisiejszego odcinka, przejdźmy dalej. Jeżeli mamy wszystko spisane, co robimy dalej?

Łukasz Kałużny: Kolejna rzecz to budowa oczekiwań. Wspomniałem o Copilocie i Gemini. Chodzi o to, żeby osobom nietechnicznym dać możliwość samodzielnego zbudowania oczekiwań, na przykład co do tego, jak zachowują się agenci, i miejsce do eksperymentowania, o którym mówiliśmy już w poprzednich odcinkach. Ważne jest to, żeby zamiast Copilotów i ChatGPT użyć playgroundów, z których potem sami będziemy korzystać przy budowie.

Mikołaj Szczerbicki: Łukasz, bardzo Cię proszę, rozwiń temat playgroundu, bo zabrzmiało to dosyć enigmatycznie.

Łukasz Kałużny: Każda z tych usług, a my najczęściej pracujemy z Azure, daje miejsce podobne do czatu, tylko z dostępem do gołego modelu językowego, który potem integrujemy w naszych agentach i aplikacjach. I to jest istotne: taki model zachowuje się zupełnie inaczej niż piękny, wybajerowany ChatGPT, który działa w trybie agentowym. Chodzi o to, żeby zobaczyć, jak zachowuje się podstawowy klocek Lego, z którego będziemy budować. Na przykład wyszukiwanie w internecie działa trochę inaczej w OpenAI hostowanym dla Ciebie na Azure. Bing Search, który jest pod spodem, zachowuje się inaczej niż to, co zobaczymy w publicznie dostępnym ChatGPT dla konsumentów.

Jeżeli osoby z biznesu chcą coś potestować, powinny dostać dostęp do takiego playgroundu, bo wtedy zbudują odpowiednie oczekiwania. Tak jak z promptem, o którym mówiłem na początku: zobaczą, jak to faktycznie działa. To buduje zaufanie, a po drugiej stronie powstają realistyczne oczekiwania. Dlatego nie mówię, że powinniśmy blokować te narzędzia i ich nie dawać. Trzeba dać to, z czego będziemy budować.

Mikołaj Szczerbicki: Playground jest więc naprawdę istotnym miejscem, żebyśmy nie mieli fałszywego obrazu tego, jak nasze narzędzie będzie działać. Czyli mamy teraz etap testowania.

Łukasz Kałużny: To testowanie przed faktycznym proof of conceptem. Jeszcze się bawimy i odkrywamy.

Mikołaj Szczerbicki: Dobrze, to jak przejść stąd do następnego kroku?

Łukasz Kałużny: Kiedy już potestowaliśmy, mamy oczekiwania i wiemy, co chcemy osiągnąć, przechodzimy do najgorszej fazy, czyli analizy. Dlaczego najgorszej? W większości naszych PoC-ów, proof of value, nie mamy problemu z automatyzacją agentem ani z zachowaniem agenta. Większość problemów to dostęp do systemów. Kiedy już wiemy, co będziemy robić i jakie to są ekrany w systemie, ktoś musi wykonać mrówczą pracę: dowiedzieć się, skąd pozyskać potrzebne dane, z jakiego systemu, jak uzyskać do niego dostęp, czy ma API, a jeżeli nie ma, to czy da się to zautomatyzować przez przeglądarkę albo czy możemy dostać się do bazy danych i czy to będzie w porządku.

To jest inwentaryzacja w ramach procesu: jak będziemy pobierać dane z systemów, które automatyzujemy. Nie oszukujmy się, teraz najwięcej przypadków to pobranie danych i zrobienie czegoś na ich podstawie, a dalej, trochę jak wcześniej w RPA, czyli Robotic Process Automation, wrzucenie czegoś z powrotem do innego systemu albo wywołanie API. Pierwsze pytanie brzmi więc: czy mogę dostać się do tych danych, systemów i akcji?

Mikołaj Szczerbicki: Zwrócę się tutaj do osób, które nas oglądają. Mieliśmy już kilka odcinków o API Management i o tym, że API jest sercem platformy, która obsługuje agentów. Dlatego wiemy, że integracja to jeden z kluczowych elementów.

Łukasz Kałużny: Inaczej: po spisaniu procesu, tego, co robimy, to jest 80% sukcesu, a nawet 80% pracy już faktycznie technicznej. I to jest integracja. To może być zaskakujące. Dlatego podchodzę do tego tak, że budowanie robotów, nazwijmy je agentami, to bardzo mocno praca programistyczna. To nie jest data science, tylko w większości przypadków żmudna robota integracyjna, żeby wszystko dostarczać jak należy.

Patrzę jeszcze na notatki. Kolejnym problemem jest to, jak bardzo agent jest autonomiczny. Co go uruchamia: mail, który wpada na skrzynkę, zdarzenie, a może człowiek, który klika? Agenci się nie domyślą, coś musi wyzwolić ich pracę. Trzeba ustalić, co będzie ją wyzwalać. To pierwsza rzecz. Druga, która z tego wynika: czy mamy human in the loop? W którym momencie wchodzi człowiek, w którym akceptuje albo wykorzystuje pracę agenta? Na to trzeba sobie odpowiedzieć od razu na początku.

Mikołaj Szczerbicki: Łukasz, to dla mnie istotne, bo widzę na rynku bardzo różne opinie na ten temat. Powiedz nam jasno, czy human in the loop, czyli obecność człowieka w procesie, jest wymagana za każdym razem, czy to już ten magiczny moment, kiedy nie jest potrzebna? Osobiście uważam, że human touch powinien być, czyli człowiek powinien cały czas znajdować się w procesie. To chyba jeszcze nie ten moment, kiedy możemy aż tak zaufać agentom.

Łukasz Kałużny: Powiem, jakie są elementy. Weźmy draftowanie, czyli przygotowanie odpowiedzi do klienta.

Mikołaj Szczerbicki: No właśnie, na konkretnych przykładach.

Łukasz Kałużny: Przygotowanie odpowiedzi do klienta. Przychodzi reklamacja albo zapytanie od klienta, agent przemiela wszystko, przygotowuje uzasadnienie i odpowiedź. Człowiek na sam koniec to sprawdza i ocenia, czy jest w porządku. To jeden z takich elementów. W automatyzacji skracamy cały czas dostarczenia, ale niech człowiek sprawdzi to, co ma wyjść do klienta, zanim zostanie wysłane. Być może nic nie zmieni, po prostu kliknie „wyślij” i to też będzie w porządku. W innych przypadkach, jak w PoC-u, o którym wspominałem na początku, który zbierał dane i przygotowywał analizę, człowiek dostaje gotowy raport ze wszystkimi źródłami i sam musi zweryfikować, czy jest w porządku.

Mikołaj Szczerbicki: Dobrze, a powiedz mi jeszcze jedno. Chcielibyśmy, żeby procesy były jak najbardziej zautomatyzowane. Jak podjąć dobrą decyzję, w którym miejscu procesu powinien znaleźć się człowiek?

Łukasz Kałużny: Potrzebne są jasne reguły. Inaczej: trzeba zrobić macierz akceptacji i wyznaczyć, kiedy coś może być zrobione automatycznie, a kiedy nie. W jednym z przypadków agent wyszukiwał coś w internecie i na tej podstawie proponował wycenę. Wprowadziliśmy tam dodatkowego agenta sędziego, nazywał się Judge, który sprawdzał screenshoty stron. Brał źródła, robił zrzuty stron i jeżeli podstawowe informacje na stronach się zgadzały, przekazywał dalej, że jest taka cena, a na koniec trafiało to do człowieka. Dlatego często mówię: na końcu coś zaakceptuj. Zauważ, Mikołaj, że ciągle mówię „na końcu zaakceptuj” i w wielu przypadkach to będzie w porządku.

Weźmy z kolei naszą firmę i część z otwartymi szkoleniami w marce Patoarchitekci. W obsłudze posprzedażowej, kiedy wpada zakup otwartego szkolenia, agent zaprasza uczestników, dodaje ich do szkolenia i tak dalej. Tam w ogóle nie ma człowieka, bo nawet jeżeli wystąpi problem, jest on bardzo mały i nie szkodzi ani reputacyjnie, ani finansowo. Trzeba więc popatrzeć na to także z drugiej strony.

Jest jeszcze rzecz, która nie jest naszą specjalizacją i zawsze zostawiamy ją klientowi: jak jego firma interpretuje AI Act. Kluczowe jest tu całe pojęcie systemów wysokiego ryzyka i to, jak interpretują je prawnicy i compliance.

Mikołaj Szczerbicki: Czyli dobrze rozumiem, że nasz pierwszy pomysł na obecność człowieka w procesie nie musi być słuszny, a właściwe miejsce wyjdzie na etapie testów. Po to między innymi robimy testy, po to jest PoV. Dobra, co mamy dalej?

Łukasz Kałużny: Dobra, mamy już wszystko, można przejść do pracy: wiemy, skąd i jak, i zaczynamy PoV. Pierwszy faktyczny krok to jasne kryteria sukcesu. Przy PoV zwykle staramy się wstępnie zautomatyzować cały proces. Proof of value czy proof of concept sprawdza, czy nasza koncepcja zadziała. To jest, ładnie po polsku, studium wykonalności. Trzeba wyznaczyć, co tak naprawdę przetestujemy: najbardziej kluczowe albo najbardziej problematyczne elementy, a może cały proces bez wszystkich edge case'ów i corner case'ów, czyli tak zwaną szczęśliwą ścieżkę z mało problematycznymi odnogami, żeby sprawdzić najważniejsze elementy. I trzeba ustalić jasne kryteria. Na przykład: w fazie proof of concept 80% przypadków zostało obsłużonych poprawnie. To jasne kryterium tego, co jest dla nas sukcesem. I teraz zupełnie szczerze…

Mikołaj Szczerbicki: Łukasz, kiedy o tym mówisz, brzmi to niesamowicie łatwo. Jestem jednak przekonany, że dopiero z takim doświadczeniem jak Twoje, po tylu przypadkach, można w miarę jasno wyznaczyć takie kryteria. Komuś, kto zaczyna tę przygodę, wyznaczenie kryteriów sukcesu naprawdę nie przychodzi łatwo.

Łukasz Kałużny: Nie, i zwykle chcemy, żeby się udało. Dlatego trzeba podejść do tego realistycznie i zdobyć doświadczenie. Zupełnie uczciwie: my też często mamy takie pytanie. Weźmy raporty. Nasi klienci mają swoich ekspertów biznesowych i to taki ekspert naprawdę ocenia, czy wynik jest w porządku, czy nie. Bardzo trudno ocenić to mierzalnie. Ktoś mógłby się przyczepić, że da się to zmierzyć, ale to zawsze jest ludzkie odczucie, na przykład czy tekst pisma był językowo w porządku. Sam, pracując z tym na co dzień, wiesz, że coś…

Mikołaj Szczerbicki: Subiektywne.

Łukasz Kałużny: Jest bardzo subiektywne. Tak to wygląda w tej części.

Mikołaj Szczerbicki: Okej, czyli mamy wyznaczone kryteria sukcesu i przeprowadzamy testy.

Łukasz Kałużny: Testy. W większości przypadków testy nie powinny skupiać się na testowaniu technologii i zabawie nowym frameworkiem, tylko iść prosto do celu. Zaczynamy implementację. Z naszej perspektywy najczęściej staramy się mieć kawałek UI, zazwyczaj jak najbrzydszy. Mówię „jak najbrzydszy”, żeby nikogo nie korciło, żeby następnego dnia było to na produkcji. Dajemy minimalną użyteczność, zostawiamy środowisko i po prostu zaczynamy testować agentów, ten kod.

Z doświadczenia technicznego jedna rzecz do zapamiętania: zrób w miarę dobre logowanie w całym procesie, żeby potem łatwo się ze wszystkiego rozliczyć: jak działało, ile trwało, jakie decyzje podjął agent i co działo się dalej. Tak jak przy dobrej aplikacji, observability trzeba zapewnić od początku.

Mikołaj Szczerbicki: Właśnie, chciałem wspomnieć, że kiedy słyszę „logowanie”, od razu przypominają mi się moje rozmowy z Szymonem o observability, do których obejrzenia gorąco zachęcam.

Łukasz Kałużny: Tak, warto je zobaczyć, tam można przyjrzeć się części produkcyjnej. Tutaj potrzebujemy mniej, bo wystarczy plik tekstowy. Ważne jest, po co to robimy. Logi będą naszym katalogiem błędów i roadmapą: co trzeba poprawić, a czego nie poprawiamy. Trzeba zdecydować, czy coś jest rzeczą na przyszłość. Na przykład znaleźliśmy edge case, który przy pilocie czy produkcji koniecznie trzeba naprawić, ale nie w tym momencie.

Im więcej takich rzeczy wyłapiemy w trakcie testów, tym lepiej. Zobaczymy też, ile będzie trwała automatyzacja. U innego klienta nie przeskoczymy tego, że agent nie odpowie w ciągu 30 sekund, bo danych jest za dużo, albo że raport będzie się generował 5 minut, bo agent musi przejrzeć kilkadziesiąt stron, żeby podjąć decyzję. To jest w porządku i pozwala zbudować odpowiednie oczekiwania oraz roadmapę, żeby nie było niespodzianek, jeżeli zdecydujemy się wejść na produkcję.

Mikołaj Szczerbicki: Dobrze, to powiedz mi, jak mamy interpretować wnioski z testów?

Łukasz Kałużny: Mamy takie podejście, że są trzy stany. Pierwszy nazwijmy scale, czyli skaluj: idź dalej, rób pilota, rób produkcję. To oznacza, że proof of concept spełnił swoje cele i wiemy, co trzeba zrobić dalej. Osiągnęliśmy kryteria sukcesu, które spisaliśmy, albo subiektywnie usłyszeliśmy: tak, jest w porządku, chcemy z tym iść dalej. Jesteśmy świadomi, że wychodzimy z fazy eksperymentu do fazy faktycznego projektu. Drugi status, który możemy mieć przy tych decyzjach, to iterate, czyli kolejna iteracja.

Mikołaj Szczerbicki: Czyli próbuj dalej.

Łukasz Kałużny: Próbuj dalej. Ale nie dlatego, że czujemy, że będzie dobrze, tylko dlatego, że wiemy na przykład, że potrzebujemy czasu, żeby poprawić X, Y, Z. Takim przypadkiem była implementacja sędziego w procesie, o którym mówiłem. Pojawił się pomysł: w sumie możemy dodać agenta, który to zweryfikuje. Potrzebujemy na to jeszcze 3–4 dni, żeby zrobić jeszcze raz pełne testy.

Mikołaj Szczerbicki: Czyli testy zakończone tym statusem wcale nie są złe. To nie jest zły wynik testu, tylko dobry, bo pokazuje, nad czym jeszcze powinniśmy popracować i co przemyśleć, żeby rozwiązanie faktycznie spełniało nasze oczekiwania.

Łukasz Kałużny: I ostatni, najbardziej znienawidzony status, bo nie można odtrąbić sukcesu, choć ja uważam, że to jest sukces: kill, czyli zabicie eksperymentu, inicjatywy. Dlaczego mówię, że to sukces? Jeżeli dobrze to spisaliśmy, wiemy, dlaczego się nie powiodło. Przy proof of concept i proof of value celem jest sprawdzenie, czy rozwiązanie wniesie wartość i będzie wykonalne. Przeprowadziliśmy test. To trochę czarny humor, ale operacja została przeprowadzona z sukcesem. Pacjent zmarł.

Mikołaj Szczerbicki: Tak, właśnie, to dla mnie istotne. Powiedz, czy dobrze myślę: to nie był zły agent, tylko ta idea nie była warta automatyzacji.

Łukasz Kałużny: Tak, nie była warta automatyzacji. W niektórych miejscach być może zabrakło dostępów do API i dlatego się nie powiodło.

Mikołaj Szczerbicki: Może zbyt wygórowane oczekiwania.

Łukasz Kałużny: Też, choć na szczęście coraz rzadziej. Powiedziałbym raczej, że może się okazać, że dodanie automatyzacji w jakimś systemie będzie w firmie zbyt kosztowne. Na przykład koszty dobudowania API pochłoną potencjalne zyski. Na to też trzeba popatrzeć. Jeżeli dobrze spiszemy wnioski, dlaczego się nie powiodło, to był sukces. I kolejny sukces: nie utopiliśmy się w projekcie, który i tak by potem nie działał. To też istotna rzecz.

Mikołaj Szczerbicki: Z biznesowego punktu widzenia brzmi to naprawdę bardzo istotnie. Łukasz, mam wrażenie, że przeszliśmy przez wszystkie kroki takiego procesu. Czy możesz zrobić dla nas podsumowanie?

Łukasz Kałużny: Najważniejszy punkt: tydzień przygotowań i zebrania danych oszczędzi nam naprawdę dużo pracy, która w ogóle nie powinna się odbyć na zasadzie debugowania. To, co wie Ania, czyli przykładowo nasza pracownica, o tym, jak coś zrobić: trzeba z nią usiąść i to spisać. To będzie nasz wsad do analizy i do ustalenia, czego faktycznie potrzebujemy. Pierwsza rzecz to więc stara dobra analiza i od niej zacznijmy.

Druga rzecz to spisanie kryteriów sukcesu: co oznacza, że idziemy dalej. To może być potem płynne i subiektywne. Okej, ale wiemy, do czego zmierzamy. I ostatnia rzecz: z analizy może wyjść, że to już nie ma sensu. Jeżeli dobrze zrobimy analizę, większość takich PoC-ów zakończy się sukcesem. Wtedy zdecydujemy, czy iterujemy, idziemy dalej do fazy pilotażowej, czy może podsumujemy koszty i okaże się, że to nie miało sensu. Ale sukcesem tego PoC-a będzie to, że sprawdzimy, co faktycznie możemy osiągnąć. Dobre przygotowanie jest tu kluczem, a następnie pamiętanie o sprawdzaniu metryk i iterowaniu, jeżeli jesteśmy blisko sukcesu. Jeżeli nie osiągamy sukcesu, bo kręcimy się w kółko, to być może warto już zabić tę inicjatywę.

Mikołaj Szczerbicki: Łukasz, bardzo Ci dziękuję. Jak wspomniałem, dla kogoś, kto pierwszy raz próbuje zbudować agenta, to na pewno nie jest łatwe. Myślę jednak, że dzięki temu, co dzisiaj powiedziałeś, wielu osobom będzie znacznie łatwiej. Wszystkim bardzo dziękujemy i do zobaczenia w następnym odcinku. Cześć!

Łukasz Kałużny: Cześć!