Protokół Agent-to-Agent (A2A)

Czym jest protokół Agent-to-Agent (A2A)?

Protokół Agent-to-Agent (A2A) to otwarty standard określający, jak autonomiczni agenci AI komunikują się ze sobą ponad granicami procesów, systemów, platform i producentów. Podczas gdy pojedynczy agent korzysta z narzędzi, danych i systemów zewnętrznych za pośrednictwem Model Context Protocol (MCP), A2A reguluje warstwę wyżej: współpracę między niezależnymi agentami. Kluczowy krok koncepcyjny A2A polega na tym, że protokół definiuje, jak agenci ze sobą rozmawiają, a nie jak myślą. Wewnętrzna logika zdalnego agenta (prompty, model, pamięć) pozostaje nieprzejrzysta. Właśnie dzięki temu na przykład agent Salesforce może wywołać agenta SAP, a żadna ze stron nie musi ujawniać swoich wewnętrznych struktur.

A2A zaprezentowano w kwietniu 2025 roku na konferencji Google Cloud Next z udziałem ponad 50 partnerów; początkowo jego rozwój napędzało Google. Już 23 czerwca 2025 roku Google przekazało specyfikację, SDK (Python, TypeScript) i narzędzia deweloperskie organizacji Linux Foundation. Tym samym A2A nie jest już standardem jednego producenta, lecz otwartym standardem zarządzanym neutralnie wobec producentów. To ważny argument dla decydentów, którzy oceniają długoterminową niezależność od platform.

Komunikacja między agentami: rdzeń techniczny

A2A celowo opiera się na sprawdzonych standardach webowych, aby obniżyć próg wejścia dla firm. Najważniejsze elementy:

• Transport. JSON-RPC 2.0 przez HTTPS. Streaming odbywa się za pomocą Server-Sent Events (SSE); dla długotrwałych zadań przewidziano opcjonalne powiadomienia push.
• Cykl życia zadania. Zadania przechodzą przez zdefiniowane stany: submitted → working → input-required → completed | failed | canceled. Ten jawny cykl życia stanowi kontraktowy rdzeń relacji między dwoma agentami; jasno pokazuje, kiedy agent czeka na doprecyzowanie (input-required), a kiedy wynik jest gotowy.
• Wiadomości i artefakty. A2A obsługuje wiadomości wieloczęściowe (tekst oraz treści multimodalne, np. formularze). Wynikiem zadania jest jeden lub kilka artefaktów.
• Trzy tryby interakcji. Synchroniczny (pojedyncze żądanie/odpowiedź), asynchroniczny polling oraz streaming/push dla długotrwałych zadań.

Ta architektura pozwala udostępnić na zewnątrz wewnętrzny przepływ wieloagentowy (np. orkiestrację w LangGraph z trwałym stanem) jako endpoint A2A z AgentCard; warstwa wewnętrzna i zewnętrzna składają się w spójną całość.

Agent Cards i wykrywanie agentów

Sercem wykrywalności (discovery) w A2A jest AgentCard. Każdy agent publikuje dokument JSON, który opisuje:

• endpoint, pod którym agent jest dostępny,
• jego możliwości (capabilities) i obsługiwane umiejętności (skills),
• modalności (tekst, formularze, multimodalność),
• obsługiwane schematy uwierzytelniania.

Dzięki AgentCard agent wywołujący dowiaduje się, co potrafi inny agent i jak może się do niego zwracać, bez wglądu w jego implementację. W praktyce AgentCard jest więc kluczową dźwignią: jeśli dostawca opublikuje AgentCard dla każdego ze swoich agentów działających produkcyjnie, systemy klientów, takie jak Salesforce Agentforce, SAP Joule czy Microsoft Copilot Studio, mogą wywoływać tych agentów z własnego środowiska bez budowania integracji dedykowanej dla klienta.

Otwarta kwestia na 2026 rok: niektórzy producenci mają komercyjne powody, by wyposażać AgentCards we własnościowe rozszerzenia. Kluczowym sygnałem do obserwowania w kontekście przenośności A2A jest więc to, czy AgentCard pozostanie przenośnym dokumentem JSON, czy stanie się specyficzna dla danego producenta.

A2A vs MCP: protokoły komplementarne, a nie konkurencyjne

Najczęstsze pytanie tech leadów w Europie brzmi: „A2A czy MCP?” Odpowiedź wiodących dostawców (Google, Salesforce, Microsoft, IBM) jest jednoznaczna i spójna: oba, dla różnych warstw. Oficjalna formuła brzmi: „MCP odpowiada za możliwości (agent-to-tool). A2A odpowiada za współpracę (agent-to-agent).” Własne wytyczne Microsoftu dotyczące systemów wieloagentowych ujmują to operacyjnie: „Use MCP for tool and data access. Use Linux Foundation A2A for cross-platform agent-to-agent messaging.”

MCP bywa też wykorzystywany do komunikacji między agentami: agent jest wtedy udostępniany jako „serwer” MCP z możliwościami w formie narzędzi. To działa, ale MCP nie został do tego zaprojektowany. Google i Microsoft zalecają A2A do prawdziwej współpracy równorzędnych agentów. W konwergentnym stosie 2026 roku obowiązuje więc zasada: MCP jako standard warstwy narzędzi, A2A jako standard warstwy agentów.

Linux Foundation i konsolidacja krajobrazu protokołów

A2A znajduje się w centrum godnego uwagi procesu standaryzacji. Podczas przekazania projektu Linux Foundation 23 czerwca 2025 roku (Open Source Summit North America, Denver) członkami założycielskimi były AWS, Cisco, Google, Microsoft, Salesforce, SAP i ServiceNow; obecnie protokół wspiera ponad 100 firm (źródło: Linux Foundation, 2025). Repozytorium i kanoniczna dokumentacja znajdują się odpowiednio pod adresami github.com/a2aproject/A2A i a2a-protocol.org.

To połączenie sił skonsolidowało rozdrobniony krajobraz protokołów:

• ACP → A2A. Agent Communication Protocol (ACP, marzec 2025) firmy IBM został 29 sierpnia 2025 roku włączony do A2A w ramach LF AI & Data. Oficjalny blog LF: „the ACP team is winding down active development and contributing its technology and expertise to A2A.” Zasady projektowe ACP (REST, async-by-default) żyją dalej w A2A.
• AGNTCY jako nakładka. Projekt AGNTCY firmy Cisco (przekazany Linux Foundation 29 lipca 2025 roku, z firmami Dell, Google Cloud, Oracle i Red Hat jako pierwszymi członkami) nie konkuruje z A2A, tylko stanowi warstwę nad nim odpowiedzialną za wykrywanie, tożsamość i obserwowalność. Open Agent Schema Framework (OASF) wprost przyjmuje AgentCards A2A i opisy serwerów MCP jako formaty wejściowe: „A2A agents and MCP servers are discoverable through AGNTCY directories.”
• NANDA jako wizja badawcza. Projekt NANDA z MIT Media Lab koncepcyjnie bazuje na MCP i A2A, ale w 2026 roku ma głównie charakter badawczy i nie stanowi podstawy do produkcyjnych decyzji architektonicznych.

Uczciwy stan na 2026 rok: MCP i A2A tworzą konwergentny standard branżowy, AGNTCY jest racjonalnym dodatkiem tam, gdzie liczy się tożsamość ponad granicami producentów, a NANDA pozostaje wizją długoterminową.

A2A w praktyce w Europie: platformy i wdrożenia

Dla firm w Europie A2A to protokół komunikacji między agentami, z którym stykają się najczęściej, ponieważ punktami wejścia są ich istniejące środowiska Salesforce, SAP, Microsoft i ServiceNow. Konkretne przykłady:

• SAP Joule Studio 2.0 / Joule Work (Sapphire 2026, GA w Q4 2026): dwukierunkowe A2A, dzięki któremu agenci zewnętrzni mogą natywnie wywoływać agentów Joule i odwrotnie. Dla zdominowanego przez SAP krajobrazu IT w regionie DACH (Niemcy, Austria, Szwajcaria) to jedno z najważniejszych wydarzeń 2026 roku w obszarze platform wieloagentowych.
• Salesforce Agentforce 360 Multi-Agent Orchestration: A2A jako międzyproducencki handshake przy delegowaniu zadań do agentów zewnętrznych; wewnętrzne przekazania obsługuje Atlas Reasoning Engine.
• Microsoft Agent 365 / Copilot Studio: obsługa A2A w Work IQ od kwietnia 2026 roku.
• Google Gemini Enterprise (dawniej Agentspace) i ServiceNow Now Assist: odpowiednio natywne A2A oraz A2A jako międzyplatformowy handshake.

Zgodność z przepisami i audyt (informacyjnie, nie stanowi porady prawnej)

Poniższe wskazówki mają charakter informacyjny i nie zastępują porady prawnej. Łańcuchy A2A mają strukturalne konsekwencje dla zgodności z przepisami, które w architekturach referencyjnych skoncentrowanych na USA często umykają:

• Łańcuch umów powierzenia w RODO (art. 28). Każdy dostawca agentów jest potencjalnie podmiotem przetwarzającym; podejście wieloagentowe wydłuża łańcuch umów powierzenia. Każdy przeskok A2A to potencjalnie osobna relacja z podmiotem przetwarzającym, z własną umową powierzenia przetwarzania danych.
• Transgraniczne przekazywanie danych (art. 44–49). W hybrydowym stosie Salesforce/SAP/Microsoft/Anthropic działającym w chmurach w USA i UE każdy przeskok między agentami, który przekazuje dane do państwa trzeciego, wymaga własnej podstawy prawnej zgodnie z rozdziałem V RODO. W przypadku odbiorców w USA certyfikowanych w ramach EU-US Data Privacy Framework obowiązuje decyzja Komisji Europejskiej z 10 lipca 2023 roku stwierdzająca odpowiedni stopień ochrony (art. 45). Jeśli brak takiej decyzji, potrzebujesz odpowiednich zabezpieczeń zgodnie z art. 46, w praktyce najczęściej standardowych klauzul umownych (SKU) wraz z oceną skutków transferu (Transfer Impact Assessment), i to dla każdego przeskoku osobno.
• Unijny AI Act (w zarysie). Kto jest dostawcą, a kto podmiotem stosującym w kompozycji A2A Salesforce → SAP → Anthropic? Ostrożna interpretacja: każdy producent jest dostawcą własnego agenta, a organizacja integrująca jest podmiotem stosującym system złożony. W 2026 roku ten podział nie został jeszcze ostatecznie wyjaśniony; takie stwierdzenia należy traktować jako tymczasowe, dopóki akty wykonawcze nie przyniosą jasności.
• Ścieżka audytu. Każda wiadomość A2A może mieć znaczenie dla audytu. Zaleca się propagowanie jednolitego trace ID przez każde zadanie A2A i każde wywołanie MCP, przypinanie wersji modeli oraz rejestrowanie użytych AgentCards. Audytowalność należy wbudować w topologię agentów, a nie tylko w pipeline logowania.

Jak w praktyce wygląda własny agent audytowy, pokazuje Allianz Project Nemo w Australii, choć wykorzystanie A2A nie zostało tam publicznie potwierdzone. To hierarchiczny system siedmiu agentów (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit), który Allianz Australia uruchomił w lipcu 2025 roku do obsługi szkód związanych z zepsutą żywnością po przerwach w dostawie prądu spowodowanych nawałnicami. Wdrożenie produkcyjne zajęło mniej niż 100 dni, a system pozwolił skrócić czas obsługi i likwidacji szkód o 80% (źródło: Allianz, 2025). O wypłacie zawsze decyduje człowiek. Ubezpieczyciele z regionu DACH mogą wykorzystać wzorzec agenta audytowego jako schemat.

Perspektywy i wskazówki praktyczne

W 2026 roku A2A przekształcił się ze standardu Google w neutralnie zarządzany projekt Linux Foundation, wspierany przez ponad 100 podmiotów. Najsilniejsze zabezpieczenie strukturalne, czyli zarządzanie w ramach Linux Foundation, idzie w parze z otwartymi pytaniami: kluczowym sygnałem do obserwowania w nadchodzących kwartałach jest to, czy A2A osiągnie prawdziwą interoperacyjność między producentami w środowiskach produkcyjnych, czy też ulegnie fragmentacji przez własnościowe rozszerzenia AgentCard.

W praktyce w Europie pragmatyczna rekomendacja brzmi: MCP dla narzędzi, A2A dla agentów. Wszystko inne to świadome odstępstwo od konwergentnego stosu i powinno być uzasadnione. Jeśli działasz jako dostawca lub podmiot stosujący, publikuj AgentCards, ponieważ to one są międzysystemowym kontraktem, który decyduje o tym, czy agent uczestniczy w ekosystemie enterprise w 2026 roku. AGNTCY i NANDA zasługują na miejsce na liście obserwacyjnej, ale w 2026 roku nie należą do ścieżki krytycznej programu wieloagentowego. Rozsądna kolejność wdrażania w koncernach: najpierw ujednolicić politykę dla serwerów MCP, potem wprowadzić A2A w obrębie jednej platformy, następnie rozszerzyć je na drugą, zbudować rejestr AgentCard i dodać tożsamość międzyproducencką (AGNTCY) dopiero wtedy, gdy uzasadni to skala.