Istotna aktualizacja: 2 września 2026
MCP i A2A rozwiązują dwa różne problemy. Model Context Protocol opisuje, jak aplikacja AI korzysta z narzędzi, zasobów i gotowych promptów. Agent2Agent Protocol służy do współpracy niezależnych agentów: odkrywania ich kompetencji, przekazywania zadań, śledzenia stanu i odbierania artefaktów. Próba zastąpienia jednego protokołu drugim prowadzi albo do traktowania złożonego agenta jak pojedynczej funkcji, albo do budowania kosztownej orkiestracji tam, gdzie wystarczyłoby wywołanie narzędzia.
Chronologia wymaga korekty względem pierwotnego szkicu. Google ogłosił A2A 9 kwietnia 2025 roku, projekt trafił do Linux Foundation w czerwcu, a stabilne A2A v1.0 wydano 12 marca 2026 roku. Dla MCP istotną bazą jest rewizja specyfikacji z 25 listopada 2025 roku. Na tej podstawie można projektować interoperacyjność, ale zgodność komunikatów nie zastępuje decyzji o zaufaniu, odpowiedzialności i skutkach biznesowych.
Narysuj granicę między agentem a narzędziem
Pierwszy artefakt architektoniczny powinien pokazywać, co w danym procesie jest agentem, a co narzędziem. Narzędzie ma zwykle wąski kontrakt, przewidywalne wejście i wynik oraz nie prowadzi samodzielnie wieloetapowej rozmowy. Agent może planować, używać kilku narzędzi, utrzymywać kontekst zadania, prosić o dodatkowe dane i zwracać wynik w późniejszym czasie.
Oficjalne porównanie A2A i MCP ujmuje tę granicę bez marketingowego skrótu: MCP łączy agenta z narzędziami i zasobami, a A2A umożliwia współpracę agentów jako równorzędnych, często nieprzezroczystych systemów. W typowym układzie agent rozmawia z innym agentem przez A2A, a wewnątrz własnej domeny korzysta z baz danych lub API przez MCP.
Nie każda usługa z modelem językowym powinna więc zostać agentem A2A. Jeśli operacja ma być atomowa, bezstanowa i łatwa do powtórzenia, interfejs narzędziowy będzie prostszy do zabezpieczenia i testowania. A2A ma sens, gdy druga strona zachowuje autonomię wykonania, potrzebuje cyklu życia zadania albo nie może ujawnić swoich wewnętrznych narzędzi.
Utrzymuj katalog wersjonowanych kontraktów
Każdy agent wystawiony w firmie powinien mieć właściciela, domenę zaufania i wpis w katalogu. Wpis obejmuje adres Agent Card, obsługiwane wersje i bindingi A2A, deklarowane skills, klasy danych, wymagane mechanizmy uwierzytelniania, limity operacyjne oraz ścieżkę eskalacji. Dla serwerów MCP analogiczny katalog powinien przechowywać wersję serwera, dostępne tools, resources i prompts, właściciela schematu oraz zasady wycofywania funkcji.
Agent Card jest opisem możliwości, nie dowodem, że wolno z nich skorzystać. Klient powinien pobierać karty tylko z zatwierdzonych lokalizacji, weryfikować podpis, gdy jest dostępny, i stosować własną politykę dopuszczenia. Publiczna karta nie może zawierać sekretów ani wewnętrznych szczegółów, które zwiększają powierzchnię ataku.
Zmiana opisu, schematu danych albo semantyki skill może złamać proces mimo poprawnej komunikacji sieciowej. Zespół potrzebuje testów kontraktowych i okresu migracji dla konsumentów. Wersjonowanie należy wiązać z zachowaniem, nie tylko z numerem biblioteki SDK.
Zaprojektuj pełny cykl życia zadania
A2A definiuje między innymi Message, Task, Artifact i zdarzenia statusu. Architektura biznesowa musi dodać do nich reguły ponawiania, anulowania, deduplikacji i retencji. Klient powinien wiedzieć, czy brak odpowiedzi oznacza, że zadanie nie wystartowało, nadal trwa czy zakończyło się bez dostarczenia wyniku.
Każde działanie wywołujące skutek potrzebuje identyfikatora idempotencji lub innego mechanizmu zapobiegania duplikatom. Ponowienie żądania odczytu jest inne niż ponowienie zlecenia płatności, publikacji albo modyfikacji konta. Stan completed powinien oznaczać zakończenie jasno zdefiniowanego kontraktu, a nie tylko brak dalszej pracy agenta.
Artefakt trzeba traktować jak dane z zewnętrznego systemu. Powinien mieć typ, wersję schematu, pochodzenie, klasyfikację, sumę kontrolną tam, gdzie ma to znaczenie, oraz zasady ważności. Tekstowa odpowiedź agenta nie może być automatycznie interpretowana jako autoryzowana instrukcja wykonawcza.
Rozdziel tożsamość, delegację i zgodę
A2A deklaruje wymagania uwierzytelniania w Agent Card, ale pozyskanie poświadczeń odbywa się poza semantyką zadania. Serwer musi uwierzytelnić każde żądanie i sam podjąć decyzję autoryzacyjną dla skill, działania i danych. Nie należy utożsamiać poprawnej tożsamości agenta z prawem do wykonania wszystkiego, co potrafi opisać.
W komunikacji MCP przez HTTP aktualna specyfikacja authorization wymaga między innymi discovery chronionego zasobu oraz użycia Resource Indicators, aby token był przeznaczony dla konkretnego serwera. Zabrania również przekazywania otrzymanego tokenu bez zmian do kolejnego API. Serwer MCP, który wywołuje usługę downstream, powinien uzyskać osobne poświadczenie dla tej relacji.
Delegacja użytkownika wymaga zachowania dwóch informacji: kto zainicjował proces i jaki agent faktycznie wykonał czynność. Operacje podwyższonego ryzyka powinny mieć ograniczony zakres, krótki czas ważności oraz zgodę odnoszącą się do skutku — na przykład wysłania konkretnego zamówienia — a nie ogólną zgodę na „działanie agenta”.
Traktuj wynik narzędzia jako nieufne wejście
Agent może otrzymać instrukcję z dokumentu, strony, issue, odpowiedzi API lub innego agenta. Protokół zapewnia format wymiany, ale nie rozstrzyga, czy treść jest prawdziwa i bezpieczna. Każda granica MCP i A2A jest zatem granicą walidacji: schemat, rozmiar, typ zawartości, klasyfikacja danych, dopuszczalne odwołania i reguły wykonywania.
Narzędzia zmieniające stan powinny być oddzielone od odczytowych, a niebezpieczne parametry powinny przechodzić walidację niezależną od modelu. Dla operacji nieodwracalnych potrzebny jest etap przygotowania i jawnego zatwierdzenia. Agent może zbudować propozycję wraz z przewidywanym skutkiem, lecz zatwierdzenie powinno trafić do kontrolowanego komponentu polityki albo uprawnionego człowieka.
Warto projektować bezpieczny tryb degradacji. Gdy agent partnerski, model lub serwer MCP jest niedostępny, proces powinien zatrzymać się, przejść do kolejki manualnej albo ograniczyć funkcję zgodnie z wcześniej podjętą decyzją. Automatyczne przełączenie na inny model lub agent bez ponownej oceny uprawnień może zmienić granicę zaufania.
Mierz interoperacyjność na awariach, nie na demo
Test „happy path” potwierdza niewiele. Zestaw zgodności powinien obejmować nieobsługiwaną wersję, nieznany skill, odrzuconą autoryzację, wygasły token, duplikat żądania, anulowanie w trakcie pracy, przerwane streamowanie, spóźniony webhook, błędny artefakt i niedostępność zależnego narzędzia. Wynik ma wskazywać nie tylko kod błędu, ale również to, czy proces pozostawił skutek częściowy.
Operacyjnie warto śledzić ukończenie według końcowego stanu, czas poszczególnych handoffów, liczbę ponowień, odsetek odrzuceń polityki, duplikaty skutków, zadania wymagające człowieka oraz przypadki, w których nie dało się ustalić pełnego pochodzenia akcji. Metryki powinny prowadzić do właściciela kontraktu, a log audytowy łączyć inicjatora, tożsamość workloadu, Agent Card i wersję narzędzia.
Interoperacyjność staje się zdolnością operacyjną dopiero wtedy, gdy nowego agenta można podłączyć bez negocjowania wyjątków w każdym systemie, a jego awarię można ograniczyć i wyjaśnić. Sam sukces dwóch połączonych demonstracji tego nie dowodzi.
Przypisz ownership na każdej granicy
Zespół domenowy odpowiada za semantykę skilla i wynik biznesowy. Zespół tożsamości odpowiada za wydawanie poświadczeń i federację domen zaufania. Platforma utrzymuje discovery, bramy, obserwowalność oraz wspólne kontrole w SDK. Security definiuje zasady dopuszczenia i wykonania akcji, a właściciel produktu wskazuje miejsca wymagające decyzji człowieka.
Centralny zespół nie powinien ręcznie pośredniczyć w każdym połączeniu agentów. Jego rolą jest katalog, silnik polityk, kontrakty referencyjne, testy kompatybilności i mechanizm obsługi incydentów. Właściciele domen pozostają wtedy odpowiedzialni za to, co ich agenci obiecują i wykonują. Standard nie może służyć do rozmycia odpowiedzialności.
Źródła
- Announcing the Agent2Agent Protocol — Google Developers Blog, 9 kwietnia 2025.
- Linux Foundation Launches the Agent2Agent Protocol Project — Linux Foundation, 23 czerwca 2025.
- A2A Protocol Ships v1.0 — A2A Protocol, 12 marca 2026.
- A2A and MCP: Detailed Comparison — A2A Protocol, stan na 2 września 2026.
- MCP Authorization, revision 2025-11-25 — Model Context Protocol, 25 listopada 2025.