Jak Google zmienia zasady gry w budowaniu produkcyjnych agentów AI, wdrażając MCP i A2A?

Koniec z izolacją modeli. Dlaczego standaryzacja kontekstu i komunikacji to przyszłość AI w Twojej firmie?

Wszyscy to wiemy. Od miesięcy słyszymy o rewolucji AI. Mamy teraz niesamowicie potężne modele, takie jak Gemini i ChatGPT, które potrafią pisać poezję, debugować kod i myśleć filozoficznie. Ale kiedy próbujemy wdrożyć to w firmie, coś jest nie tak z wynikiem.

Chcemy, aby AI pomagało w obsłudze klienta. I co się wtedy dzieje? Model pięknie przeprasza klienta, ale nie potrafi sprawdzić statusu jego zamówienia w naszym systemie. Dlaczego? Ponieważ jest całkowicie odłączony od rzeczywistości biznesowej. To największa pułapka każdej implementacji AI w produkcji. Nasze potężne modele są jak mądrzy stażyści zamknięci w pokoju bez telefonu czy dostępu do internetu. Potrafią rozwiązać abstrakcyjny problem, ale nie mają pojęcia, który klient jest dla nas najważniejszy, ani ile mamy zapasów w magazynie.

Do tej pory rozwiązanie było jedno: miesiące pracy programistów piszących mnóstwo małych fragmentów kodu łączącego ten genialny mózg z bazą danych firmy. A potem znowu, aby podłączyć go do API. I potem połączyć z CRM. Dokładnie. Aż do teraz. Zamiast skupiać się tylko na modelu, który jest „mądrzejszy”, Google Cloud postanowiło rozwiązać podstawowy problem: problem hydrauliki.

W ciągu ostatniego roku na scenie pojawiły się dwa protokoły, które zmieniają zasady gry: Model Context Protocol (MCP) stworzony przez Anthropic (twórców Claude) oraz Agent2Agent (A2A) zaprezentowany przez Google w I kwartale 2025.

W tym artykule, napisanym w stylu „development na miękko”, przyjrzymy się:

• Dlaczego obecne AI jest „głupie” w odniesieniu do twoich danych?
• Czym jest MCP i co robi, aby powstrzymać AI przed halucynacjami na temat twojej firmy?
• Czym jest A2A i dlaczego jest to bilet do budowania prawdziwych systemów produkcyjnych, a nie tylko zabawkowych chatbotów? 
• Jak zacząć z tym pracować (plan działania bez bólu głowy)?
• Gdzie jest haczyk i jakie ryzyka musisz znać?

Zapnijcie pasy. Robimy pierwszy krok, by AI przestało być ciekawostką i stało się prawdziwym pracownikiem.

Ból biznesu: Mózg w słoiku

Zanim omówimy protokoły, konieczne jest wyjaśnienie problemu. Duże modele językowe (LLM) nie „wiedzą”, co się wydarzyło po dacie ich treningu. Nie mają też dostępu do twoich prywatnych systemów.

Kiedy pytasz: „Jaki jest status zamówienia 12345?”, model nie ma metody na jego weryfikację. Zamiast tego generuje odpowiedź (halucynuje), która brzmi prawdopodobnie w świetle jego wiedzy treningowej. Rezultat? Chaos w obsłudze klienta.

Tu pojawia się paradoks: Im lepsze stają się modele, tym trudniej te halucynacje wyłapać. Błędy stają się subtelne, ukryte w perfekcyjnie brzmiących zdaniach. Dla obsługi klienta czy procesów decyzyjnych to chaos znacznie gorszy niż oczywisty błąd – to utrata zaufania, które trudno odbudować.

Protokół 1: MCP – standardowy port USB dla narzędzi AI

Do tej pory, aby model mógł korzystać z narzędzi (baz danych, API pogodowych, systemów CRM), każdy musiał tworzyć własny konektor. To jakby każda firma produkująca laptopy miała własny port ładowania – koszmar. Model Context Protocol (MCP) to otwarty standard (taki jak USB-C) przeznaczony do komunikacji między modelem AI a zewnętrznie opracowanymi narzędziami.

Jak to działa (w uproszczeniu)?

MCP to standard dla agenta AI, aby:

1. Zapytać o narzędzia: „Jakich narzędzi mogę użyć?”
2. Otrzymać odpowiedź: „Masz dostęp do get_customer_details(id) i check_inventory(product_name)”. Co ważne – model otrzymuje nie tylko nazwę, ale też opis działania narzędzia. Dzięki temu „rozumie”, do czego ono służy i jak je poprawnie użyć, nawet jeśli widzi je pierwszy raz.
3. Poprosić o wykonanie: „OK, proszę, wykonaj get_customer_details(12345)”.
4. Otrzymać dane: „Oto wynik: [JSON z danymi klienta]”.

Co to zmienia w praktyce?

To most, który opisaliśmy wcześniej (Twój Kluczowy Punkt #1). Zamiast halucynować, agent AI, poproszony o sprawdzenie statusu zamówienia, wywołuje rzeczywistą funkcję w twoim systemie ERP za pośrednictwem protokołu MCP. Otrzymuje prawdziwe dane i na ich podstawie przedstawia klientowi poprawną odpowiedź. MCP to koniec świata oderwanego od rzeczywistości. To standardowy sposób na podłączenie „mózgu w słoiku” do systemu nerwowego firmy, twoich danych i API.

Wymóg produkcyjny: Od chatbota do zautomatyzowanego procesu

Świetnie. Mamy więc jednego inteligentnego agenta (dzięki MCP), który może współpracować z naszymi narzędziami. Ale czy rzeczywiste procesy biznesowe są realizowane przez jedną osobę?

Teraz podajmy prosty przykład: skarga klienta. Ten proces w praktyce wymaga całego zespołu:

1. Agent Wsparcia (Support) przyjmuje zgłoszenie.
2. Deleguje zadanie do Agenta Logistyki, aby sprawdził, czy wadliwy produkt wrócił do magazynu.
3. Agent Logistyki potwierdza, więc Agent Wsparcia prosi Agenta Finansów o wystawienie korekty faktury.
4. Agent Finansów wystawia fakturę i informuje Agenta CRM o zamknięciu sprawy.

Do tej pory, w świecie AI, staraliśmy się zmusić do tego wszystkiego jednego monolitycznego bota. To nie działa. Tak samo, jak nigdy nie zatrudniłbyś jednej osoby do bycia jednocześnie księgowym, magazynierem i przedstawicielem obsługi klienta. 

Protokół 2: A2A – biznesowy LinkedIn dla Agentów AI

To właśnie tutaj wkracza Agent2Agent (A2A). Więc, jeśli MCP służy do interakcji z innymi narzędziami (protokół dla agenta), to A2A służy do komunikacji z innymi agentami (protokół dla agenta). W słowach Jeremy’ego Morgana – profesjonalisty z CodeCloud – A2A można postrzegać jako „HTTP dla agentów AI”.  

Jest to standard, który pozwala różnym wyspecjalizowanym agentom AI wykonywać twoje polecenia – nawet jeśli są produkowane przez różne firmy i działają na różnych technologiach (!), aby:

1. Znaleźć się nawzajem: „Kto w tej firmie zajmuje się finansami?”
2. Rozumieć swoich możliwości: „Co potrafisz zrobić?”
3. Delegować zadania: „Proszę, wystaw korektę faktury dla zamówienia 12345”.
4. Odbierać wyniki: „Zrobione, oto numer korekty”.

Jak to działa (w uproszczeniu)?

AgentCard jest sercem A2A. To po prostu plik JSON, który działa jak cyfrowa wizytówka lub profil LinkedIn.

Każdy agent udostępnia swoją kartę, która określa:

• Kim jestem? (np. billing-agent-prod)
• Co potrafię? (np. create_invoice, process_refund)
• Jak się ze mną skontaktować? (np. endpoint API, metody autentykacji)

Kiedy nasz Agent Wsparcia musi zorganizować zwrot w przykładzie skargi, nie jest konieczne, aby wiedział, jak działa system księgowy. Wystarczy, że zdobędzie AgentCard dla „Agenta Finansowego” i wyśle mu jednolite zadanie.

Co to zmienia w praktyce?

To jest właśnie ten moment, w którym AI przechodzi z poziomu „chatbota” na poziom złożonych, wieloagentowych systemów produkcyjnych (Twój Kluczowy Punkt nr #2). Google nazywa obecny stan „wieloagentowym kłębkiem makaronu” (ang. multi-agent hairball). A2A ma ten makaron rozplątać.

Dodatkowo, zachęcam Was do odsłuchania video na kanale YT KodeKloud, gdzie Jeremy Morgan szczegółowo omawia te zagadnienia:

Przewaga GCP: Gra o infrastrukturę, nie tylko o modele

I tutaj dochodzimy do najbardziej strategicznie istotnej kwestii (Twój Kluczowy Punkt nr #3).

Cała branża jest zaangażowana w coś w rodzaju wyścigu „koni mechanicznych”, kto ma więcej parametrów w modelu, kto ma ulepszony chatbot. Google ze swojej strony ma Gemini, ale jednocześnie gra w zupełnie inną grę. Google gra o infrastrukturę. Poprzez wykorzystanie otwartych protokołów MCP i A2A, Google Cloud Platform (GCP) mówi deweloperom:

Nie obchodzi nas, z jakiego modelu chcesz skorzystać. Chcesz użyć open-source Llama? Śmiało. Chcesz połączyć się z agentem z AWS? Nie ma problemu. Oferujemy ci standardowe (i niezawodne) rozwiązania (protokoły), które pomogą ci wszystko załatwić.

To genialny ruch. Zamiast tworzyć kolejny zamknięty „ogrodzony ogród”, Google standaryzuje fundamenty. To daje deweloperom GCP wyraźną przewagę:

• Koniec z uzależnieniem od dostawcy: Możesz mieszać i dopasowywać najlepsze systemy i agentów z różnych źródeł (między dostawcami, między frameworkami).
• Kompozycyjność: Złożone systemy można budować jak klocki LEGO, zamiast wszystko rzeźbić od podstaw.
• Niezawodność: Standaryzowane protokoły oznaczają standardowe śledzenie błędów, monitorowanie i bezpieczeństwo, co jest szczególnie ważne w systemach produkcyjnych.

Niedawno Google udostępniło framework Agent Development Kit (ADK). Dzięki temu ekosystem GCP oferuje teraz kompletny stack „end-to-end”:

• ADK – do tworzenia agentów (również tych niezależnych od modeli Google),
• A2A – do komunikacji między agentami (agent-agent),
• MCP – do komunikacji z narzędziami (agent-narzędzie).

Doskonałym przykładem tej architektury w działaniu jest nowy asystent głosowy Mercedes-Benz oparty na Gemini. Jak pokazało samo Google Cloud, system ten działa dokładnie w ten sposób:

• Główny agent AI (orkiestrator), czyli Automotive AI Agent, zarządza rozmową.
• Gdy użytkownik prosi o nawigację, orkiestrator deleguje zadanie (przez logikę A2A) do wyspecjalizowanego agenta nawigacyjnego (Conversational Navigation).
• Ten agent nawigacyjny z kolei pobiera dane o miejscach i trasie (przez logikę MCP) z Google Maps Platform (Places Search API).

To nie jest już teoria – to jest case study z najwyższej półki, pokazujące, jak buduje się dziś systemy produkcyjne. Video prezentacja jest też dostępna na rolce stworzonej przez Google Cloud wraz z Mercedes-Benz (źródło).

Co więcej, to nie jest wojna formatów a współpraca. Google korzysta z MCP od Anthropic, a Anthropic integruje się z A2A i Google Cloud. To daje deweloperom w ekosystemie Google ogromną przewagę: narzędzia, które rozwiązują rzeczywiste problemy produkcyjne, a nie tylko abstrakcyjne benchmarki.

OK, brzmi fajnie. Ale jak zacząć? (Roadmapa bez bólu głowy)

Kiedy robisz to w praktyce, na pierwszy rzut oka wszystko wydaje się rewolucyjne. Architekci i deweloperzy muszą cofnąć się o krok i pomyśleć o automatyzacji procesu zamiast budowania bota.

Poniżej znajdziecie logiczną ścieżkę adopcji rozwiązań.

Krok 1: Wybierz jeden proces, a nie jednego bota

Nie próbuj budować „bota do wszystkiego”. Wybierz jeden konkretny proces biznesowy, który chcesz zautomatyzować (np. wspomniane „obsługiwanie skarg”, „wdrażanie nowego pracownika” lub „reagowanie na incydent MLOps”).

Krok 2: Zidentyfikuj „zespół” i daj mu narzędzia (MCP)

Określ, jakie „role” (agenci) są potrzebne w tym procesie (Agent Wsparcia, Agent Finansowy itp.). Zanim agenci zaczną ze sobą rozmawiać, potrzebują dostępu do danych. Użyj MCP, aby zapewnić każdemu z nich „klucze” (dostęp do narzędzi) do odpowiednich systemów (CRM, ERP).

Krok 3: Wręcz im wizytówki i naucz ich współpracy (A2A)

Kiedy agenci mają już narzędzia (MCP), spraw, aby ze sobą współpracowali. Zaproponuj każdemu AgentCard (ich „profil LinkedIn”), aby mogli się odnaleźć. Następnie zastosuj A2A, aby Agent Wsparcia mógł formalnie „delegować” zadanie na przykład Agentowi Finansowemu.

Krok 4: Patrz im na ręce i zaczynaj od małych zadań

Systemy wieloagentowe potrzebują solidnego monitoringu (obserwowalności). Musisz wiedzieć, kto komu i kiedy przypisał zadanie. Na szczęście standaryzacja A2A to ułatwia. Zacznij od jednego prostego procesu. Nie próbuj automatyzować od razu całej firmy.

Gdzie jest haczyk? O czym Google głośno nie mówi

Podobnie jak każda nowa, zaawansowana technologia, MCP i A2A nie są magiczną różdżką. Oto rzeczywiste ryzyka i zastrzeżenia, które powinieneś znać.

To (na razie) plac budowy, a nie gotowy produkt

Oba protokoły są bardzo nowe. Google opublikowało specyfikację (wersję roboczą) i przykładowe implementacje, aby społeczność była zachęcana do dyskusji nad pomysłami. Nie dostajesz więc dojrzałych bibliotek utwardzonych do produkcji ani rozwiniętego ekosystemu. To technologia dla pionierów, a nie maruderów.

Trudno jest debugować „bałagan spaghetti”

Systemy multi-agentowe są niezwykle skomplikowane. Jeśli Agent A żąda od Agenta B czegoś, Agent B wymaga od Agenta C, a Agent C zwraca błąd, zidentyfikowanie przyczyny może być koszmarem. Dlatego właśnie Krok 4 (Obserwowanie) z naszej roadmapy jest kluczowy.

Armata na muchę

Nie wpadnij w pułapkę hype’u czy mody na konieczne wprowadzenie nowości. Jeśli Twój projekt to prosty chatbot z dwoma narzędziami, wdrażanie pełnej architektury wieloagentowej A2A może być przerostem formy nad treścią (overengineering). Czasem proste połączenie LLM-a z API wystarczy. Te protokoły pokazują moc dopiero przy większej skali i złożoności.

Należy utrzymywać poziom ścisłego nadzoru (Zarządzanie i IAM)

Jeśli dajesz agentowi AI (przez MCP) dostęp do swojego systemu ERP z uprawnieniami do wystawiania faktur, musisz mieć 100% pewności, że działa on z odpowiednią tożsamością i uprawnieniami (nazywanymi IAM). Te protokoły nie rozwiązują twoich problemów z bezpieczeństwem – dostarczają jedynie pewne rutynowe ramy, abyś mógł je poprawnie zastosować.

IT Infrastructure

Przejmiemy opiekę 24/7 nad całą infrastrukturą IT w Twojej firmie, zapewniając bezpieczeństwo, wydajność i brak przestojów.

Oferta IT Infrastructure

Podsumowanie: Koniec izolacji, początek współpracy

W ciągu ostatnich kilku lat podchodziliśmy do AI, jakby były to odizolowane mózgi. Jak się okazuje, genialny mózg jest bezużyteczny w biznesie bez dostępu do danych (kontekstu) i bez zdolności do współpracy (komunikacji).

Przyszłość nie będzie polegała na jednym, gigantycznym, monolitycznym modelu AI, który wie wszystko. Przyszłość będzie zespołem wyspecjalizowanych agentów, którzy współpracują w czasie rzeczywistym, opierając się na rzeczywistych danych.

Aby rozwijać tę przyszłość, Google dostarczyło nam nowe standardy:

1. MCP (Model Context Protocol): Zapewnia agentom narzędzia i kontekst (dostęp do danych).
2. A2A (Agent2Agent Protocol): Daje agentom możliwość pracy zespołowej (komunikacja).
3. ADK (Agent Development Kit): Pozwala to wszystko sprawnie zbudować.

Dla firm jest to strategiczna zmiana. To przejście od „Mamy chatbota” do etapu „Mamy zautomatyzowane procesy biznesowe oparte na AI”. I to może być rewolucja.