LinkedIn stworzył opartą na Model Context Protocol warstwę wiedzy organizacyjnej dla agentów programistycznych. W prezentacji opublikowanej przez InfoQ 19 września 2026 roku Ajay Prakash opisał system Contextual Agent Playbooks and Tools, któremu przypisano wzrost produktywności o 20% bez spadku niezawodności.
Dlaczego sam dostęp do modelu i terminala nie wystarczył
Ajay Prakash, software engineer w LinkedIn z 14-letnim doświadczeniem, wskazał skalę wewnętrznego środowiska jako główne ograniczenie agentów. Firma ma tysiące repozytoriów, mikrousług i aplikacji, a także własne bazy danych, systemy eksperymentów, obserwowalności oraz zarządzania konfiguracją. Nowi inżynierowie przechodzą ponad tygodniowy bootcamp i potrzebują kolejnych tygodni, aby sprawnie pracować z tym stosem.
Pierwsze asystenty programistyczne działały głównie jak inteligentne autouzupełnianie. Późniejszy tryb agentowy pozwolił im edytować wiele plików i wykonywać polecenia w terminalu. Na początku 2025 roku Andrej Karpathy określił pracę opartą na kolejnych poleceniach dla agenta jako vibe coding.
LinkedIn udostępnił narzędzia programistyczne wszystkim inżynierom, ale efekty nie spełniły oczekiwań. Agenci nie znali wewnętrznych frameworków ani przyjętych sposobów wprowadzania zmian. Tworzyli kod niskiej jakości lub halucynowali, a pracownicy musieli stale uzupełniać prompty i kontrolować przebieg pracy. Część z nich wróciła przez to do ręcznego programowania.
Co MCP zmienił w dostępie agentów do wiedzy
Możliwość rozszerzenia agentów pojawiła się wraz z Model Context Protocol, który Anthropic udostępnił jako otwarty standard łączenia modeli z narzędziami. LinkedIn najpierw opakował w MCP istniejącą wyszukiwarkę kodu. System indeksował kod z 1000 repozytoriów i obsługiwał słowa kluczowe, wyrażenia regularne oraz filtry języka i typu pliku.
Agent mógł dzięki temu znaleźć odpowiednie fragmenty kodu, a w razie potrzeby odczytać cały plik. Nie musiał już opierać się wyłącznie na publicznym kodzie użytym podczas trenowania modelu. Potrafił również wielokrotnie zmieniać zapytania, nawet jeśli użytkownik rozpoczął od ogólnego opisu w języku naturalnym.
LinkedIn podłączył następnie dokumentację, firmowe wiki, flagi funkcji, system zarządzania zadaniami i platformę danych. Sam dostęp do źródeł nadal jednak nie wystarczał przy złożonych zadaniach. Wiedza o instalowaniu zależności, kompilowaniu i testowaniu była rozproszona między dokumentami, wątkami w Slacku oraz doświadczeniem starszych inżynierów.
Kolejnym ograniczeniem było przepełnianie okna kontekstowego. Wyniki wywołań narzędzi zajmowały miejsce, a kompresja kontekstu usuwała część wcześniejszych ustaleń. Agent ponownie wykonywał wtedy te same operacje. Brak trwałej pamięci oznaczał również, że przy następnym podobnym zadaniu musiał zaczynać od początku, zużywając czas i tokeny.
Jak playbooki tworzą pamięć proceduralną organizacji
LinkedIn rozwiązał ten problem przez pamięć proceduralną, czyli zapis wiedzy o sposobie wykonania zadania. Firma nazwała takie pakiety playbookami. Każdy zawiera nazwę, opis i instrukcje, a agent wywołuje go przez MCP tak samo jak zwykłe narzędzie.
Przykładem jest playbook opisujący tworzenie potoków Airflow. Gdy inżynier prosi o przygotowanie takiego potoku, agent pobiera instrukcje i łączy je z wymaganiami przekazanymi przez użytkownika. Każdy pracownik LinkedIn może utworzyć playbook i umieścić go w centralnym repozytorium, udostępniając wiedzę pozostałym zespołom.
- Jedno zadanie. Playbook powinien być samodzielny i opisywać konkretną czynność zamiast kilku niezależnych procesów.
- Kompozycja. Długie procedury mogą odwoływać się do mniejszych playbooków, które da się wykorzystać w wielu scenariuszach.
- Stopniowe ujawnianie kontekstu. Agent pobiera procedury pomocnicze dopiero wtedy, gdy rzeczywiście ich potrzebuje.
- Aktualizacja wiedzy. Agent może wskazać nieaktualne instrukcje, opisać przypadki brzegowe i zaproponować zmianę playbooka.
Instrukcja systemowa zachęca agentów do podsumowania nowych ustaleń po zakończeniu sesji. Mogą one także pobrać kod playbooka i przygotować jego aktualizację do zatwierdzenia. W ten sposób LinkedIn buduje graf powiązanych procedur, po którym agent porusza się podczas coraz dłuższych zadań.
Jak architektura MCP skaluje katalog do tysięcy pozycji
LinkedIn korzysta z jednego lokalnego serwera MCP, który udostępnia narzędzia oraz playbooki. Procedury centralne dotyczą wielu repozytoriów, natomiast lokalne znajdują się w konkretnym repozytorium i trafiają do kontekstu tylko podczas pracy w odpowiednim katalogu. Serwer rozpoznaje bieżący obszar roboczy i wczytuje dostępne tam instrukcje.
Narzędzia łączące się z systemami firmy wymagają uwierzytelnienia. Przy pierwszym użyciu warstwa autoryzacji uruchamia zwykle przepływ OAuth, zapisuje token w bezpiecznym magazynie kluczy, a później odświeża go podczas kolejnych wywołań. Serwer jest instalowany na laptopach LinkedIn i sprawdza aktualizacje co godzinę. Nowe narzędzia przechodzą kontrolę InfoSec.
Bezpośrednie udostępnienie dużego katalogu agentowi szybko zużywałoby okno kontekstowe. Według Prakasha przekroczenie około 30 narzędzi spowalnia agentów i pogarsza ich działanie. LinkedIn zastąpił więc pełną listę trzema funkcjami: wyszukiwaniem narzędzi i playbooków, pobieraniem schematu wybranego narzędzia oraz jego wykonaniem.
Agent najpierw przeszukuje katalog na podstawie słów kluczowych, domen i rodzaju działania. Następnie odczytuje nazwę i opis wybranej pozycji, pobiera wymagane argumenty, a dopiero potem uruchamia narzędzie. Taki mechanizm pozwala obsłużyć tysiące pozycji bez umieszczania ich pełnych definicji w kontekście modelu.
Jakie efekty i zabezpieczenia opisał LinkedIn
Prakash przedstawił przykład obsługi alarmu dotyczącego wzrostu opóźnień. Agent pobiera instrukcje diagnostyczne, analizuje logi, metryki, wdrożenia i ostatnie zmiany, a następnie przechodzi do zależnej usługi. Po wykryciu wadliwej zmiany w kodzie przygotowuje opis przyczyny oraz sugerowane działania.
Inżynier musi potwierdzić ustalenia przed wykonaniem czynności naprawczych. Po akceptacji agent może ograniczyć skutki awarii, zaktualizować system zarządzania incydentami, przygotować raport i utworzyć pull request z poprawką. Według prezentacji taki proces trwa kilka minut zamiast kilku godzin.
LinkedIn miał ponad 600 podobnych przepływów oraz tysiące narzędzi. Opis prezentacji mówi o 20-procentowym wzroście produktywności bez utraty niezawodności, ale nie podaje metodologii pomiaru, okresu badania ani kosztów wdrożenia i utrzymania platformy.
Dla polskich firm główny wniosek dotyczy jakości kontekstu, a nie samego wyboru modelu językowego. Organizacje z własnymi frameworkami i rozproszoną dokumentacją mogą potrzebować zarządzanej warstwy procedur, kontroli dostępu oraz procesu zatwierdzania zmian, zanim powierzą agentom zadania produkcyjne.
