W poprzednim odcinku Premium zbudowaliśmy jednego autonomicznego agenta. Ale co gdy jeden agent nie wystarczy — gdy zadanie jest zbyt szerokie, żeby jeden model mógł obsłużyć je dobrze? Tutaj wchodzi architektura multi-agent: wiele agentów AI, z których każdy jest wyspecjalizowany w swoim obszarze, a jeden z nich koordynuje całość.

Problem z jednym agentem do wszystkiego

Jeden agent z bardzo szeroką instrukcją i wieloma narzędziami ma tendencję do błądzenia — model próbuje obsłużyć zbyt dużo naraz i popełnia błędy tam, gdzie wyspecjalizowany agent by sobie poradził. Poza tym: jeden duży agent trudno testować i aktualizować, bo zmiana w jednym miejscu wpływa na całe zachowanie.

Architektura multi-agent rozwiązuje to przez podział odpowiedzialności — jak w dobrze zorganizowanym zespole ludzkim.

Wzorzec Orchestrator + Sub-agents

Najpopularniejszy wzorzec w Copilot Studio:

  • Orchestrator agent — przyjmuje zadanie od użytkownika lub systemu, analizuje je i deleguje do właściwego sub-agenta. Sam nie wykonuje operacji biznesowych, tylko zarządza przepływem.
  • Sub-agents (agenci wyspecjalizowani) — każdy odpowiada za konkretny obszar: agent HR, agent Zamówień, agent Raportowania. Mają własną bazę wiedzy, własne narzędzia i własne instrukcje skrojone pod ich domenę.

Orchestrator „rozmawia" z sub-agentem — przekazuje mu zadanie i odbiera wynik — tak jak manager deleguje pracę do specjalisty.

Jak to zrealizować w Copilot Studio

Copilot Studio udostępnia mechanizm Agent Transfer — akcja, w której jeden agent przekazuje rozmowę (wraz z kontekstem) do innego agenta. Konfiguracja:

  1. Stwórz sub-agentów z ich własną konfiguracją (instrukcja, baza wiedzy, narzędzia).
  2. W orchestratorze dodaj narzędzie (tool) typu „Talk to agent" wskazujące na konkretnego sub-agenta.
  3. W instrukcji orchestratora opisz, kiedy i do którego sub-agenta delegować — model sam zadecyduje na podstawie treści żądania.

Kiedy sub-agent zwraca wynik

Po zakończeniu zadania sub-agent może zwrócić wynik do orchestratora lub bezpośrednio do użytkownika — zależnie od konfiguracji. W większości scenariuszy sub-agent odpowiada użytkownikowi bezpośrednio, a orchestrator monitoruje całość i przejmuje, gdy zadanie wymaga koordynacji między kilkoma sub-agentami.

Praktyczny przykład — agent HR

Wyobraź sobie firmowego chatbota HR dostępnego dla pracowników:

  • Orchestrator: Agent HR — przyjmuje pytania od pracowników.
  • Sub-agent: Urlopy — obsługuje wnioski urlopowe, sprawdza stan dni, aktualizuje kalendarz.
  • Sub-agent: Onboarding — prowadzi nowych pracowników przez proces wdrożenia, odpowiada na pytania i tworzy zadania.
  • Sub-agent: Wynagrodzenia — odpowiada na pytania o paski, koryguje dane, eskaluje do działu płac.

Pracownik pisze jedno zdanie do jednego chatbota — a ten sam dekyduje, który specialist odpowie.

Zalety architektury multi-agent

  • Lepsza jakość odpowiedzi — wyspecjalizowany agent z wąską instrukcją i dedykowaną bazą wiedzy jest dokładniejszy niż jeden agent próbujący wiedzieć wszystko.
  • Łatwiejsze utrzymanie — aktualizujesz sub-agenta odpowiedzialnego za urlopy bez dotykania reszty systemu.
  • Skalowalność — dodajesz nowego sub-agenta bez przebudowy całości.
  • Bezpieczeństwo — każdy sub-agent może mieć swój zakres dostępu do danych.

Kiedy multi-agent, a kiedy jeden agent

Jeden agent wystarczy gdy: problem jest wąski i dobrze zdefiniowany, liczba narzędzi jest mała (3–5), obszar wiedzy jest jednorodny. Jeśli przekraczasz te granice — multi-agent zaczyna dawać wyraźne korzyści. Zacznij prosto, skaluj gdy widzisz, że jeden agent nie daje rady.