Jak stworzyć firmowy katalog agentów i narzędzi AI?

Gdy firma uruchamia pierwszego asystenta AI, zwykle wiadomo, kto go stworzył, z jakich danych korzysta i do czego służy. Po kilku miesiącach pojawiają się kolejne agenty, serwery MCP, skille, API i automatyzacje. Część działa tylko w jednym zespole, część powiela istniejące funkcje, a część nadal jest widoczna mimo utraty właściciela lub aktualności.

Wtedy problemem przestaje być samo zbudowanie narzędzia. Trudniejsze staje się ustalenie, który zasób jest zatwierdzony, aktualny i właściwy dla konkretnego zadania.

Firmowy katalog pomaga znaleźć odpowiedź, ale nie powinien być tylko listą linków. Musi łączyć opis biznesowy z zasadami odpowiedzialności, dostępu i cyklu życia.

Zacznij od problemu, nie od technologii

Nie twórz katalogu wyłącznie dlatego, że pojawił się nowy standard lub produkt. Najpierw sprawdź, czy w firmie występują objawy braku wspólnej ewidencji:

• zespoły budują podobne narzędzia niezależnie od siebie;
• użytkownicy nie wiedzą, który agent jest wersją obowiązującą;
• nie da się szybko wskazać właściciela integracji;
• zasoby pozostają dostępne po zakończeniu projektu;
• opis funkcji nie mówi, do jakich danych i działań narzędzie ma dostęp;
• ocena bezpieczeństwa jest powtarzana od początku przy każdym wdrożeniu;
• zmiana nazwy, adresu albo wersji zrywa wcześniejsze konfiguracje.

Jeśli firma ma dwa proste narzędzia obsługiwane przez jedną osobę, arkusz może wystarczyć. Rozbudowany katalog ma sens wtedy, gdy liczba zasobów, zespołów i środowisk zaczyna utrudniać wybór oraz nadzór.

Co właściwie powinno znaleźć się w katalogu?

Agentic Resource Discovery, czyli ARD, definiuje otwarty sposób wyszukiwania zasobów agentowych. Za taki zasób uznaje między innymi agenta, serwer MCP, skill, API lub przepływ pracy. Klient AI może zapytać usługę wyszukiwania, co jest dostępne dla danego zadania, a następnie otrzymać pasujące opisy.

To użyteczny model myślenia, nawet jeśli firma nie wdraża tej specyfikacji. Każdy wpis w wewnętrznym katalogu powinien zawierać co najmniej:

• nazwę i krótki opis zrozumiały dla użytkownika biznesowego;
• problem lub zadanie, które zasób rozwiązuje;
• właściciela biznesowego i technicznego;
• grupę użytkowników, dla której jest przeznaczony;
• dane wejściowe i rodzaj wyniku;
• systemy, z którymi się łączy;
• wymagane uprawnienia;
• dozwolone i zabronione klasy danych;
• środowisko, wersję i sposób wywołania;
• status: roboczy, w przeglądzie, zatwierdzony, ograniczony albo wycofany;
• datę ostatniej kontroli i termin następnego przeglądu.

Bez tych informacji wyszukiwarka może znaleźć zasób, ale użytkownik nadal nie wie, czy wolno mu go użyć i kto odpowiada za jego działanie.

Oddziel znalezienie zasobu od jego uruchomienia

To najważniejsza granica całego rozwiązania. ARD działa przed wywołaniem zasobu. Specyfikacja pomaga go odkryć i opisać, ale nie jest środowiskiem wykonawczym, nie zastępuje MCP ani API i nie nadaje sama w sobie prawa dostępu.

W firmie warto rozdzielić trzy kroki:

1. Odkrywanie — które zasoby pasują do zadania?
2. Autoryzacja — czy ten użytkownik lub agent może skorzystać z wybranego zasobu w danym kontekście?
3. Wykonanie — jak narzędzie zostanie wywołane, ograniczone i zapisane w historii?

Agent może więc zobaczyć, że istnieje narzędzie do tworzenia zamówień, ale nie powinien automatycznie otrzymać prawa do złożenia zamówienia. Dostęp musi nadal wynikać z tożsamości, roli, polityki danych i limitów działania.

Wprowadź proces zgłaszania i zatwierdzania

Samo automatyczne wykrycie nowych narzędzi może szybko zamienić katalog w kolejną nieuporządkowaną listę. Potrzebny jest prosty przepływ odpowiedzialności.

AWS opisuje wzorzec rejestru, w którym wydawca zgłasza rekord, kurator go zatwierdza lub odrzuca, a nieaktualny zasób może zostać wycofany z wyszukiwania. Firma może zastosować podobny proces niezależnie od wybranej platformy:

1. twórca lub właściciel zgłasza zasób wraz z wymaganymi metadanymi;
2. osoba techniczna sprawdza sposób integracji, wersję i zależności;
3. właściciel danych potwierdza zakres dostępu;
4. właściciel procesu ocenia zastosowanie biznesowe i ryzyko;
5. kurator nadaje status i określa datę ponownego przeglądu;
6. dopiero zatwierdzony wpis staje się widoczny dla właściwej grupy odbiorców.

Nie każdy zasób wymaga równie rozbudowanej kontroli. Narzędzie tylko do odczytu publicznych informacji może przejść krótszą ścieżkę niż agent zmieniający dane klienta lub uruchamiający płatność.

Opisuj możliwości językiem zadania

Użytkownik rzadko szuka „serwera MCP do systemu X”. Częściej pyta: „które narzędzie porówna oferty?”, „co przygotuje projekt umowy?” albo „jak znaleźć przyczynę błędu?”.

Microsoft opisał 25 sierpnia 2026 funkcję inteligentnego wyszukiwania w swoim marketplace, w której użytkownik przedstawia problem naturalnym językiem, otrzymuje rekomendacje i porównuje rozwiązania. To ogłoszenie produktowe dostawcy, ale dobrze pokazuje trwałą zasadę: katalog jest użyteczny wtedy, gdy łączy potrzeby biznesowe z opisem możliwości, a nie wymaga znajomości nazw produktów.

Dlatego pole „zastosowanie” powinno zawierać konkretny cel, ograniczenia i przykładowe pytania. Hasło „agent analityczny” jest zbyt szerokie. Lepszy opis to: „porównuje zatwierdzone oferty dostawców na podstawie ceny, terminu i warunków gwarancji; nie składa zamówień”.

Nie mieszaj rankingu z zatwierdzeniem

Wynik wyszukiwania może zależeć od dopasowania semantycznego, popularności, świeżości albo preferencji zespołu. Żadne z tych kryteriów nie dowodzi bezpieczeństwa.

Katalog powinien osobno pokazywać:

• zgodność z opisem zadania;
• status zatwierdzenia;
• zakres dostępu;
• właściciela i aktualność;
• ograniczenia oraz znane ryzyka.

Najwyżej oceniony wynik nie zawsze jest właściwy. Agent do analizy pełnych danych finansowych może lepiej pasować funkcjonalnie, ale użytkownik bez odpowiednich uprawnień powinien otrzymać wariant działający na danych zagregowanych.

Zaplanuj wycofywanie, zanim pojawi się pierwszy problem

Katalog bez zarządzania cyklem życia szybko traci wiarygodność. Każdy wpis powinien mieć właściciela i termin przeglądu. Brak potwierdzenia nie musi od razu usuwać narzędzia, ale powinien zmienić jego status lub ukryć je przed nowymi wdrożeniami.

Przy wycofywaniu sprawdź:

• kto i które procesy nadal korzystają z zasobu;
• czy istnieje zatwierdzony następca;
• kiedy można zablokować nowe użycia;
• jak poinformować właścicieli zależnych procesów;
• jak zachować historię wersji i decyzji;
• kiedy odebrać dane dostępowe i uprawnienia.

Nie usuwaj wpisu bez śladu. Informacja, że zasób został wycofany i czym go zastąpiono, chroni przed ponownym wdrożeniem starego rozwiązania.

Jak zacząć mały pilotaż?

Pierwsza wersja nie musi być automatyczną, federacyjną wyszukiwarką. Zacznij od jednego obszaru i kilkunastu zasobów.

Praktyczny pilotaż może wyglądać tak:

1. zinwentaryzuj agentów, skille, API i automatyzacje jednego zespołu;
2. uzupełnij obowiązkowe pola oraz właścicieli;
3. oznacz zasoby zatwierdzone i wymagające przeglądu;
4. zdefiniuj trzy do pięciu typowych pytań użytkowników;
5. sprawdź, czy katalog zwraca właściwe wyniki i pokazuje ograniczenia;
6. przeprowadź próbę odebrania dostępu oraz wycofania starej wersji;
7. zmierz czas znalezienia i zatwierdzenia narzędzia przed pilotażem i po nim.

Dopiero później warto automatyzować publikowanie rekordów, wyszukiwanie naturalnym językiem lub federację między wieloma katalogami.

Najważniejsza zasada

Firmowy katalog agentów i narzędzi AI ma pomagać wybierać zasoby, którym można zaufać w określonym kontekście. Widoczność nie jest uprawnieniem, a dobre dopasowanie nie jest zatwierdzeniem.

Zacznij od właściciela, przeznaczenia, danych, uprawnień i cyklu życia. Jeśli te elementy są jawne, firma może szybciej korzystać z istniejących rozwiązań, ograniczać duplikaty i wycofywać nieaktualne narzędzia bez zgadywania, gdzie są używane.