O czym jest ten film
- Dlaczego pojedynczy agent w okienku czatu to dla firm za mało — organizacje potrzebują podejścia bardziej całościowego.
- Czym jest aplikacja agentowa według Oracle: zaczynamy od efektu biznesowego i roli użytkownika, a agentów dopasowujemy dopiero potem.
- Pokazany przykład: aplikacja wspierająca dyrektora prowadzącego zespół dwunastu osób — jeden widok na zaangażowanie zespołu we własny rozwój.
- Każdy komponent aplikacji uruchamia pod spodem przepływ pracy, w którym model językowy jest jednym z kroków, a nie całym silnikiem.
- Druga warstwa agentów działa w tle: obserwuje cały pulpit i podpowiada następne działania, które można od razu wykonać.
- Przewidywalność w praktyce: wstrzykiwanie kontekstu, węzły kodu, warunki i formatowanie odpowiedzi — cała branża zmierza w tę stronę.
- Bezpieczeństwo: polityki uprawnień generowane z dokumentów (np. podręcznika HR) w formie przetestowanych funkcji zamiast zwykłego RAG.
- Osobna kontrola dostępu dla użytkowników: kto może uruchomić dany przepływ i pod jaką tożsamością wykonuje on działania w systemach.
- Przepływy nie muszą czekać na kliknięcie — mogą startować np. od przychodzących e-maili.
- Wyniki wizualne (PDF-y, prezentacje) zamiast ścian tekstu — mniej psychicznego zmęczenia w codziennej pracy.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zacznij od efektu biznesowego, nie od technologii
Na czym polega: Autor za punkt wyjścia przyjmuje definicję Oracle: aplikację agentową projektuje się wokół konkretnego celu — wsparcia człowieka w jego roli — a dopiero potem dobiera agentów i automatyzacje. To odcina drogę do „wdrażania AI dla samego AI”.
Jak stosować: Zanim powstanie pierwszy prompt, opisz jednym zdaniem, co aplikacja ma odmienić w czyjejś codziennej pracy (np. „dyrektor ma w jednym miejscu widzieć zaangażowanie zespołu w rozwój”). Od tego zdania uzależniaj kolejne decyzje projektowe.
Na co uważać: Najczęstsza pułapka to odwrócenie kolejności: „mamy agenta, znajdźmy mu zastosowanie”. Takich projektów nie da się obronić przed zarządem i równie trudno zmierzyć ich wartość.
2.Agent to narzędzie w aplikacji, a nie cała aplikacja
Na czym polega: W modzie na AI łatwo ulec pokusie, by agent był całą automatyzacją. Autor argumentuje, że kontrolę zyskujemy dopiero wtedy, gdy model językowy jest jednym z elementów większego, przewidywalnego systemu.
Jak stosować: Rozpisz proces i zaznacz, które kroki faktycznie wymagają elastyczności modelu (pisanie, klasyfikacja, analiza), a które mogą być zwykłym kodem, warunkami i regułami. Model stosuj tylko tam, gdzie jest naprawdę potrzebny.
Na co uważać: Im większą część logiki oddajesz modelowi, tym trudniej zagwarantować powtarzalność — a w firmach o powtarzalność chodzi najbardziej.
3.Każde wywołanie modelu osadź w przepływie pracy
Na czym polega: W omawianym podejściu żadne wywołanie LLM nie jest „gołą rozmową”: najpierw wstrzykiwany jest kontekst, potem następują węzły kodu, warunki i formatowanie odpowiedzi pod interfejs. Cała branża zmierza w tę stronę.
Jak stosować: Traktuj model jako jeden węzeł przepływu. Przed nim: przygotowanie danych i wybór narzędzi; po nim: walidacja i doprowadzenie wyniku do postaci, którą pokażesz użytkownikowi.
Na co uważać: Wysyłanie danych prosto do modelu, bez uprzedniego ujęcia ich w strukturę, to prosta droga do niespójnych odpowiedzi i wycieków kontekstu.
4.Zbuduj jeden widok na całą rolę, nie kilkanaście czatów
Na czym polega: Istotą aplikacji agentowej jest jeden ekran obsługujący cały obszar czyjejś pracy: statusy, pytania, ręczne uruchamianie akcji. Czat pozostaje, ale jako jeden z elementów, nie jedyne okno na świat.
Jak stosować: Wypisz czynności z danej roli (np. menedżera: przegląd celów, e-maile przypominające, pytania o polityki firmowe) i sprawdź, które da się złożyć w jeden spójny pulpit z komponentami.
Na co uważać: Jeden widok nie znaczy jedna gigantyczna aplikacja „na wszystko” — na jeden pulpit powinien przypadać jeden cel biznesowy.
5.Niech agenci w tle podpowiadają następny krok
Na czym polega: Poza agentami obsługującymi konkretne komponenty warto mieć drugą warstwę: agentów obserwujących cały stan pulpitu i sugerujących, co zrobić dalej — z możliwością natychmiastowego działania.
Jak stosować: Dodaj do pulpitu sekcję rekomendowanych działań generowaną z bieżących danych. Każda podpowiedź powinna prowadzić do akcji wykonalnej od razu w tym samym miejscu, np. edycji i wysyłki e-maila.
Na co uważać: Podpowiedzi bez możliwości szybkiego wykonania zamieniają się w kolejne powiadomienia, które użytkownik z czasem zacznie ignorować.
6.Zostaw człowiekowi punkt decyzyjny przed każdą akcją na zewnątrz
Na czym polega: W przykładzie z filmu robocza wersja e-maila do podwładnego pojawia się jako komponent pulpitu — można ją przejrzeć i poprawić przed wysłaniem. Automatyzacja kończy się na przygotowaniu, decyzja zostaje przy człowieku.
Jak stosować: Wszystko, co aplikacja wysyła, modyfikuje lub publikuje w imieniu użytkownika, przepuszczaj przez etap podglądu i akceptacji w interfejsie.
Na co uważać: Nadmiar zatwierdzeń zabija sens automatyzacji — punktów kontroli potrzebujesz tam, gdzie akcja jest nieodwracalna lub dotyka innych ludzi.
7.Krytyczne zasady zamieniaj w przetestowany kod, nie w RAG
Na czym polega: Dla pytań o urlopy czy benefity „zwykle poprawna” odpowiedź z wyszukiwania w dokumentach nie wystarczy. Autor pokazuje trzecią drogę: dokument (np. podręcznik HR) zostaje zamieniony w zestaw funkcji z wygenerowanym kodem, testami i ściśle określonymi danymi wejściowymi.
Jak stosować: Rozdziel pytania na te wymagające dosłownej precyzji (liczba dni urlopu, progi uprawnień) — tam kodyfikuj zasady w funkcje — i na te otwarte, gdzie RAG w zupełności wystarczy.
Na co uważać: Kodyfikacja dokumentu to proces, który trzeba powtarzać po każdej zmianie regulaminu. Zaplanuj odświeżanie, inaczej agent będzie pewnie powtarzał nieaktualne zasady.
8.Rozdziel uprawnienia agenta od uprawnień użytkownika
Na czym polega: Autor opisuje dwa niezależne poziomy zabezpieczeń: polityki ograniczające, co agent może zrobić, oraz kontrole decydujące, kto może uruchomić dany przepływ i pod jaką tożsamością wykonuje on działania w systemach.
Jak stosować: Dla każdego przepływu zdefiniuj osobno: minimalny zestaw narzędzi agenta, listę osób uprawnionych do uruchomienia oraz tożsamość techniczną, pod którą pracuje automatyzacja.
Na co uważać: Agent z szerokimi uprawnieniami, dostępny dla wszystkich użytkowników aplikacji, to typowy wektor wycieku danych wewnętrznych.
9.Wyzwalacze nie muszą kończyć się na kliknięciu
Na czym polega: Aplikacja agentowa to centrum dowodzenia, ale przepływy mogą ruszać także bez udziału użytkownika — na przykład w reakcji na przychodzącego e-maila.
Jak stosować: Przejrzyj procesy obsługiwanej roli i poszukaj zdarzeń, które mogą samodzielnie startować automatyzacje. Interfejs zostaw na statusy, pytania i akcje wymagające człowieka.
Na co uważać: Automatyczne wyzwalacze bez limitów i alertów potrafią wywołać lawinę niechcianych akcji — na początku włącz tryb, w którym człowiek zatwierdza każdy start.
10.Domagaj się wyników wizualnych zamiast ścian tekstu
Na czym polega: Autor zauważa, że ciągłe czytanie długich odpowiedzi tekstowych po prostu męczy. Na uwagę zasługują artefakty — PDF-y, prezentacje, diagramy — które pozwalają szybciej pojąć złożone podsumowanie.
Jak stosować: Tam, gdzie agent ma coś podsumować lub przeanalizować, ustal format wyjścia na dokument lub grafikę, którą da się przejrzeć wzrokiem, a nie czytać akapitami.
Na co uważać: Generowanie ozdobnych artefaktów na siłę do prostych pytań spowalnia odpowiedź — stosuj je do materiałów złożonych i powtarzalnych.
Redakcyjne tłumaczenie
Od pojedynczego agenta do aplikacji agentowej
W tym roku sporo na kanale zajmowałem się agentami osobistymi: „drugim mózgiem”, asystentami do kodowania, a nawet agentami obsługi klienta. Wszystkie zbudowane są według tego samego schematu — pojedynczy agent, wokół którego osadzamy jeden przypadek użycia, oraz rozmowa w okienku czatu, gdzie wysyłamy prośby i czytamy odpowiedzi. Tacy agenci są znakomici, u mnie obsługują dużą część biznesu. Ale kiedy przychodzi mi pracować z firmą nad wdrożeniem agentowego AI, często okazuje się, że potrzeba czegoś bardziej całościowego.
Przez ostatnie lata AI zrobiło się tak głośne, że twórców agentów kusi, by agent był całą automatyzacją albo całą aplikacją — zamiast być narzędziem osadzonym w większym, bardziej przewidywalnym procesie czy programie, czego w praktyce potrzebuje większość ludzi. Potrzebują czegoś, co nazywa się aplikacją agentową.
Definicja: najpierw wynik, potem agent
To oficjalna definicja Oracle i bardzo mi się podoba. W aplikacji agentowej nie zaczynamy od pytania „co zautomatyzujemy tym agentem”. Zaczynamy od efektu biznesowego: w czym konkretnie aplikacja ma pomóc człowiekowi w jego roli? Doświadczenie projektujemy wokół tego celu, a dopiero potem zastanawiamy się, jak wpleść w aplikację — być może nawet kilku — agentów, którzy wspomogą wybrane automatyzacje.
To najpraktyczniejsza droga do wdrożenia agentowego AI. Kiedy priorytetem jest efekt biznesowy, znacznie większa szansa, że organizacja faktycznie dostanie wartość, a nie tylko najnowszą technologię wdrożoną dla samego wdrożenia — a uwierzcie, widuję to boleśnie często. Do tego, gdy agenci są jedynie narzędziem w większej aplikacji, zyskujemy kontrolę i przewidywalność: w całym programie pracują przepływy korzystające z modeli językowych, ale to nie agent prowadzi wszystko od początku do końca.
(Informacja dodatkowa: „przepływ pracy”, po angielsku workflow, to zaplanowany ciąg kroków — przygotowanie danych, wywołanie modelu, warunki, formatowanie wyniku. Pojęcie będzie pojawiać się przez cały materiał.)
Wśród platform, jakie widziałem, najlepiej robi to Oracle AI Agent Studio, więc to na niej pokażę cały proces. Film powstał we współpracy z Oracle, ale niezależnie od tego z ich podejścia da się wyciągnąć wnioski — o przepływach i bezpieczeństwie — które przenoszą się na dowolny stos technologiczny. Link do platformy znajdziecie w opisie.
Przykład: pulpit menedżera z zespołem dwunastu osób
Pracę zaczynamy tak samo jak z agentem do programowania: opisujemy, co chcemy zbudować. I znowu najważniejsze jest pytanie o cel — po co ta aplikacja ma służyć w czyjejś roli. W pokazywanym przykładzie poprosiłem o aplikację do coachingu menedżerskiego: „Jestem dyrektorem, mam zespół około dwunastu osób i chcę jednego widoku, aplikacji agentowej, pokazującego, jak mój zespół angażuje się we własny rozwój”.
Nie będę czekał na budowanie wszystkiego od zera — pokazuję wynik, który wcześniej otrzymałem z tego samego polecenia. Aplikacja składa się z wielu komponentów i pod spodem każdy, w którym pracuje agent, napędzany jest przepływem pracy. Mamy więc do czynienia z w miarę przewidywalnym procesem, który określa, jak agent wspomaga daną automatyzację.
Generowanie chwilę trwało, bo przepływ był bardzo rozbudowany — odpowiedź wyszła znakomita i możemy zadawać pytania uzupełniające. Czat tu nie znika: w aplikacji agentowej nadal mamy do niego dostęp, ale dochodzi struktura w postaci gotowych komponentów. Na dole, dla przykładu, jest komponent pozwalający wysłać przypominającego e-maila każdemu, kto nie nadąża z bieżącymi celami. Roboczą treść przygotowuje przepływ, ale piękno tego rozwiązania polega na tym, że szkic wyświetla się bezpośrednio w pulpicie: mogę go przejrzeć, poprawić i dopiero wtedy wysłać. Nie muszę przechodzić do innego programu — całą kontrolę mam w jednym miejscu. O to dokładnie chodzi: jeden widok do ogarnięcia wszystkiego, co potrzebne do jednego celu biznesowego, tutaj do zarządzania zespołem.
Zwróćcie uwagę na prawy górny róg, bo to jedna z moich ulubionych części tej aplikacji. Za komponentami pracują agenci, ale oprócz nich w tle działa druga grupa, która ma wgląd we wszystko — podwładnych, priorytety — i podpowiada następne kroki. Mogę wejść w poszczególne komponenty po szczegóły, ale gdy chcę ogólnie wiedzieć, co dalej, wystarczy spojrzeć tu. Agent podpowiada na przykład wysłanie e-maila do bezpośrednio podległych osób; jednym kliknięciem otwieram podpowiedź, edytuję treść i faktycznie realizuję działanie. Aplikacja pomaga więc nie tylko ustalać priorytety, ale też od razu je wykonywać.
Zasada najważniejsza: model zawsze wewnątrz przepływu
Gdyby z całego materiału miała zostać jedna myśl, to ta: w aplikacji agentowej każde wywołanie dużego modelu językowego jest częścią większego przepływu, który dodaje przewidywalności. Widać to na przykładzie: na starcie wstrzykiwany jest kontekst, dalej węzły kodu i warunki, a dopiero potem wywołanie modelu. Model jest ważnym ogniwem procesu, ale nie jedynym — w odróżnieniu od aplikacji czatowych, gdzie wpisany tekst trafia prosto do LLM. Często trzeba jeszcze zmienić format odpowiedzi pod to, co ma się wyświetlić w aplikacji; generalnie kontroli musi być znacznie więcej niż w układzie „prośba wprost do agenta”.
Cała branża zmierza właśnie w tę stronę: przepływy agentowe mają być maksymalnie przewidywalne. Modele są zdolne i elastyczne, potrafią rozebrać problem i dojść do rozwiązania. Ale na poziomie przedsiębiorstwa potrzebne są gwarancje: że kontekst zawsze zostanie załadowany tak samo, że warunek wybierze właściwy model do danego zadania, że formatowanie się nie wysypie. Są wymagania, przy których agentowi nie wolno dać szansy na pomyłkę, bo stawki są zbyt wysokie — albo po prostu chcemy, żeby nasze automatyzacje były niezawodne. To najbardziej niezawodne podejście, i to także w pracy nad kodem z pomocą AI. Robię tak w Archonie, moim narzędziu open source do budowy agentów — jego edytor przepływów wygląda zresztą bardzo podobnie do tego w Oracle AI Agent Studio, więc od razu poczułem się tu jak w domu. To dziś po prostu standardowy sposób automatyzowania czegokolwiek z użyciem modeli językowych.
W Oracle AI Agent Studio budowa aplikacji zaczyna się od przepływów: ustalasz konkretne automatyzacje, które chcesz mieć w jednym widoku, a potem każdy komponent korzysta z odpowiedniego przepływu. Kliknięcie przycisku — tak jak w pokazanym przykładzie — uruchamia przepływ z danymi z pulpitu jako wejściem.
Polityki: zasady zamienione w kod
Przepływy pozwalają też wprowadzić ostrzejsze reguły bezpieczeństwa. W Oracle AI Agent Studio istnieje pojęcie polityki: tworzy się funkcje nadające agentowi bardzo szczegółowe uprawnienia i możliwości, a następnie wplata je w przepływy. Załóżmy, że budujemy aplikację dla działu HR i w ramach wspólnego pulpitu ma działać agent odpowiadający na pytania o politykę urlopową. Można po prostu wgrać dokumenty — w przykładzie jest to PDF z podręcznikiem HR — a platforma zamieni wytyczne z pliku w funkcje przekazywane agentowi. Każda funkcja ma wygenerowany kod źródłowy, przypadki testowe do walidacji oraz ściśle określone wejście i wyjście. Cała idea: na podstawie materiałów ustalamy dokładnie, co agent ma umieć, i dopiero wtedy tworzymy dla tego funkcje.
Tutaj trzeba rozgraniczyć dwie rzeczy, bo wiele osób próbowałoby rozwiązać ten problem przez RAG.
(Informacja dodatkowa: RAG, czyli Retrieval-Augmented Generation, to technika, w której model odpowiada na pytania, wyszukując fragmenty wcześniej załadowanych dokumentów.)
Zamiast zamieniać podręcznik HR w kod, można by po prostu wgrać go do agenta i kazać mu wyciągać z dokumentu fragmenty na bieżąco. Problem w tym, że taka odpowiedź jest probabilistyczna. RAG działa dobrze i zwykle trafia w prawdę — ale przy urlopach i benefitach „zwykle” nie wystarcza. Lepiej wziąć dokument i zamienić go w przetestowany kod, żeby agent miał strukturę i odpowiadał poprawnie za każdym razem.
Sam przepływ zaczyna się od wywołania klasyfikacyjnego: model rozpoznaje, czy pytanie dotyczy urlopu rodzicielskiego, czy polityki urlopowej. Zanim jednak model zostanie wywołany, ładowana jest polityka — agent dostaje dokładnie te narzędzia, których potrzebuje, ani jednego więcej, i to w wąskim zakresie. Przepływ można testować na miejscu: odpowiedź widzimy w formacie JSON, bo to nie finalna postać agenta — dopiero komponent interfejsu w aplikacji nada jej właściwą formę. Podczas budowania przepływu po prostu sprawdzamy, czy wszystko działa.
Kto może uruchomić przepływ — i w czyim imieniu
Omówiliśmy uprawnienia agenta i jego konkretne możliwości, ale osobno zarządza się także bezpieczeństwem po stronie ludzi korzystających z aplikacji. Dla każdego przepływu można określić, kto w ogóle ma prawo go uruchomić, oraz pod jaką tożsamością przepływ wykonuje kolejne kroki automatyzacji. Do tego dochodzi cała masa innych ustawień: model używany w przepływie albo wyzwalacze — bo automatyzacje nie muszą czekać na kliknięcie w aplikacji. Pulpit jest naszym oknem na system, ale przepływy można rozszerzyć na przykład o automatyczne starty od przychodzących e-maili.
Sedno: aplikacja agentowa to wasze centrum dowodzenia. Tu sprawdzacie statusy, tu ręcznie uruchamiacie przepływy, tu zadajecie agentowi pytania — wszystko w jednym miejscu, z możliwością dalszego rozszerzania.
Artefakty zamiast ściany tekstu
Na koniec rzecz, o której chcę powiedzieć krótko: praca z agentami w formie wizualnej. Nie da się mieszkać w czacie całymi dniami. Często to wystarcza, ale nie zawsze da się przebywać w takim miejscu. Chcemy, żeby agent komunikował się z nami wizualnie, na tyle, na ile się da — żeby tworzył artefakty: prezentacje, PDF-y. Nawet jeżeli nie wykorzystamy ich później, sam fakt szybszego pojęcia materiału robi ogromną różnicę w produktywności.
Kiedy proszę agenta o coś bardziej złożonego, na przykład przegląd jakiegoś obszaru, nie chcę, żeby wypluwał na mnie ścianę tekstu. I znowu świetny przykład z Oracle AI Agent Studio: podsumowanie ryzyka związanego z rozwojem zespołu — wracając do pierwszego przykładu — dostaję jako PDF. Szczegóły przeglądam w znacznie czystszej formie. Gdyby to samo przyszło jako zwykła odpowiedź tekstowa, czytanie byłoby uciążliwe. Da się, ale powtarzanie tego w kółko przez cały dzień mocno męczy głowę. Dla własnego spokoju chcę, żeby moi agenci jak najczęściej oddawali wynik właśnie w tej formie. Zresztą dokładnie dlatego do mojego gadania zawsze dołączam diagramy — jak widać po tym materiale.
Podsumowanie
To wszystko, co składa się na aplikację agentową, i to, jak dojść do niej z Oracle AI Agent Studio. Najważniejsza myśl całego materiału: skup się na efektach biznesowych. Definicja Oracle mówi wprost — aplikację buduje się wokół rezultatu, zamiast czynić z agenta całość rozwiązania. Pamiętajcie, że to materiał wstępny: chciałem w ogólnym zarysie pokazać, jak takie aplikacje powstają w podejściu Oracle, w którym użytkownicy biznesowi składają całość bez żadnych umiejętności technicznych. W kolejnych odcinkach pokażę, jak podobne rzeczy budują programiści bezpośrednio w VS Code z agentami do kodowania. Jeśli doceniacie materiał i czekacie na więcej o aplikacjach agentowych i inżynierii agentowej w ogóle, polubienie i subskrypcja bardzo pomagają. Do zobaczenia w następnym odcinku.