Fabryka agentów AI: wspólna platforma w dużej organizacji
- Dla kogo:
- CTO, CIO, architekci i managerowie IT planujący coraz więcej agentów AI w dużej organizacji
- Czas czytania:
- 10 min
- Odcinek:
- 36 min
Po kliknięciu wideo załaduje się z YouTube (Google). Google może zapisać dane na Twoim urządzeniu i przetwarzać je także w USA. Więcej (PDF) · Obejrzyj na YouTube
Słuchaj też: Spotify · Apple Podcasts · RSS
W skrócie
Jeśli w Twojej firmie ma powstawać coraz więcej agentów AI, musisz zdecydować, czy każdego budujesz osobno, czy stawiasz wspólną platformę. Fabryka agentów to taka platforma na Azure AI Foundry, API Management i Logic Apps: osobne środowiska do eksperymentów, testów i produkcji, bezpieczeństwo zatwierdzone raz i integracje, które podpina się raz i udostępnia kolejnym agentom. Zespół z zaakceptowanym pomysłem szybko dostaje zabezpieczone środowisko.
Kluczowe wnioski
- Gdy strategia firmy zakłada coraz więcej agentów i API, wspólna platforma jest prawdopodobnie jedynym sensownym kierunkiem, a pierwszego agenta dla zarządu da się pewnie zbudować bez niej.
- AI Sandbox jest ustandaryzowanym, zabezpieczonym miejscem na sprawdzenie hipotezy biznesowej, a agent przechodzi z niego przez środowisko przedprodukcyjne na produkcję; wdraża się go z repozytorium Git przez CI/CD jak zwykłe oprogramowanie.
- W wariancie enterprise'owym dane wątków leżą w zasobach we własnej subskrypcji organizacji, szyfrowanych jej kluczami.
- API Management wystawia systemy firmy agentom na jednej fasadzie, z opisem zrozumiałym dla modelu, więc nie trzeba pisać własnych bramek MCP ani zmieniać systemów źródłowych.
- Gdy proces jest naprawdę deterministyczny, Logic Apps bardzo często okazuje się bardziej przewidywalny niż własny kod czy agenci, a agent wchodzi tam, gdzie potrzebna jest analiza generatywna.
- Pracę nad platformą zaczyna warsztat, na którym z przypadków biznesowych klienta wybiera się te, które dobrze do niej pasują.
Platforma ma sens, gdy agentów i API będzie przybywać
Jeśli strategia firmy przewiduje coraz więcej agentów i coraz więcej API, wspólna platforma jest prawdopodobnie jedynym sensownym kierunkiem. Pierwszego agenta, który ma pokazać zarządowi krótkoterminowy sukces, da się pewnie zbudować w parę tygodni.
Fabryka agentów oznacza tu wdrożenie w dużej organizacji, także w takiej, którą ograniczają regulacje.
Zespół nie stawia za każdym razem całej infrastruktury, więc szybciej zaczyna korzystać z agentów w ustandaryzowany sposób. Raz zaakceptowana platforma zwalnia z otwierania ruchu sieciowego i ponownej certyfikacji środowiska przy każdym przypadku biznesowym. Bezpieczeństwo i spójność, na przykład logi, rozwiązuje się raz.
Wspólna platforma skupia też wiedzę w jednym miejscu. U kilku klientów zespoły testują agentów zamiast kolejnych frameworków open source, których wciąż przybywa i które zmieniają sposób działania.
Agent przechodzi przez trzy środowiska
Platforma ma trzy środowiska: AI Sandbox, środowisko przedprodukcyjne i produkcję. AI Sandbox to miejsce bezpiecznych eksperymentów i innowacji. W wielu firmach sandbox oznacza wolną amerykankę, w której użytkownik robi, co chce. Tutaj jest to zabezpieczone, współdzielone środowisko, ustandaryzowane i podlegające zasadom korporacyjnym, być może z dostępem do danych produkcyjnych. Na danych anonimowych i sztucznych trudno budować agentów i AI w ogóle.
W sandboxie zespół sprawdza proof of value. Proof of value to test hipotezy biznesowej: czy scenariusz ruszy na agentach i będzie działał. Tworzenie i testowanie kodu schodzi na dalszy plan.
Scenariusz, który się sprawdzi, przechodzi z produkcyjnym cyklem życia do środowiska przedprodukcyjnego. Tam zespół sprawdza, czy wszystkie wdrożenia i integracje działają, a agent jest w pełni zintegrowany i gotowy do produkcji.
Każde środowisko składa się z czterech elementów: kanałów dostępowych, środowiska uruchomieniowego agenta, części integracyjnej i części utrzymaniowo-operacyjnej, o której łatwo zapomnieć.
Kanał dostępu jest oddzielony od agenta
Agent nie zależy od tego, jak się do niego dostajesz. Może być osobnym bytem, częścią aplikacji mobilnej, czatem na stronie albo procesem w tle. Platforma pozwala wywołać agenta w dowolny sposób, a samo wywołanie jest zewnętrzną integracją:
- synchronicznie z systemu biznesowego, na przykład przyciskiem „wygeneruj mi raport”;
- asynchronicznie przez zdarzenie, na przykład komunikat, kolejkę albo e-mail na sprawdzanej skrzynce;
- przez czat na stronie, w Teams lub w innej aplikacji.
Sposób wywołania zostaje poza platformą, żeby nie narzucać rozwiązania. Proof of value może pokazać, że agenta trzeba wywoływać zupełnie inaczej. Wtedy niczego się nie przepina ani nie przebudowuje.
Jeden z ostatnich przypadków u klientów to analiza wyników finansowych kontrahenta. W testach analityk wkleja wyniki w okno czatu i sprawdza, czy agent odpowiada zgodnie z oczekiwaniami. Docelowo w systemie jest przycisk „Dokonaj mi analizy”, który uruchamia agenta. Agent synchronicznie odpytuje backendy i API, zbiera i analizuje dane, a zwraca tylko wynik końcowy.
Agenci działają w projektach Azure AI Foundry
Środowiskiem uruchomieniowym agentów jest Azure AI Foundry w ekosystemie Microsoftu.
Jednostką pracy w AI Foundry jest projekt, czyli odpowiednik inicjatywy. Technicznie przypomina namespace w Kubernetesie: jest jeden duży klaster, a zespół lub projekt dostaje swój namespace. W Azure podobną rolę pełnią grupy zasobów. Jeden projekt może mieć wielu agentów budowanych przez jeden zespół, a agenci w projekcie mogą się ze sobą komunikować.
Projekt korzysta z modeli z określonej listy: OpenAI oraz wspieranych modeli open source z marketplace, bez modeli konkurencji. Protopia pracuje z klientami zazwyczaj na OpenAI, to jest 99%.
Małych agentów łączy agent orkiestrator
Ze względu na to, jak działają modele językowe, Protopia zazwyczaj buduje małych agentów, każdego do konkretnego zadania albo fragmentu procesu biznesowego. Nad nimi działa agent orkiestrator, który wywołuje mniejszych agentów. Orkiestrator może dostać droższy model z reasoningiem, a mali agenci tańszy model, na przykład GPT-4o mini.
W większości przypadków Protopia nie puszcza procesu przez łańcuch całkowicie niezależnych agentów. Korzysta ze scenariusza connected agents: centralny agent plus mali agenci, a kroki są orkiestrowane świadomie. W AI Foundry dosłownie wskazujesz, który agent łączy się z którym.
Wątek to konwersacja agenta w jednej sprawie. Handoff to chwilowe przekazanie wątku innemu agentowi: agent czeka na odpowiedź i przetwarza dalej.
A2A (agent to agent) to protokół open source do komunikacji między agentami, zainicjowany przez Google. Jest dostępny w AI Foundry, ale nie warto się do niego mocno przywiązywać, bo agenci zazwyczaj łączą się w obrębie jednego projektu.
W wariancie enterprise’owym dane wątków zostają w Twojej subskrypcji
Historia wątków pozwala później wznowić wątek asynchroniczny i zebrać z niego wyniki. W wariancie mniej enterprise’owym usługa trzyma te dane u siebie. W wariancie enterprise’owym, który Protopia zazwyczaj wdraża, dane trafiają do osobnych usług, które trzeba wdrożyć:
- storage na pliki;
- Cosmos DB na konwersacje i dane agentów;
- Search z indeksami odwróconymi i bazą wektorową do wyszukiwania tekstowego lub semantycznego w tekstach, dokumentach i załącznikach, czyli podstawa RAG.
Bring your own resources to model, w którym organizacja dokłada storage, Cosmos DB i Search we własnej subskrypcji. Widzisz je i masz nad nimi kontrolę. Zasoby wdraża się prawie w całości na zasadach organizacji, więc można je dostosować do jej wewnętrznych wymagań regulacyjnych, na przykład bezpiecznej komunikacji i niezależnych logów.
Historia konwersacji może zawierać dane wrażliwe i chronione, na przykład w branży medycznej, farmaceutycznej czy bankowej. Dlatego zasoby szyfruje się kluczami organizacji (CMK), zgodnie z regulacjami, które organizacja wypracowała.
API Management jest centralnym punktem integracji
W tej architekturze API Management jest sercem platformy, bo agent bez API jest zwykłym czatem. Wystawia API organizacji spójnie, na jednej fasadzie, tak żeby agenci łatwo je konsumowali.
System biznesowy podpięty raz przez API jest dostępny dla każdego agenta, którego z nim połączysz. Agent nie dostaje od razu dostępu do wszystkiego: uwierzytelnianie i autoryzacja określają, z którym API rozmawia dany agent.
API musi być wystawione inaczej niż system backendowy. Systemy dostarczone z zewnątrz albo przez wewnętrzny dział często są słabo opisane. Agent nie wie z pamięci, co robi dana metoda, a sam opis metody tego nie gwarantuje. Dlatego w API Management dopisuje się opis zrozumiały dla agenta, żeby wiedział, który endpoint rozwiązuje jego problem. Działa to i dla OpenAPI Schema, i dla MCP (Model Context Protocol): każde API, wywołanie i spodziewaną odpowiedź opisuje się językiem naturalnym dostosowanym do modelu.
Opis pisze czat z system promptem, który mówi mu, że tekst ma służyć jemu samemu. Ludzka dokumentacja zamienia się w dokumentację maszynowo-tłumaczoną.
API Management tłumaczy też w locie, na przykład wystawia API SOAP jako REST. Dzięki API Management nie trzeba pisać własnej bramki MCP do systemu ani, co gorsze, modyfikować systemu źródłowego, żeby wystawiał endpointy dla agentów. Taka praca programistyczna potrafi być bardzo kosztowna i często nieprzewidywalna w czasie.
W API Management są dwie nowe możliwości. Dowolne istniejące API, z którego korzystają też systemy spoza świata agentów, można praktycznie jednym przełącznikiem przekształcić w MCP. Od niedawna można też przenieść na fasadę zewnętrzne MCP: cudze albo takie, które ktoś w firmie zbudował od razu jako MCP, bez API. Organizacja kontroluje je jak własne, z dodatkowymi zabezpieczeniami, politykami i orkiestracją.
Logic Apps obsługuje kroki, które da się przewidzieć
Jeśli scenariusz jest naprawdę deterministyczny, czyli znasz proces i wiesz, jak go podpiąć, Logic Apps bardzo często okazuje się bardziej precyzyjny i przewidywalny, a przy tym prostszy w budowie niż własny kod czy agenci.
Często zostają wąsko wyspecjalizowane, niskopoziomowe API i API Management, który je wystawia, a brakuje kleju do orkiestracji, na przykład: wywołaj API, odbierz odpowiedź, wyślij trzy e-maile albo SMS, poczekaj na zgodę i potwierdź na innym endpoincie. W tej architekturze klejem jest Logic Apps, narzędzie no-code Microsoftu, którym można też zarządzać z kodu. Logic Apps razem z API Management to iPaaS (Integration PaaS).
Przepływ w Logic Apps można wyklikać jak w Power Apps, ale konektorów systemowych i biznesowych jest więcej: do Oracle, SAP, CRM czy Salesforce. Przepływ może też wywołać API w API Management albo agenta. Gotowych integracji i akcji są, z grubsza, setki. Control flow obejmuje warunki (IF), pętle (FOR), obsługę błędów i wznawianie integracji.
Model OpenAI jest, w uproszczeniu, niedeterministyczny. Agent wchodzi dopiero tam, gdzie potrzebna jest analiza generatywna, wytworzenie czegoś nowego albo łączenie faktów w locie.
W niektórych scenariuszach punktem wejścia jest workflow w Logic Apps. Marek Grabarz: „to nie agent odpala workflow, tylko workflow woła agenta.” Na podstawie wyniku agenta workflow robi dalej coś przewidywalnego. Kanałem dostępowym jest wtedy integracja w iPaaS.
Agenta wdraża się jak kod
Agent jest takim samym kawałkiem oprogramowania jak każdy inny, więc część utrzymaniowo-operacyjna opiera się na podejściu DevOps. Specjalnych zasad nie ma, zmieniają się tylko niektóre detale techniczne.
Agenci są w repozytorium Git: GitHub, Bitbucket, GitLab lub innym, które organizacja już ma. Przygotowane skrypty CI/CD wdrażają agentów na kolejne środowiska.
Plik agenta w repozytorium zawiera definicję agenta z system promptem oraz podłączone integracje i innych agentów. Można go traktować jak manifest infrastructure as code. W tym przypadku są to skrypty w Pythonie, więc plik jest też definicją agenta w kodzie Pythona. Gdy platforma już działa, wdrożenie często sprowadza się do kopiuj-wklej albo pomocy GitHub Copilota czy innego agenta do kodowania.
Observability pokazuje przebieg każdego wątku
Gdy w agencie coś pójdzie źle albo ktoś zgłosi, że dostał złą odpowiedź, zespół sprawdza wątek. AI Foundry przechowuje w bazie pełne wątki konwersacji każdego agenta, dopóki ich nie usuniesz: wejście, wszystkie wywołane narzędzia, treść żądań do innych systemów, integracji i agentów oraz odpowiedzi. Wątek jest stanowy. W Azure AI Foundry Studio możesz go znaleźć, wrócić do niego, obejrzeć w playgroundzie i sprawdzić, co się stało.
Observability włącza się w projekcie prawie bez pracy wdrożeniowej. Application Insights, klasyczny APM Microsoftu, śledzi cykl życia agenta: pytania, odpowiedzi i wywołania, w całym wątku konwersacji z czatu albo w wątku wywołania z innego systemu.
AI Foundry ma też obszar oceny jakości: inny model ocenia, czy cały przepływ przebiegł dobrze. Zaczynają się pojawiać metryki ewaluacji odpowiedzi, ale rynek dopiero tu raczkuje, bo niedeterministyczną rzecz mierzy kolejna niedeterministyczna rzecz.
Content filtering działa od początku i chroni przed tym, że użytkownicy wrzucą do agenta coś groźnego. Organizacja reguluje, na jakie treści pozwala. Niektóre firmy mogą chcieć poluzować filtry, na przykład w e-commerce z treściami dla dorosłych.
Miarą platformy jest użycie i liczba skarg
Pierwszą miarą platformy i przypadków agentowych jest to, czy po wdrożeniu ktoś z nich korzysta.
Druga metryka dotyczy każdego agenta osobno: ile jest skarg i zgłoszeń błędów, na przykład na jakość odpowiedzi, w stosunku do liczby użyć. Dobry wynik to użycie, które nie spada, i brak skarg na jakość.
Pracę zaczyna warsztat, a sandbox ma być dostępny następnego dnia roboczego
Zanim zacznie się praca nad platformą, Protopia stara się zorganizować warsztat. Klient przygotowuje na niego przypadki biznesowe. Zaproszeni są architekci biznesowi, niekoniecznie osoby od utrzymania, bo to jeszcze nie ten etap. Na warsztacie zespół wskazuje przypadki, które dobrze pasują do platformy i dobrze się zintegrują. Przy 5, 10 czy 15 takich przykładach zachęta do budowy platformy jest dużo większa. Łukasz Kałużny: „to istotny element, żeby nie budować platformy dla samej platformy.”
Gdy inicjatywa zostanie zaakceptowana do testów w AI Sandbox, zespół powinien mieć dostęp następnego dnia roboczego. Zespół utrzymujący platformę może na przykład udostępnić takie środowisko w kilkanaście minut. Self-service jest możliwy, ale nie jest tu założeniem. Czas liczy się od akceptacji i nie obejmuje procesów organizacyjnych firmy.
Rozmawiają
Łukasz Kałużny
Founder, Managing Partner, Technology Advisor.
Łukasz Kałużny jest współzałożycielem Protopii i Microsoft MVP w kategorii Microsoft Foundry. Współprowadzi Patoarchitekci od 2019 roku i rozmawia o architekturze IT, GenAI i agentach AI bez marketingowego szumu.
Wszystkie wpisy autora
Marek Grabarz
Founder, Managing Partner, Technology Advisor.
Marek Grabarz jest współzałożycielem Protopii i Microsoft MVP w kategorii Microsoft Azure. Współprowadzi podcast Powered by Protopia i rozmawia z liderami IT o API Management, integracjach i bezpiecznym wdrażaniu AI.
Wszystkie wpisy autora
FAQ
Czy AI Foundry obejmuje też starsze usługi AI Microsoftu, na przykład speech to text?
AI Foundry w teorii udostępnia też usługi AI sprzed OpenAI, na przykład speech to text. Ten opis platformy nie skupia się na nich.
Czy Protopia pracuje tylko na technologiach Microsoftu?
Protopia ma też przypadki z innymi technologiami, ale specjalizuje się głównie w rozwiązaniach Microsoftu.
Czy warto budować każdego agenta jako osobną inicjatywę?
Z doświadczenia Protopii nie ma sensu budować pojedynczych agentów jako osobnych inicjatyw. Wyjątkiem jest pierwszy agent, który ma szybko pokazać zarządowi krótkoterminowy sukces.
Pełna transkrypcja
00:00 Fabryka agentów to wdrożenie, nie obrazek z low code
Łukasz Kałużny: Cześć! Witamy w Powered by Protopia. Jestem Łukasz Kałużny, a ze mną jest Marek Grabarz.
Marek Grabarz: Cześć.
Łukasz Kałużny: Cześć. Dzisiaj porozmawiamy o fabryce agentów. To kontynuacja tematu, a właściwie spięcie agentów i naszych poprzednich odcinków, w których tłumaczyliśmy podejście do API Managementu, który można nazwać sercem całości.
Marek Grabarz: Tak, mówiliśmy o tym w poprzednich nagraniach. Pierwsze dotyczyło samych agentów AI i wartości, jaką mogą wnieść do organizacji. Kolejne dotyczyło API Managementu. Tak jak wspomniałeś, Łukasz, dziś spróbujemy złożyć to w całość i opisać wizję architektury, którą jako Protopia oferujemy klientom: jak to wszystko ze sobą działa…
Łukasz Kałużny: …i jak to się sprawdza.
Marek Grabarz: I z jakich komponentów się składa.
Łukasz Kałużny: Przez fabrykę agentów nie będziemy rozumieli linkedinowych obrazków z diagramem low code na jakiejś platformie open source typu n8n, tylko prawdziwe wdrożenie dla dużych organizacji.
Marek Grabarz: Dokładnie tak. Czyli jak mogłoby to docelowo wyglądać w świecie enterprise, w szczególności w świecie ograniczonym regulacjami, DORĄ.
01:21 Trzy środowiska i cztery elementy platformy
Łukasz Kałużny: Tak. To, co widzicie na ekranie, to trzy środowiska w naszym podejściu. Wspominaliśmy o tym w poprzednich odcinkach: pierwsze środowisko to AI Sandbox, w którym chcemy dać miejsce do bezpiecznego eksperymentowania.
Marek Grabarz: Warto tu podkreślić, że choć to się nazywa sandbox, to w wielu firmach są typowo sandboxowe środowiska, w których panuje wolna amerykanka i użytkownicy mogą robić cokolwiek. My rozumiemy przez to środowisko ustandaryzowane, podlegające zasadom korporacyjnym, być może z dostępem do danych produkcyjnych. Agentów, czy w ogóle AI, trudno bowiem robić na danych zanonimizowanych, sztucznych.
Łukasz Kałużny: Tak, więc to środowisko zabezpieczamy i jest ono współdzielonym bytem. Jeszcze wyjaśnimy, dlaczego…
Marek Grabarz: Takie miejsce innowacji.
Łukasz Kałużny: Tak. Dlatego nie mówimy nawet o proof of concept, ale o proof of value. Nie skupiamy się na tworzeniu i testowaniu kodu, tylko na tym, czy nasz scenariusz biznesowy na agentach faktycznie ruszy i będzie działał.
Marek Grabarz: Czy realizuje hipotezę, która się pojawiła.
Łukasz Kałużny: Potem, już z produkcyjnym cyklem życia, przechodzimy na środowisko nieprodukcyjne, a na końcu świętujemy sukces i wdrażamy się na produkcję. Stosujemy te same praktyki, które znamy z wytwarzania oprogramowania.
Marek Grabarz: Tak jest.
Łukasz Kałużny: Jedno takie środowisko składa się z kilku elementów. Jeśli je rozbijemy, to mamy cztery. Pierwszy to kanały dostępowe, czyli sposób, w jaki komunikujemy się z agentem. Drugi to samo środowisko uruchomieniowe agenta. Trzeci to cała część integracyjna, która, jak powiedzieliśmy, jest realnym sercem wszystkiego. I na końcu część, o której wszyscy zapominają…
Marek Grabarz: Utrzymaniowo-operacyjna.
Łukasz Kałużny: Utrzymaniowo-operacyjna, czyli całe podejście DevOpsowe, bo agentów musimy traktować tak samo jak kod. To taki sam kawałek oprogramowania jak każdy inny. Nie ma tam specjalnych zasad, poza tym, że zmieniają się pewne detale techniczne wynikające ze sposobu działania. Dobra, zacznijmy od pierwszego elementu, czyli kanałów dostępowych.
03:54 Kanały dostępowe: przycisk, zdarzenie, czat
Marek Grabarz: Kanały dostępowe. Chodzi o to, jak będziemy agenta eksponować i gdzie go osadzimy. Czy będzie niezależnym bytem, częścią aplikacji mobilnej, czy będzie można się z nim skomunikować na stronie, czy będzie procesem działającym w tle. Dobrze rozumiem?
Łukasz Kałużny: Tak, dokładnie. Zakładamy tu, że agenta nie interesuje, w jaki sposób się do niego dostaniemy.
Marek Grabarz: Jak go wywołaliśmy.
Łukasz Kałużny: Tak. Częścią platformy jest możliwość dowolnego wywołania agenta i to są już zewnętrzne integracje. Nasz system biznesowy może wywołać agenta synchronicznie, na przykład użytkownik kliknie w systemie przycisk „zbuduj mi raport agentem”. W innym przypadku przyjdzie zdarzenie z systemu, asynchronicznie, na przykład komunikat z kolejki albo mail od użytkownika na sprawdzanej skrzynce. A w przypadku, który najczęściej kojarzy się z AI, będzie…
Marek Grabarz: Czat.
Łukasz Kałużny: Czat, na stronie albo w Teamsach.
Marek Grabarz: Albo w innej aplikacji.
Łukasz Kałużny: Albo gdzie indziej. Chodzi o to, żeby także mentalnie oderwać jedno od drugiego. Agent rozwiązuje problem, a to, jak go zainicjujemy, to zupełnie inna kwestia. Powinna być poza samą platformą, żeby dać dowolność i nie narzucać twardo rozwiązań. Już przy proof of value może wyjść, że chcemy zrobić to zupełnie inaczej, więc dajemy elastyczność, żeby potem nie przepinać się i nie przebudowywać.
Marek Grabarz: To dość istotne, bo, jak sam wspomniałeś, AI często kojarzy nam się z czatem, czyli z tym, co praktykują indywidualni użytkownicy: otwierają okienko i piszą „hej, wygeneruj mi wierszyk”. Nie o tym mówimy. Mówimy o realnych zastosowaniach biznesowych. Nie zawsze użytkownik końcowy wchodzi w interakcję z czatem. Bardzo często generujemy raport i potrzebujemy dodatkowych kroków, opisów albo procesu, który coś wokół tego zrobi. Zastosowań jest więcej.
Łukasz Kałużny: Z ostatnich przypadków klientów: przeanalizuj wyniki finansowe kontrahenta, zestaw wyniki kontrahenta. W trakcie testów faktycznie wklejamy te wyniki w okienko czatu i patrzymy, co wychodzi. Analityk sprawdza, czy agent odpowiada w oczekiwany sposób. Ale na koniec dnia w systemie będzie przycisk „Dokonaj analizy”.
Marek Grabarz: Punktem inicjującym agenta jest naciśnięcie guzika. Agent synchronicznie komunikuje się z backendami i API, zbiera informacje, analizuje, przetwarza i oddaje tylko wynik końcowy tego, co wygenerował albo, powiedzmy, wykoncypował.
Łukasz Kałużny: Tak można to określić.
Marek Grabarz: Dobra.
07:04 Microsoft Foundry i projekty dla zespołów
Łukasz Kałużny: Drugi element to sam agent. Tutaj poruszamy się w Azure AI Foundry i w ekosystemie Microsoftu.
Marek Grabarz: Mamy też przypadki z innymi technologiami, ale nie będziemy w nie wchodzić. Nasza specjalizacja kręci się głównie wokół rozwiązań Microsoftu.
Łukasz Kałużny: Żeby uprościć wdrożenia, budujemy platformę. Fabryka agentów AI, mimo marketingowej nazwy platform engineering, jest faktycznie potrzebna. Tak jak z AI Sandboxem i wszystkimi środowiskami: nie chcemy za każdym razem stawiać całej infrastruktury. To pierwszy istotny element: chcemy jak najszybciej umożliwić adopcję w wystandaryzowany sposób.
Marek Grabarz: Zaletą jest to, że raz wytworzone platformowe środowisko agentów zwalnia nas w przyszłości z otwierania ruchu sieciowego i recertyfikowania środowisk dla kolejnych przypadków biznesowych. Mamy jedną dużą platformę, zaakceptowaną do użycia i zbudowaną w sposób bezpieczny i spójny, także pod względem logów. Wiele wyzwań adresujemy raz, a dobrze.
Łukasz Kałużny: W AI Foundry jest definicja projektu i to bardzo dobrze, bo można ją porównać do projektu czy inicjatywy. Technicznie możemy to porównać do namespace'u w Kubernetesie: mamy jeden duży klaster, a zespół czy projekt dostaje swój namespace. Inaczej mówiąc, w Azure są to grupy zasobów, a w SharePoincie czy Teamsach zespół.
Marek Grabarz: Rozumiem, że taki projekt może mieć wielu agentów budowanych przez konkretny zespół.
Łukasz Kałużny: Dokładnie. W projekcie uruchamiamy agentów, którzy mogą się ze sobą komunikować, agent z agentem. W projekcie nie jesteśmy ograniczeni do jednego modelu, możemy korzystać z różnych wspieranych modeli. Jest OpenAI, najpopularniejszy…
Marek Grabarz: Cała masa dodatkowych modeli open source…
Łukasz Kałużny: Tak, plus wspierane modele open source, jest Microsoft Maia.
Marek Grabarz: W samym marketplace jest ogromna lista. Warto podkreślić, że to nie są modele konkurencji, tylko modele open source.
Łukasz Kałużny: One też są ograniczone do pewnej listy, ale z klientami pracujemy zazwyczaj na OpenAI, w 99%.
Marek Grabarz: Podsumowując, AI Foundry to nie tylko miejsce z projektami, w których osadzamy agentów. AI Foundry dostarcza też wszystkie modele AI dostępne w Microsoft, czyli modele open source i OpenAI, a także usługi AI, które istniały jeszcze przed OpenAI…
Łukasz Kałużny: Przy czym na nich się tu nie…
Marek Grabarz: Na przykład speech to text i tego typu rzeczy. W teorii tam są.
10:03 Observability i własne zasoby
Łukasz Kałużny: Tak, ale nie skupiamy się na nich w tym miejscu. Mamy więc funkcjonalności, czyli modele. Teraz rzecz ważna, o której wspominaliśmy, czyli dzień drugi: w projekcie dostajemy całe observability. Można powiedzieć, że prawie bez wysiłku wdrożeniowego włączamy observability, widzimy cały tracing tego, jak agent działa, i mamy historycznie wszystkie informacje audytowe. To też jest taka…
Marek Grabarz: Mówisz o Application Insights, kolejnej usłudze Microsoftu. Powiedziałbym, że to klasyczny APM.
Łukasz Kałużny: Tak.
Marek Grabarz: Jest w stanie prześledzić cykl życia agenta, pytań, odpowiedzi i różnych wywołań.
Łukasz Kałużny: Całego wątku, w zależności od tego, czy to wątek rozmowy, kiedy ktoś pisze na czacie, czy wątek wywołania, które przyszło z jakiegoś systemu.
Marek Grabarz: Patrząc na architekturę, widzę tam jeszcze dodatkowe usługi. AI Foundry buduje się konkretnie pod agentów i ma doczepiony zestaw usług, które pozwalają przechować historię wątku i do niego wrócić. Jeśli wątek jest asynchroniczny, możemy go później kontynuować i zebrać wyniki.
Łukasz Kałużny: Tak, to wszystko jest zbierane w zależności od konfiguracji. W mniej enterprise'owym wariancie usługa trzyma to w sobie. W bardziej enterprise'owym scenariuszu, który zazwyczaj robimy, te usługi są trzymane oddzielnie i musimy je dostarczyć, czyli wdrożyć.
Marek Grabarz: Konkretnie jest to baza, storage i…
Łukasz Kałużny: Search.
Marek Grabarz: Search, czyli do indeksowania.
Łukasz Kałużny: Indeksy odwrócone. Mamy storage na pliki i bazę Cosmos DB, w której przechowujemy konwersacje i dane agentów. Rozmowę agenta w jednej sprawie nazywamy tu wątkiem. Do tego Search, czyli baza wektorowa…
Marek Grabarz: …tekstów, dokumentów, załączników, do wyszukiwania tekstowego.
Łukasz Kałużny: Czyli do RAG-a.
Marek Grabarz: Albo semantycznego.
Łukasz Kałużny: Czyli dostajemy bazę do RAG-a.
Marek Grabarz: Warto podkreślić, że to model bring your own resources. Sami dokładamy storage, Cosmosa i Searcha, więc możemy nad nimi zapanować tak, żeby spełniały wewnętrzne wymagania regulacyjne organizacji: szyfrowanie, bezpieczną komunikację, niezależnie odkładane logi.
Łukasz Kałużny: Marku, można to jeszcze uprościć. Storage z tymi danymi będzie w naszej subskrypcji, będziemy go widzieli i mieli nad nim kontrolę.
Marek Grabarz: I będzie wdrożony po naszemu…
Łukasz Kałużny: Prawie po naszemu.
Marek Grabarz: Po organizacyjnemu, może tak. Dobra, jasne.
12:52 API Management jako serce integracji
Marek Grabarz: Mamy więc agentów. A agenci bez API, jak już podkreślaliśmy…
Łukasz Kałużny: Nie istnieją.
Marek Grabarz: Są tak naprawdę zwykłym czatem, niczym więcej.
Łukasz Kałużny: Trzecim elementem na tej mapie są właśnie integracje. Tu oddam Ci głos, bo wyróżniamy API Management.
Marek Grabarz: Staramy się, żeby API Management był centralnym punktem integracji. Zalety API Managementu omawialiśmy w poprzednich odcinkach. W skrócie: mamy w organizacji cały zestaw różnych API i chcemy wystawić je spójnie, tak żeby agenci łatwo je konsumowali, na jednej wspólnej fasadzie.
Łukasz Kałużny: Trzeba powiedzieć, że raz podpięty system biznesowy, zaprezentowany przez API…
Marek Grabarz: Zintegrowane API.
Łukasz Kałużny: Tak, jest dostępny dla każdego agenta, którego do niego podepniemy. Ważne: agent nie dostaje od razu dostępu do wszystkiego, ale możemy go łatwo podpiąć do konkretnego systemu biznesowego. To praca, którą robimy raz.
Marek Grabarz: Warto podkreślić, że API raz zintegrowane w API Managemencie nie jest dostępne dla każdego. Nadal obowiązują zasady uwierzytelniania i autoryzacji: ten agent może rozmawiać z tym API, a inny agent z innym. Każdy ma swoje uprawnienia. Druga istotna rzecz: API trzeba wystawić trochę inaczej niż nasz system backendowy. Często taki system jest dostarczany z zewnątrz albo przez komórkę wewnątrz firmy i nie jest dobrze opisany. Potrzebujemy konkretnych kontraktów i opisów. Dlaczego? Bo agent nie ma wiedzy, tak jak ja czy Ty…
Łukasz Kałużny: …z pamięci.
Marek Grabarz: …że konkretne API albo konkretna metoda robi to czy tamto. Sam opis metody nie daje tej gwarancji. Żeby agent był skuteczny, musimy w API Managemencie dostarczyć opis zrozumiały dla agenta, tak by wiedział, że właśnie ten endpoint jest mu potrzebny do rozwiązania problemu, który przetwarza.
15:16 Opis API dla modelu, SOAP jako REST i MCP
Łukasz Kałużny: Tak. Niezależnie od tego, czy wystawiamy API jako OpenAPI Schema, czy jako MCP, czyli Model Context Protocol, w obu przypadkach w API Managemencie możemy napisać dokumentację API, opisać schematy, przez które jest eksponowane, i przygotować dokumentację dla modelu LLM, dla agenta. Językiem naturalnym dostosowanym do modelu opisujemy każde API, każde wywołanie i to, czego model może się spodziewać.
Marek Grabarz: Ta technika często zaskakuje naszych klientów: używamy czatu, żeby opisał endpoint tak, żeby sam go później rozumiał. To jeszcze zabawniejsze.
Łukasz Kałużny: Tak, bierzemy ludzki język i ludzką dokumentację i przerabiamy ją na dokumentację maszynową, a nawet maszynowo tłumaczoną, bo to chyba dobre określenie.
Marek Grabarz: Tak, ale z takim system promptem, żeby model wiedział, że opis ma być pod niego. Ważne jest też, że API Management potrafi wręcz tłumaczyć w locie. Jeśli mamy API SOAP-owe, możemy je wystawić z API Managementu jako REST-owe. Dla wielu naszych klientów to zaskoczenie, ale takie możliwości istnieją. API Management daje nam więc dużo.
Łukasz Kałużny: Trzeba powiedzieć, dlaczego nazywamy API Management sercem. Upraszcza sposób integracji. Nie musimy pisać specjalnego kodu, na przykład bramki Model Context Protocol do naszego systemu. Nie musimy też, co gorsza, a ktoś może wpaść na taki pomysł, modyfikować systemu źródłowego, żeby wystawiał endpoint pod agentów. To może zająć sporo czasu i być kosztowne. Z drugiej strony wartością przy agentach nie jest napisanie kodu w Pythonie z jakimś frameworkiem, tylko to, że faktycznie się skupimy…
Marek Grabarz: …na automatyzacji.
Łukasz Kałużny: Tak, że skupimy się na rozwiązaniu problemu. API Management zdejmuje z nas dużo pracy programistycznej, która bywa bardzo kosztowna i często nieprzewidywalna w czasie.
Marek Grabarz: Kojarzy mi się tu jeszcze temat MCP, bo w API Managemencie są dwie nowe rzeczy. Po pierwsze, dowolne API, które kiedyś wystawiliśmy i które konsumują teraz inne systemy, niekoniecznie agentowe, możemy praktycznie jednym przełącznikiem skonwertować na MCP. Po drugie, od niedawna można przynosić zewnętrzne serwery MCP. Jeśli mamy zewnętrzne integracje MCP, które nie są własnością naszej firmy, albo ktoś u nas wyprodukował od razu MCP zamiast API, możemy przenieść to MCP na fasadę.
Łukasz Kałużny: Tak, jako swoje, zabezpieczyć je i kontrolować.
Marek Grabarz: Dołożyć swoje dodatkowe zabezpieczenia, swoje polityki i orkiestrację.
18:10 Logic Apps dla procesów deterministycznych
Łukasz Kałużny: Wspomniałbym tu o jednej istotnej rzeczy, czyli o iPaaS.
Marek Grabarz: Dokładnie. Często lądujemy w sytuacji, w której mamy niskopoziomowe, wąsko wyspecjalizowane API, które robią coś konkretnego. Mamy API Management, który potrafi je wystawiać. Brakuje nam jednak kleju, elementu orkiestrującego: zawołaj to API, dostań odpowiedź, wyślij trzy maile albo SMS-a, poczekaj na zatwierdzenie, a potem potwierdź na innym endpoincie. Takiej integracji nie da nam ani API Management, ani…
Łukasz Kałużny: …agenci.
Marek Grabarz: …ani pojedyncze API. Często potrzebujemy czegoś pośrodku. Czym to jest w naszej architekturze, Łukasz?
Łukasz Kałużny: To Logic Apps, czyli w Microsofcie narzędzie no code, którym możemy też zarządzać z kodu. Platformę Logic Apps razem z APIM-em klasyfikujemy jako iPaaS, czyli Integration PaaS.
Marek Grabarz: Warto podkreślić, że to nie jest typowe narzędzie w stylu Power Apps, w którym wszystko wyklikujemy. Oczywiście nadal możemy wyklikać, ale konektorów systemowych i biznesowych jest więcej. Możemy się podpiąć do Oracle'a, do SAP-a, do CRM-a, Salesforce'a i innych rzeczy.
Łukasz Kałużny: Albo wywołać API na APIM-ie.
Marek Grabarz: Tak, albo…
Łukasz Kałużny: Albo w tym wypadku wywołać agenta.
Marek Grabarz: Nie chcę rzucać konkretnymi liczbami, ale powiedziałbym, że z pudełka są setki różnych integracji.
Łukasz Kałużny: Tak, i akcji.
Marek Grabarz: W Logic Apps mamy też możliwość sterowania przepływem, czyli control flow. Możemy zrobić IF-a, pętlę FOR, łapać błędy, wznawiać integrację. Tych rzeczy, które możemy ogarnąć, jest sporo.
Łukasz Kałużny: Mówimy o tym dlatego, że w tej architekturze chodzi o to, żeby nie dodawać specjalnie kodu. Jeśli scenariusz jest naprawdę deterministyczny, znamy proces i wiemy, jak go podpiąć, to nie trzeba kombinować. Tam, gdzie trzeba by pisać customowy kod albo narobić agentów, bardzo często okaże się, że Logic Apps i proces, który tam mamy, będzie bardziej precyzyjny, prostszy do zrobienia i, co najważniejsze, przewidywalny.
Marek Grabarz: To cenna uwaga, bo wielu osobom rodzi się w głowie myśl: przecież OpenAI, nazwijmy to w uproszczeniu, jest w jakiś sposób niedeterministyczny. Budując logikę biznesową czy przepływ biznesowy, elementy znane, które możemy zautomatyzować, automatyzujemy deterministycznie: przez workflowy i integrację poszczególnych API. Agent wchodzi dopiero wtedy, gdy potrzebna jest analiza generatywna, wytworzenie czegoś dodatkowego, połączenie faktów w locie, a nie przejście od A do B do C do D.
Łukasz Kałużny: W niektórych scenariuszach może się okazać, że punktem wejścia do naszego rozwiązania będzie właśnie workflow w Logic Apps…
Marek Grabarz: I odwrotnie: to nie agent odpala workflow, tylko workflow woła agenta.
Łukasz Kałużny: Dokładnie, woła agenta i na podstawie wyników robi dalej coś przewidywalnego. Może się też zdarzyć, i w pokazywanym środowisku to całkowicie normalne, że kanałem dostępowym będzie integracja z poziomu iPaaS, czyli Logic Apps.
21:42 Connected agents zamiast A2A
Marek Grabarz: To podsuwa mi kolejny element, czyli A2A. Łukasz, czym jest A2A?
Łukasz Kałużny: Agent to agent, czyli komunikacja między agentami. To otwarty protokół zainicjowany przez Google'a. W kontekście AI Foundry on tam jest, ale…
Marek Grabarz: Pojawia się.
Łukasz Kałużny: Tak, ale nie przywiązywałbym się do niego tak bardzo, bo w 99% przypadków będziemy łączyć agentów w ramach naszego projektu. I teraz co jest ważne?
Marek Grabarz: Właśnie, kojarzy mi się drugie pytanie, związane z tym, co zacząłeś. Staramy się budować jednego wielkiego agenta czy takie mikroserwisowe agenty? Jak to wygląda?
Łukasz Kałużny: Nasze podejście, biorąc pod uwagę, jak działają modele językowe, jest takie: tworzymy małe, dedykowane agenty do konkretnych zadań, na przykład do konkretnego kawałka procesu biznesowego albo do rozwiązania konkretnego problemu. Żeby potem to przyspieszyć, mamy na przykład, nie nazwałbym go superagentem, tylko kawałek…
Marek Grabarz: Takiego agenta orkiestratora.
Łukasz Kałużny: Tak, dyrygenta, który wywołuje te mniejsze. Na przykład na większym agencie, który orkiestruje, może być droższy model z reasoningiem, a na tych malutkich na przykład GPT-4o mini, czyli tańszy model. Szukamy odpowiedniego doboru. Podsumowując: mniejsze agenty z tańszym modelem do bardzo konkretnych akcji i droższy model, który orkiestruje całym zadaniem. Dlaczego powiedziałem, żeby nie przywiązywać się tak do A2A, mimo że tam jest? Bo w większości przypadków nie robimy tak, że nasz proces przelatuje przez wielu agentów w sposób całkowicie niezależny, bo to trochę bajka dla dzieci. Realnie korzystamy ze scenariusza, który nazywamy connected agents: mamy centralnego agenta i te małe.
Marek Grabarz: Czyli świadomie orkiestrujemy kroki.
Łukasz Kałużny: Dokładnie. „Świadomie” to słowo klucz. W AI Foundry dosłownie mówimy: połącz mi tego agenta z tym.
Marek Grabarz: W tym kontekście.
Łukasz Kałużny: Tak, a tę akcję nazywamy hand off: agent na chwilę przekazuje wątek dalej, czeka na odpowiedź i przetwarza dalej.
Marek Grabarz: Mamy więc kanały dostępowe, platformę agentową i cały obszar integracji, który wystawia API i systemy źródłowe. Powiedz mi, jak to spiąć klamrą: jak to utrzymywać i automatycznie wdrażać?
24:36 Repozytorium i CI/CD dla agentów
Łukasz Kałużny: Wracamy do trzech środowisk, o których mówiliśmy: mamy sandbox, środowisko testowe, na którym sprawdzamy, czy wszystkie wdrożenia i integracje działają, i na końcu środowisko produkcyjne. W naszym podejściu chcemy to jak najbardziej uprościć, ale jednocześnie przenieść do tego świata praktyki inżynierskie z wytwarzania oprogramowania, bo one się pokrywają. Nie wymyślamy koła na nowo. Używamy po prostu kontroli wersji w postaci repozytorium Git: GitHub, Bitbucket, GitLab czy dowolne rozwiązanie Gitowe, które mamy w organizacji. Do tego w CI/CD mamy przygotowane skrypty do wdrażania agentów na poszczególne środowiska. Jeśli mówimy o wdrożeniu agenta do projektu, to jego reprezentacja w pliku w repozytorium zawiera podłączone integracje, podłączonych innych agentów i definicję samego agenta z system promptem.
Marek Grabarz: Jasne.
Łukasz Kałużny: Możemy na to patrzeć jak na manifest infrastructure as code. Albo, skoro w tym przypadku są to skrypty w Pythonie, ktoś zobaczy po prostu definicję agenta w kodzie Pythona, która mówi, jak ma zostać uruchomiony. Dlaczego mówimy o łatwości? Bo przy tej metodzie wdrażania, kiedy mamy taką platformę, często dochodzi wprost do kopiowania albo do użycia na przykład GitHub Copilota czy innego agenta kodującego, który pomaga we wdrożeniu.
Marek Grabarz: To już bardziej praktyka developerska. A jak z utrzymaniem? Automatyzację rozumiem. Wyobraźmy sobie jednak, że w agencie coś poszło krzywo albo ktoś przychodzi z roszczeniem, że agent źle mu odpowiedział. I co teraz?
26:54 Wątki, ewaluacja i content filtering
Łukasz Kałużny: Dlatego mówimy o observability. Mamy dwie rzeczy. Po pierwsze, samo AI Foundry: dopóki nie usuniemy danych, a to bardzo ważne, każdy agent ma w bazie przechowywane wątki całej rozmowy. Widzimy wejście i wszystkie wywołane narzędzia, czyli całą historię wywołań.
Marek Grabarz: Czyli treści tych wszystkich…
Łukasz Kałużny: Tak, treści wywołań, żądań do innych systemów, integracji czy agentów, i odpowiedzi. Dopóki tego nie skasujemy, wszystko jest dostępne. W interfejsie Azure AI Foundry Studio możemy wejść w wątek, zidentyfikować go, podejrzeć i zobaczyć, co się w nim znajduje. Dane są trzymane w usłudze stanowo. Wątek agenta jest więc rzeczą stanową: można do niego wrócić, obejrzeć go w playgroundzie i zaudytować, co się stało. To jeden element.
Marek Grabarz: Nasuwa mi się inna rzecz, która po części odpowiada na pytanie, dlaczego preferujemy model bring your own resources. Właśnie dlatego, że, jak sam powiedziałeś, te zasoby przechowują historię konwersacji. A historia konwersacji może zawierać dane wrażliwe i chronione, czy to w branży medycznej, farmaceutycznej, czy w bankowości. Po to mamy te zasoby przyniesione i wdrożone na własnych zasadach, z szyfrowaniem tak zwanymi kluczami CMK, czyli kluczami organizacji, żeby spełniały regulacje, które organizacja wcześniej wypracowała. To też istotna sprawa.
Łukasz Kałużny: Tak. Dostajemy więc wszystkie te informacje. Ciekawą rzeczą, która tam się znajduje i która rynkowo dopiero raczkuje, jest ocena jakości odpowiedzi agenta. Możemy mierzyć ewaluacje, patrzeć, jak wyglądają odpowiedzi, czy coś się nie zacięło. Zaczynają się pojawiać metryki, które pomagają obserwować pracę takiego…
Marek Grabarz: Rzeczywiście, w AI Foundry mamy cały obszar oceny jakości. To nie jest ocena z zewnątrz, tylko kolejny…
Łukasz Kałużny: Inny model.
Marek Grabarz: …model ewaluuje, czy w jego opinii cały przepływ został wykonany dobrze, czy źle.
Łukasz Kałużny: To istotne. Tylko, jak mówię, rynkowo dopiero raczkujemy z takim mierzeniem, bo rzecz niedeterministyczną mierzymy kolejną rzeczą niedeterministyczną.
Marek Grabarz: A monitoring jakości treści i zabezpieczenie przed tym, żeby użytkownicy nie wrzucili tam czegoś groźnego? To wciąż funkcjonuje, prawda?
Łukasz Kałużny: Tak, to jest od początku. Mamy content filtering, czyli filtrujemy treści i możemy regulować, na co pozwalamy.
Marek Grabarz: Co w niektórych firmach ma znaczenie. Niektóre firmy mogą albo chcą pozwolić sobie na pewne treści.
Łukasz Kałużny: Na przykład generowanie treści dla dorosłych w e-commerce, możemy sobie to wyobrazić…
Marek Grabarz: Możemy odpuścić pewne filtry.
30:05 Platforma czy pojedynczy agent i metryki sukcesu
Łukasz Kałużny: Tak, odpuścić pewne filtry. Podsumowując naszą rozmowę i patrząc na całość platformy, którą proponujemy: z naszego doświadczenia nie ma sensu budować pojedynczych agentów jako osobnych inicjatyw, traktowanych jako…
Marek Grabarz: Zgodziłbym się z Tobą i nie zgodził. Nie zgodziłbym się w tym sensie, że jeśli chcemy zrobić pierwszego agenta w firmie, pokazać zarządowi, że agent działa, i osiągnąć krótkoterminowy sukces, to pewnie w parę tygodni jesteśmy w stanie coś takiego zbudować. Jeśli jednak strategia firmy przewiduje, że agentów i API będzie coraz więcej, to platforma jest chyba jedynym kierunkiem, który ma sens.
Łukasz Kałużny: Tak, chodzi o to, żeby za każdym razem nie odkrywać koła na nowo, scentralizować wiedzę i skupić się, jak robimy to u kilku klientów, na testowaniu agentów, a nie na testowaniu kolejnych frameworków open source, które pojawiają się jak grzyby po deszczu i zmieniają sposób działania.
Marek Grabarz: To dość istotne. Z klientami praktykujemy też to, że zanim w ogóle wejdziemy w prace nad platformą, organizujemy warsztat i prosimy o przygotowanie przypadków biznesowych. Zapraszamy na przykład architektów biznesowych, niekoniecznie osoby od utrzymania, bo to jeszcze nie ten moment dyskusji. Mówimy: to są przypadki, które będą tu dobrze grać i dobrze się integrować. Mając 5, 10 czy 15 takich przykładów, zachęta do zbudowania platformy jest o wiele większa.
Łukasz Kałużny: Tak, to istotny element, żeby nie budować platformy dla samej platformy.
Marek Grabarz: Otóż to. Takie mamy podejście w Protopii: nie wdrażamy i nie wciskamy czegoś po to, żeby było i ładnie wyglądało, tylko po to, żeby było rzeczywiście używane. Jedną z naszych wewnętrznych metryk jest to, czy to, co wdrożyliśmy, jest w ogóle używane.
Łukasz Kałużny: To jedyna metryka, jaką można przyjąć przy takiej platformie i przypadkach agentowych: czy po zbudowaniu rozwiązanie jest wykorzystywane. Druga metryka, którą mamy: jak często ktoś na rozwiązanie narzeka. To też istotne przy agentach.
Marek Grabarz: Czy w ogóle do nas wraca?
Łukasz Kałużny: Nie, mówię o samym agencie. To metryka dla samego agenta: czy jest dużo reklamacji na sposób jego działania. Pochwalić nikt nie pochwali, ale narzekać będą. Narzekanie albo zgłoszenia błędów to rzecz, która się pojawia, i to dobra metryka, żeby zestawić ją z użyciem: ile razy coś było wykorzystane, a ile razy zgłaszano problemy albo powtarzające się problemy, na przykład z jakością odpowiedzi. Czyli z jednej strony nie spada użycie agenta albo rozwiązania agentowego, a z drugiej nie ma narzekania na jego jakość. W naszej opinii to jedyny skuteczny sposób, żeby zmierzyć zadowolenie z agenta.
Marek Grabarz: Jasne. Myślę, że powinniśmy podsumować. Poruszyliśmy chyba większość rzeczy dotyczących architektury. Mamy kanały dostępowe, mamy samych agentów i zautomatyzowaną platformę z wdrożeniami opartymi na kodzie. Mamy cały obszar integracji, który jest głównym klejem między agentami i czatami a naszymi niskopoziomowymi backendami. Całość staramy się wdrożyć na trzy środowiska. Pierwsze to miejsce na innowacje i eksperymenty. Jeśli coś przechodzi ten proces…
Łukasz Kałużny: …wychodzi z niego…
Marek Grabarz: …innowacyjno-inkubacyjny, staje się rozwiązaniem przedprodukcyjnym, z pełną integracją i przygotowaniem do wejścia na produkcję. Na koniec mamy produkcję poszczególnych agentów.
Łukasz Kałużny: Tak. W tym podejściu ważne jest jeszcze to, że jeśli inicjatywa zostanie zaakceptowana do testów w AI Sandboxie, to dosłownie następnego dnia roboczego zespół powinien mieć dostęp. Budujemy ten mechanizm tak, że, nie powiem, że to self-service, choć to też jest możliwe, ale na przykład zespół utrzymujący platformę dosłownie…
Marek Grabarz: …guzikiem przenosi.
Łukasz Kałużny: …w kilkanaście minut może udostępnić takie środowisko.
Marek Grabarz: Czyli chcesz powiedzieć, że nie trzeba przez miesiąc wypełniać różnych kwitów, żeby się w ogóle przenieść?
Łukasz Kałużny: Mówię o czasie od akceptacji, to inna rzecz. Procesy zostawmy. Skupiam się na części technicznej, nie operacyjnej: od strony technicznej, od momentu, gdy ktoś siądzie do pracy, wytworzenie nowego środowiska w tym ekosystemie to minuty. Tak oferujemy taką platformę.
Marek Grabarz: Dobrze, to chyba tyle na dzisiaj. Zapraszamy Was do zastanowienia się, jak takie platformy agentowe mogą wyglądać w Waszych firmach i jaką wartość przyniosą na koniec dnia Waszej organizacji. Zapraszamy też na kolejne nagrania. Pewnie na inny temat, ale nadal będzie ciekawie i inspirująco. Dzięki.
Łukasz Kałużny: Dzięki.
Marek Grabarz: Do usłyszenia.
