# #3 Nauka Premium — Architektura Multi-Agent w Copilot Studio Cześć! Tym odcinkiem będę chciał zapoczątkować serię odcinków dotyczących Copilot Studio. Tym bardziej, że w ostatnim czasie pojawił się też nowy widok w Copilot Studio i zupełnie zmienił sposób postrzegania budowania agentów. W tym odcinku chciałbym opowiedzieć w jak najprostszy sposób, w jaki sposób podchodzić do budowy agentów, do skalowania tych rozwiązań, do korzystania z wzorców — nawet nie w kontekście Copilot Studio, tylko w kontekście rozumienia w ogóle agentyczności: czym te agenty są, jakie dają możliwości w kontekście skalowania procesów biznesowo. Przygotowałem trzy krótkie infografiki, układając je w kolejności od najprostszych rozwiązań. ## Podstawowy agent Zacznę od budowy takiego podstawowego agenta. Mówię o agencie nie mówię o procesie agentycznym, czyli o agencie w rozumieniu biznesowym — czegoś, co zaczyna się obecnie od interfejsu wejścia w formie chatu. W takim rozwiązaniu jest jakiś interfejs wejściowy — jest to chat. W przypadku Copilot Studio na przykład jest to publikowane w kanale Teams, może to być chat dostępny w przeglądarce, gdziekolwiek. Użytkownik pisze do takiego chatu w języku naturalnym, i z tego interfejsu idzie pewna informacja do agenta, który tam w tle sobie chodzi. Czym jest ten agent AI w takiej budowie koncepcyjnej? Ma w sobie pewną instrukcję systemową, która opisuje jego działanie — co on ma robić, jak ma się zachowywać, jak ma dobierać pewne rozwiązania pod kątem tego, co użytkownik napisał. Wyobraźmy sobie agenta, który jest asystentem firmie i ma rozpoznać, jaki jest problem i wysłać e-mail do odpowiedniego działu. Agent ma też tools — narzędzia, które realnie pozwalają na wykonanie jakiejś czynności. To nie są bazy wiedzy (to jest wiedza agenta), a tools to specyficzne narzędzia. W rozumieniu Copilot Studio toolem może być gotowa akcja wysyłki maila, toolem może być rozbudowany Power Automate, który coś wykonuje. Tak możemy rozumieć taką podstawową budowę agenta. ## Skills — warstwa umiejętności W całym tym zjawisku agentów pojawiło się pojęcie skills — umiejętności. Znów mamy pewien interfejs wejściowy, mamy agenta, mamy jakiś orkiestrator, czyli model językowy, który rozumie co napisał użytkownik, interpretuje to odpowiednio i wybiera, co chcemy zrobić. Pomiędzy tools, które przed chwilą pokazywałem, możemy też użyć skills. Skills możemy traktować jako system prompty, ale już z wiedzą bardziej domenową, bardziej szczegółową. To znaczy możemy sobie wyobrazić, że główny prompt już nie wskazuje, jakiego toola ma użyć, tylko wskazuje, do którego skilla powinien zajrzeć. Budując agenta IT, który ma odpowiadać na pytania z obszaru IT, to teraz dzięki temu, że mamy skills — w jednym agencie, który de facto będzie służył tylko do komunikacji wewnętrznej — możemy dołożyć różne skills z różnych domen organizacji. Może być dedykowany skill IT, skill kadr, skill logistyki. I teraz orkiestrator określa, czy ten użytkownik chciał bardziej dowiedzieć się z poziomu IT, czy bardziej z poziomu logistyki. Ten poziom skills pozwala nam na bardziej domenowy podział wiedzy. I dzięki temu możemy tutaj zrobić taki poziom gradacji — użytkownik napisał, że potrzebuje zamówić nowego laptopa. Agent początkowo szuka, który skill odpowiada za sprzęt IT. W skilu jest system prompt, który mówi: jeśli użytkownik pyta o sprzęt IT, to dopytaj użytkownika o treść zgłoszenia i parametry, a jak będziesz miał pełną wiedzę, to skorzystaj z odpowiedniego toola — na przykład zgłoszenia w JIRA lub systemie zgłoszeń organizacji. ## Architektura Multi-Agent A teraz przejdziemy sobie do jeszcze dalszego myślenia — w jaki sposób możemy skalować rozwiązania. Architektura multi-agent: z punktu widzenia użytkownika mamy pewien interfejs wejściowy, mamy agenta głównego. Ten agent główny ma jakiś system orkiestracji — system prompt, który opisuje, do którego podagenta powinien skierować, gdy użytkownik coś pyta. Już nie skill, tylko kolejny agent. Przykład promptu: „Jesteś głównym dyspozytorem — określ właściwy dział agenta". I mamy trzech domenowych agentów: agenta IT, agenta kadr, agenta logistyki. Wyobrażamy sobie, że w organizacji tworzone są mikroagenty z domenową wiedzą w danej dziedzinie. Tworzymy głównego agenta jako dyspozytora — spiąć całą komunikację w jeden ekosystem. Podpinamy pod to agentów domenowych, nie skills, tylko agentów. Daje nam to większą skalowalność rozwiązania o jeszcze jeden poziom. Bo teraz te agenty znowu mają pewien system prompt, znowu mają określone z jakich skills mogą korzystać w środku i skills z jakich mogą korzystać tools. Może być nawet tool wspólny — na przykład jeden tool do wysyłania maili, niezależnie skąd skorzystamy. ## Dlaczego multi-agent a nie skills? Produktem z punktu widzenia developmentu jest agent, jeden agent. Rozbudowanie rozwiązania wiąże się z tym, że jeden zespół prawdopodobnie będzie musiał wziąć odpowiedzialność i w jakiś sposób tym zarządzać. W momencie, gdy idziemy w multi-agentyczność, rozdajemy domenowo odpowiedzialności po zespołach i każdy zespół pilnuje swojego agenta, dba o niego jakościowo. A główny agent jest tylko i wyłącznie pewnym orkiestratorem — nie robi nic niezwykłego, tylko kieruje do konkretnego agenta, który już ma robić coś specyficznego. Taki podział, taka segmentacja pozwala nam na lepszą skalowalność i budowanie właśnie takiego ekosystemu multi-agentów w organizacji. Celowo za dużo nie opowiadałem tu o Copilot Studio — chciałem pokazać same wzorce, bo niezależnie od tego, w jakim frameworku będziemy pracować, wygląda to podobnie. Warto to rozumieć, żeby wiedzieć jak dobierać rozwiązania. Mam nadzieję, że ten odcinek pozwolił wam zrozumieć lepiej budowę i architekturę tych rozwiązań — czym są skills, czym są tools, czym jest multi-agentyczność. Postaram się w następnych odcinkach przybliżyć te konkretne zagadnienia w kontekście już technologii Copilot Studio. Dzięki za dzisiaj.