MCP, A2A i ACP w praktyce: Jak bank łączy narzędzia i agenty ze sobą.

Seria publikacji dotyczących modeli z ostatnich kilku lat podążała za jednym schematem. Pojawia się większy model, który pisze lepszy kod, rozumuje bardziej klarownie i radzi sobie z dłuższymi kontekstami. W ciągu kilku tygodni entuzjazm słabnie, ponieważ sam sprytny model w oknie czatu nadal nie może sprawdzić salda klienta, zablokować podejrzaną transakcję ani pobrać historii kredytowej aplikanta. Inteligencja nigdy nie była prawdziwym wąskim gardłem – problemem była integracja.

Wysiłki inżynieryjne przeniosły się z po prostu rozmiaru modelu na projektowanie protokołów. Trzy specyfikacje adresują problem integracji: MCP (Model Context Protocol), A2A (Agent-to-Agent) oraz ACP (Agent Communication Protocol). Razem określają one, w jaki sposób model uzyskuje dostęp do narzędzi, jak jeden agent komunikuje się z drugim oraz ile agentów może współpracować bez popadania w chaos.

Jeden przykład ilustruje wszystko poniżej: bank tworzący asystenta AI, który musi wykrywać oszustwa, oceniać wnioski o kredyt i komunikować się z systemami bankowymi, przy jednoczesnym zachowaniu wystarczającej transparentności, by zadowolić organy nadzoru.

Dlaczego model sam w sobie potrzebuje protokołów

Samodzielnie model językowy potrafi jedynie przewidywać tekst. Jeśli zapytamy go, czy konto klienta wykazuje podejrzane działania w tym miesiącu, albo odrzuci zapytanie, albo udzieli płynnej, ale błędnej odpowiedzi, ponieważ rzeczywisty rejestr transakcji jest poza jego zasięgiem.

Początkowe rozwiązania łączyły modele bezpośrednio z interfejsami REST API, jeden po drugim. Asystent do wykrywania oszustw potrzebował dostosowanego kodu dla API bankowego, jeszcze więcej dla systemu CRM, a jeszcze więcej do zarządzania przypadkami. Małe implementacje radziły sobie z tym, natomiast większe napotkały trzy problemy:

• Nic nie mogło być ponownie wykorzystane. Łącznik do systemu bankowości core używany przez zespół zajmujący się oszustwami nie był przydatny dla zespołu ds. pożyczek, mimo że oba zespoły potrzebowały identycznych danych transakcyjnych, więc każdy projekt musiał być rozpoczynany od zera.
• Stan danych znikał pomiędzy zapytaniami. API są z natury bezstanowe. Analityk, który pobrał dane transakcyjne klienta, a po dwóch kolejnych zapytaniach chciał wiedzieć, czy w „tych danych” są jakieś nieprawidłowości, odkrył, że zwykła integracja z API nie zachowuje żadnego powiązania pomiędzy tymi zapytaniami, chyba że inżynierowie ręcznie stworzą warstwę pamięciową.
• Prawa dostępu były dodawane ad hoc. Każda operacja bankowa wymaga sprawdzenia uprawnień oraz utworzenia zapisu dla audytorów. Młodszy analityk zajmujący się oszustwami może przeglądać historię transakcji, ale nie może zatwierdzić odwołania przelewu. Indywidualna konfiguracja każdego API utrudniała precyzyjne stosowanie takich zasad i sprawiała trudności w ich przedstawieniu audytorowi.

Protokół jednorazowo ustala warunki umowy. Żaden bank nie musi opracowywać własnej metody umożliwiającej modelowi wywołanie silnika wykrywania oszustw, ponieważ MCP dostarcza jedną, spójną interfejs. Żaden zespół nie musi tworzyć własnego sposobu przekazywania spraw z agenta ds. oszustw do agenta ds. zgodności, ponieważ A2A oferuje odpowiedni mechanizm. HTTP służył do tego w aplikacjach sieciowych, a SQL w bazach danych – to wspólny język umożliwiający współpracę niezależnie opracowanych systemów.

Pięć etapów projektowania

Projektowanie systemów przeszło przez pięć etapów, zarówno w bankowości, jak i w innych dziedzinach.

1. Zwykły LLM. Model odpowiada wyłącznie na podstawie danych treningowych. Potrafi wyjaśnić, czym jest KYC, ale nie może stwierdzić, czy profil konkretnego klienta spełnia zasady KYC banku, ponieważ nigdy nie widzi jego danych.
2. Generowanie wzbogacone o dostęp do informacji. Model łączy się z magazynem dokumentów, takim jak podręcznik zasad compliance czy wcześniejsze wytyczne regulacyjne, dzięki czemu odpowiedzi opierają się na aktualnych, poufnych danych specyficznych dla danej organizacji, a nie na ogólnych informacjach użytych podczas szkolenia.
3. Agenci. Model potrafi nie tylko wyszukiwać informacje, ale także działać. Asystent ds. compliance może teraz powoływać się na zasady KYC oraz sprawdzać dokumenty klienta w bazie danych pod kątem ich zgodności z tymi zasadami, zaznaczając ewentualne braki.
4. Systemy wieloagentowe. Gdy jeden agent zajmujący się jednocześnie wykrywaniem oszustw, oceną kredytową i komunikacją z klientem staje się niewiarygodny lub trudny do kontrolowania, prace są dzielone między specjalistów – np. agenta ds. oszustw, agenta ds. kredytów i agenta ds. komunikacji z klientem, z których każdy jest ekspertem w określonej dziedzinie.
5. Protokoły. Gdy pojawia się wiele agentów i systemów, potrzebny jest standardowy sposób, aby mogły one odnajdywać się nawzajem, dzielić się kontekstem i komunikować bezpiecznie. MCP, A2A i ACP odpowiadają na tę potrzebę.

Obecnie większość banków znajduje się pomiędzy trzecim a czwartym etapem. Istnieją pojedyncze agenty, często po jednym na każdy przypadek użycia, jednak bez wspólnego protokołu między nimi każdy nowy agent nadal wymaga dodatkowej, dostosowanej integracji. Wypełnienie tej luki jest celem protokołów.

Wywoływanie narzędzi, warstwa leżąca u podstaw MCP

Zanim pojawił się MCP, istniało wywoływanie narzędzi, znane również jako wywoływanie funkcji. Umożliwia ono modelowi żądanie wykonania działań zewnętrznych zamiast wyłącznie generowania tekstu, a MCP jest zbudowane na jego bazie.

Mechanizm jest prosty. Dla każdego dostępnego narzędzia programista tworzy schemat JSON zawierający nazwę, opis oraz parametry typowane, a następnie wysyła go do modelu wraz z poleceniem. Gdy model stwierdzi, że potrzebne jest jakieś narzędzie, nic nie uruchamia. Jego wynikiem jest zstrukturyzowany obiekt JSON z nazwą narzędzia oraz argumentami, a aplikacja otaczająca wykonuje tę funkcję i zwraca wynik modelowi. Schemat bankowy wygląda w ten sposób:

{
  "name": "get_customer_transactions",
  "description": "Returns transactions for a customer above a given amount, within a date range",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string"},
      "min_amount": {"type": "number"},
      "start_date": {"type": "string", "format": "date"},
      "end_date": {"type": "string", "format": "date"}
    },
    "required": ["customer_id", "start_date", "end_date"]
  }
}

Przypuśćmy, że analityk ds. oszustw prosi o pokazanie ostatnich dużych transakcji klienta, przekraczających pięć tysięcy dolarów w ciągu ostatniego miesiąca. Do udzielenia odpowiedzi nie wykorzystuje się pamięci. Zamiast tego model wysyła żądanie do funkcji get_customer_transactions z identyfikatorem klienta, progiem kwotowym oraz określonym oknem czasowym. Następnie aplikacja wyszukuje informacje w bazie danych bankowej, przekazuje faktyczne dane, a model przekształca je w czytelną syntezę.

Zwykłe narzędzia do wywoływania funkcji dobrze radzą sobie z jednym modelem i kilkoma narzędziami zapisanymi w kodzie. Problemy pojawiają się, gdy istnieje dziesiątki narzędzi rozproszonych w systemach bankowych, ds. oszustw, CRM oraz systemach dokumentowych, przy czym niektóre z nich muszą być dodawane bez konieczności ponownego wdrażania dla każdego klienta, albo gdy istnieje jedno narzędzie, którego muszą bezpiecznie korzystać zarówno asystenci ds. oszustw, jak i kredytów. MCP jest skierowane właśnie na te problemy.

MCP szczegółowo

MCP trafił od Anthropic pod koniec 2024 roku jako otwarty standard służący do łączenia aplikacji AI z zewnętrznymi systemami. Można to porównać do uniwersalnego adaptera. Wcześniej połączenie asystenta bankowego z systemem bankowym, silnikiem wykrywania oszustw oraz systemem CRM wymagało trzech niekompatybilnych integracji. Teraz każdy klient zgodny z MCP może komunikować się z każdym serwerem zgodnym z MCP, tak jak każde urządzenie USB pasuje do każdego portu USB.

Arytmetyka M razy N

Podstawowy problem ma charakter kombinatoryczny. Połączenie M narzędzi z N aplikacjami tworzy macierz, która staje się nie do zarządzania w miarę wzrostu obu liczb. Bank posiadający pięć wewnętrznych systemów i cztery asystenty (wykrywanie oszustw, kredyty, obsługa klienta, zgodność z regulacjami) potrzebowałby nawet dwudziestu dostosowanych łączników. Standardowy protokół redukuje to do pięciu plus czterech, ponieważ każdy system i każdy asystent implementują MCP tylko raz.

Trzy role

• Host: aplikacja AI, którą użytkownik faktycznie widzi, na przykład interfejs asystenta analityka oszustw.
• Client: komponent wewnątrz hosta, który zarządza jednym połączeniem z serwerem MCP i obsługuje komunikację na poziomie protokołu.
• Server: strona udostępniająca funkcjonalności, czyli dane lub operacje. Bank może mieć jeden serwer przed systemem bankowym, drugi przed silnikiem wykrywania oszustw i trzeci przed repozytorium dokumentów, przy czym każdy z nich jest utrzymywany przez zespół odpowiedzialny za system, który stoi za nim.

Trzy elementy podstawowe, które może oferować serwer

• Zasoby zawierają dane tylko do odczytu, które model może uwzględnić w kontekście, na przykład wyciąg z konta lub status dokumentów KYC. Podobnie jak żądanie GET, służą one jedynie do informowania i nic nie zmieniają.
• Narzędzia wykonywają określone działania, takie jak zamrożenie części konta lub przesłanie sprawy do pracownika ds. zgodności. Podobnie jak żądania typu POST zmieniają one stan, co sprawia, że są to elementy najbardziej wymagające ludzkiego zatwierdzenia w banku.
• Wskazówki to wielokrotnie używalne, parametryzowane szablony, które kierują modelem ku poprawnie sformułowanemu żądaniu. Przykładem jest standardowa wskazówka do eskalacji przypadków oszustwa, którą każdy asystent analityka używa w ten sam sposób, dzięki czemu żadna zespołowa grupa nie utrzymuje własnej, nieco innej wersji.

Próbkowanie, odkrywanie i transport

Próbkowanie umożliwia serwerowi poproszenie LLM hosta o uzupełnienie informacji, wykorzystując rozumowanie modelu do wykonania podzadania. Serwer przechowujący dokumenty może go użyć, aby model streszczł długą umowę kredytową przed jej zwróceniem, a następnie analityk ludzki przejrzał to streszczenie przed podjęciem decyzji.

Odkrywanie następuje w momencie, gdy klient się łączy i pyta serwer o dostępne zasoby, narzędzia oraz instrukcje, co sprawia, że MCP pozostaje dynamiczne. Gdy zespół zajmujący się oszustwami opublikuje nowe narzędzie do sprawdzania historii urządzenia klienta, każdy podłączony asystent może go natychmiast używać, bez konieczności modyfikacji kodu klienta.

Format komunikacji to JSON-RPC 2.0, przesyłany za pomocą jednego z dwóch powszechnie używanych protokołów. Stdio nadaje się do serwerów działających na samym komputerze klienta, natomiast HTTP z Server-Sent Events lub streamable HTTP jest odpowiedni dla serwerów zdalnych. Do serwera bankowości w centrum danych, znajdującego się za firewall, uzyskuje się dostęp przez zdalny HTTP z odpowiednią autoryzacją, a nie przez Stdio.

Bezpieczeństwo

Przemysły regulowane to obszary, w których MCP zarabia na życie, chociaż nie dostarcza automatycznie żadnych mechanizmów kontroli. Umożliwia inżynierom jedno spójne miejsce do tworzenia i wdrażania tych mechanizmów, zamiast co raz na nowo projektować rozwiązania bezpieczeństwa pod każdą integrację. Wdrożenie w bankowości produkcyjnej powinno:

• wymagać OAuth 2.1 podczas autoryzacji klientów w serwerach;
• przyznawać każdemu narzędziu tylko te uprawnienia, których potrzebuje, tak aby token młodszego analityka nie mógł uzyskać dostępu do funkcji takich jak approve_wire_transfer;
• zapisywać informacje o każdym wywołaniu narzędzia;
• wymagać wyraźnej potwierdzenia od osoby ludzkiej przed wywołaniem operacji zmieniającej stan, np. zamrożeniem konta lub zniesieniem blokady.

Jak wygląda wdrożenie MCP

Typowe wdrożenie bankowe składa się z trzech warstw. Hostem jest interfejs czatu lub środowisko działania agenta, które widzi użytkownik, na przykład asystent do prowadzenia dochodzeń. Klient MCP znajdujący się w hostzie otwiera sesje z serwerami, wysyła żądania odkrywania informacji oraz przekazuje pomiędzy nimi wywołania narzędzi. Każdy z serwerów obsługuje pojedynczy system przechowywania danych – na przykład system bankowości core, silnik wykrywania oszustw czy magazyn dokumentów – a każdy z nich jest utrzymywany i zabezpieczany przez zespół, który jest za niego odpowiedzialny.

Przykład dochodzenia w sprawie oszustwa pokazuje ścieżkę żądania:

1. Analityk chce uzyskać informacje o wszystkich transakcjach o wartości powyżej dziesięciu tysięcy dolarów dla danego klienta z ostatnich trzydziestu dni, a także sprawdzić, czy odcisk urządzenia ostatnio uległ zmianie.
2. LLM hosta określa, że potrzebne są dwa wywołania narzędzi, i poleca klientowi uruchomienie funkcji get_transactions na serwerze bankowości core oraz get_device_history na serwerze silnika wykrywania oszustw.

Klient wysyła żądania JSON-RPC do obu serwerów przez HTTPS.

Każdy serwer weryfikuje zakres uprawnień OAuth analityka oraz jego prawo do dostępu do danych danego klienta, sprawdza swoje własne systemy bazowe i udziela odpowiedzi.

Klient przekazuje obie odpowiedzi modelowi, który łączy je w jeden podsumowanie.

Wszystko – zarówno żądania, odpowiedzi, jak i identyfikator analityka – jest zapisywane w dzienniku audytowym.

Minimalny serwer w Pythonie wykorzystujący oficjalny wzorzec SDK pokazuje, jak mało kodu potrzebuje takie narzędzie:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("core-banking-server")
@mcp.tool()
def get_transactions(customer_id: str, min_amount: float, days: int) -> list:
    """Fetch transactions above a threshold for a customer, scoped to the caller's authorization."""
    # In production this calls the real core banking API,
    # scoped and logged, never queried directly by the model.
    return query_core_banking(customer_id, min_amount, days)
@mcp.tool()
def place_transaction_hold(transaction_id: str, reason: str) -> dict:
    """Places a temporary hold on a transaction pending review. Requires human confirmation before execution."""
    return execute_hold(transaction_id, reason)
if __name__ == "__main__":
    mcp.run(transport="stdio")

Dwa narzędzia zawarte w nim wymagają w praktyce różnego podejścia. get_transactions służy do odczytu danych, ma charakter podobny do zasobów i może być uruchamiane bez konieczności potwierdzenia. place_transaction_hold zmienia stan w rzeczywistym systemie finansowym, dlatego nie powinien być wykonywany tylko dlatego, że o to poprosił model. Warstwa aplikacyjna powinna najpierw skierować go do wyraźnego potwierdzenia przez analityka.

Niektóre nawyki pomagają utrzymać serwery produkcyjne w dobrym stanie:

• Każdemu serwerowi przyporządkuj jeden system do obsługi, a nie monolit obejmujący bankowość podstawową, zwalczanie oszustw i CRM.
• Pisz opisy narzędzi w taki sposób, jakby były to dokumentacje przeznaczone dla nowego analityka, ponieważ model decyduje o tym, kiedy dane narzędzie ma zastosowanie, wyłącznie na podstawie tego tekstu.
• Wersjonuj schematy narzędzi. Zmiana wymaganego parametru w get_transactions bez uprzedzenia powoduje awarię wszystkich asystentów, które od niego zależą, włączając te spoza zespołu zajmującego się zwalczaniem oszustw.

Załóż, że każde wezwanie narzędzia stanowi niepewny wprowadzony danych dla systemu poniżej w łańcuchu przetwarzania, i zweryfikuj je, ponieważ zmanipulowany wynik modelu mógłby w przeciwnym razie spróbować wykonać nieuprawnione wezwanie.

A2A, agenci rozmawiający z agentami

MCP zajmuje się połączeniami między modelem a narzędziami. A2A, wprowadzone przez Google w 2025 roku i obecnie utrzymywane przez Linux Foundation, obsługuje inne połączenie: jeden autonomiczny agent kontaktujący się z drugim, szczególnie gdy zostały one stworzone przez różne zespoły lub dostawców.

Jeden agent nie wystarcza, ponieważ pojedynczy agent zajmujący się oszustwami, procesem akceptacji i komunikacją rozwija się w rozległy system, którego trudno zarządzać, a udowodnienie audytorowi, która logika podjęła decyzję, staje się bardzo trudne. Specjaliści, którzy delegują zadania między sobą, działają lepiej i są bezpieczniejsi.

Delegacja polega na karcie agenta, czyli maszynowo czytelnym opisie tego, co agent może robić. Przypomina listę narzędzi serwera MCP, ale opisuje umiejętności całego agenta, a nie poszczególnych funkcji. Agent pomocniczy koordynujący czyta kartę agenta ds. oszustw i dowiaduje się, że może badać sporne transakcje, czyta kartę agenta ds. kredytów i dowiaduje się, że może oceniać zgodność z warunkami refinansowania, a następnie wybiera odpowiedniego delegata do obsługi żądania klienta.

Koordynacja określa, w jaki sposób agenci przekazują sobie zadania, przesyłają częściowe wyniki oraz zgłaszają sukcesy lub niepowodzenia za pośrednictwem standardowego kanału komunikacji. Każda ze stron traktuje drugą jako „czarną skrzynkę”. Agent ds. obsługi klienta nie musi wiedzieć, w jaki sposób zbudowano Agenta antyoszustwa, czy ten korzysta z narzędzi MCP w systemie bankowym, jaki model nim kieruje ani ile kroków wymaga jego działanie. Wystarczą mu jedynie możliwości tego agenta oraz sposób przekazywania mu zadań.

Dwa przykłady z bankowości ilustrują to zjawisko. Po pierwsze, klient zgłasza nieznane opłaty w wysokości pięciuset dolarów na karcie oraz pyta o lepszą stopę procentową kredytu hipotecznego. Asystent nie zajmuje się żadnym z tych problemów osobiście. Przekazuje sprawę sporu Agentowi antyoszustwa, a pytanie dotyczące kredytu – Agentowi ds. kredytów, uruchamia oba procesy równocześnie, a następnie łączy odpowiedzi w jedną wiadomość.

Po drugie, agent ds. oszustw sprawdza tę transakcję, łącząc się z serwerami MCP do obsługi bankowości podstawowej oraz z silnikiem wykrywania oszustw w celu pobrania danych o transakcjach i urządzeniach. Gdy jego pewność co do oceny oszustwa jest niska, unika domysłów i przekazuje sprawę za pośrednictwem A2A do agenta ds. przeglądu zgodności, który stosuje surowsze zasady regulacyjne, a w razie potrzeby przekazuje ją ludzkiemu pracownikowi ds. zgodności. Asystent klienta, agent ds. oszustw, agent ds. przeglądu zgodności, pracownik ludzki – to właśnie taką uporządkowaną delegację umożliwia system A2A.

ACP, warstwa komunikacji

Podczas gdy A2A skupia się na delegowaniu zadań, ACP koncentruje się na komunikacji w ramach rozmów między wieloma agentami, szczególnie na zarządzaniu stanem, pamięcią oraz obsługą błędów podczas dłuższych interakcji.

• Architektura. Rozmowy stają się sekwencjami wpisywanych wiadomości. Każda wiadomość zawiera treść oraz metadane dotyczące jej nadawcy, wątku i oczekiwanego odpowiedzi. Dlatego eskalacja sprawy związanej z oszustwem do działu ds. zgodności obejmuje coś więcej niż samą sprawę: ustrukturyzowane pola dla ID sprawy, osoby składającej prośbę, stopnia pilności oraz typu oczekiwanej odpowiedzi.
• Komunikacja. Struktura zastępuje surowy tekst – podobnie jak e-mail ma temat, nadawcę i treść, a nie jest jedną masą znaków. Gdy dziesiątki pracowników zajmuje się jednym procesem kredytowym, każda wiadomość musi trafić do właściwego pracownika oraz odpowiedniego osoby odpowiedzialnej za jej przetworzenie.

Stan. Proces akceptacji, który przechodzi przez agenta ds. kwalifikacji, agenta ds. ryzyka oraz agenta ds. zatwierdzenia, musi zachowywać informacje o stanie przez wiele wymian danych. ACP określa zasady przypinania i aktualizowania współdzielonego stanu, takiego jak przeprowadzone sprawdzenia i dokumenty w toku, aby żaden agent nie stracił kontroli nad aplikacją, nawet jeśli proces trwa kilka dni.

Pamięć. Krótkoterminowa pamięć rozmowy, powiązana z aktualną aplikacją, jest przechowywana oddzielnie od długoterminowej pamięci przenoszonej między sesjami – na przykład znane preferencje klienta dotyczące kredytu hipotecznego o stałej stopie procentowej, które powinny kierować rozmową bez konieczności powtarzania pytań.

Obsługa błędów. Nieudana próba połączenia z agentem w bankowości nie może po prostu zniknąć. Załóżmy, że agent ds. ryzyka nie może pobrać raportu kredytowego z powodu awarii w kolejnym etapie procesu. ACP określa strukturyzowane błędy, co umożliwia agentowi koordynującemu decyzję wybór między kolejną próbą, przekazaniem zadania ludzkiemu ekspertowi lub wstrzymaniem procesu, a także zapobiega temu, by częściowa lub błędna decyzja przeszła niezauważona.

Jak porównują się te pięć rozwiązań

Gdy umieścić je obok siebie, opcje różnią się pod kilkoma względami:

• To, co łączy. Zwykłe API łączą jedną aplikację z drugą. Wywołania narzędzi łączą model z funkcją. MCP łączy model lub aplikację z narzędziami, danymi i poleceniami. A2A łączy agenty ze sobą. ACP łączy agenty ze sobą na poziomie wiadomości.
• Standaryzacja pomiędzy dostawcami. Zwykłe API – nie. Wywołania narzędzi – częściowo. MCP, A2A i ACP – tak.
• Odkrywanie możliwości. Brak takiej funkcji w przypadku zwykłych API i wywoływania narzędzi. Działa dynamicznie w MCP, poprzez karty agentów w przypadku A2A, a w ACP jest ograniczone.
• Wbudowane konwencje stanu i pamięci. Brak takich konwencji w przypadku zwykłych API i wywoływania narzędzi, częściowe w MCP i A2A, natomiast stanowią one główny element w ACP.
• Przykład z bankowością. System bankowości podstawowej komunikujący się z CRM; asystent wywołujący zaimplementowaną funkcję sprawdzania salda; asystent odkrywający i wywołujący narzędzia bankowości podstawowej, związane z oszustwami i dokumentami, w sposób jednolity; agent zajmujący się oszustwami delegujący zadania agentowi odpowiedzialnemu za weryfikację zgodności; śledzenie stanu zatwierdzenia pożyczki trwającej kilka dni pomiędzy trzema agentami.

Te opcje są uzupełnieniami, a nie konkurentami. Asystent bankowy w procesie produkcji prawdopodobnie połączy MCP w celu łączenia agentów z systemami centralnymi, A2A do delegowania zadań między specjalistami oraz konwencje ACP do zarządzania długimi procesami wielu agentów, takimi jak proces akceptacji kredytów, od początku do końca.

Jedna wiadomość od klienta, od początku do końca

Weźmy prostą sytuację: klient nie rozumie opłaty w wysokości pięciuset dolarów i chce jednocześnie dowiedzieć się o lepszej stopie oprocentowania kredytu hipotecznego. Cały system reaguje krok po kroku.

1. Klient wysyła wiadomość do Asystenta AI, aplikacji-hostującej w ramach aplikacji bankowej.
2. Dzięki A2A asystent przekazuje pytanie dotyczące oszustwa Agentowi ds. oszustw, a pytanie o kredyt hipoteczny Agentowi ds. kredytów, przy czym oba procesy działają jednocześnie.
3. Agent ds. oszustw łączy się z serwerem CRM za pośrednictwem MCP w celu uzyskania historii kontaktów i skarg, a także z serwerem bankowości core w sprawie spornej transakcji. Po zastosowaniu swoich zasad wykrywania oszustw wywołuje funkcję place_transaction_hold serwera bankowości core, ponownie przez MCP. To żądanie trafia do analityka ludzkiego w celu potwierdzenia przed wykonaniem, ponieważ zmienia stan transakcji.
4. Agent ds. kredytów pobiera aktualne warunki hipoteki oraz profil kredytowy z serwera bankowości core za pośrednictwem MCP, porównuje je z obecnymi tabelami stóp procentowych i opracowuje rekomendację. Oferta nowej stopy procentowej wymaga zatwierdzenia od osoby odpowiedzialnej za ocenę kredytową, dlatego nic nie jest wykonywane, a rekomendacja oraz dane pomocnicze są przekazywane do zestawienia przeznaczonego dla ludzi.
5. Oba agenci zgłaszają wyniki działania asystentowi poprzez A2A, używając zstrukturyzowanych wiadomości w stylu ACP, które zawierają informacje o stanie sprawy, oczekujących zatwierdzeniach od ludzi oraz ustaleniach.
6. Asystent wykorzystuje MCP, aby wysłać klientowi e-mail potwierdzający wstrzymanie operacji, a także rejestruje każde wezwanie narzędzia, przekazanie obowiązków oraz granice decyzyjne w systemie audytowym, ponieważ organy regulacyjne oczekują dokładnie takiego śladu w przypadku ponownego przeanalizowania sprawy.

Interoperacyjność w banku wygląda zatem w ten sposób: nie ma jednego ogromnego modelu, który próbuje robić wszystko, lecz specjalistyczni agenci z kontrolowanym dostępem do narzędzi, z których każdy doskonale wykonywa swoją pracę, a wszystko to jest poprzedzone czystym śladem audytowym.

Bezpieczeństwo pomiędzy agentami i protokołami

• Iniekcja poleceń. Wroga instrukcja ukryta w dokumencie, e-mailu lub załadowanym pliku może próbować przejąć kontrolę nad kolejnym ruchem agenta. Wyobraźmy sobie sfałszowany spór zawierający ukryty tekst, który nakazuje agentowi ds. oszustw zatwierdzić roszczenie bez weryfikacji. Narzędzia MCP zmieniają rzeczywisty stan, więc zagrożenie jest rzeczywiste. Środki zaradcze: traktuj wszystkie pobrane treści jako niewiarygodne, nigdy nie pozwólaj wynikom modelu uruchomić narzędzia o wysokim ryzyku, takiego jak place_transaction_hold, bez sprawdzenia zgodności z zasadami, oraz ogranicz dostępne narzędzia, które model może widzieć w danym kontekście.
• Autoryzacja. Każde połączenie klient-serwer w MCP oraz każda wymiana danych typu A2A wymaga autoryzacji, zwykle OAuth 2.1, dzięki czemu anonimowy użytkownik nie może uruchomić narzędzia bankowego ani przydzielić zadań agentowi ds. przestrzegania przepisów.

Uprawnienia. Autoryzacja określa, kto dzwoni, natomiast uprawnienia wskazują, co dana osoba może robić. Nawet po autoryzacji agent ds. oszustw nie powinien mieć dostępu do narzędzi umożliwiających zmianę stopy kredytowej, ponieważ leży to poza zakresem jego kompetencji, bez względu na to, jak przekonujące wydają się jego uzasadnienia.

Zero trust. Żaden element łańcucha nie jest uznawany za wiarygodny domyślnie – ani model, ani inny agent, ani serwer końcowy. Zasady są sprawdzane przy każdej realizacji połączenia, a nie ignorowane tylko dlatego, że połączenie powstało wewnątrz systemu AI banku.

Ludzka akceptacja. Działania o znaczeniu finansowym, bezpieczeństwa lub regulacyjnym, takie jak zamrożenie konta, zniesienie blokady lub zatwierdzenie pożyczki, wymagają potwierdzenia przez człowieka. Jest to decyzja projektowa dostosowana do istoty zagrożenia, a nie wada technologii.

Ślady audytowe. Rejestruj każde wezwanie narzędzia, delegację oraz zmianę stanu w wystarczająco dużym stopniu szczegółowo, aby móc odtworzyć to, co się wydarzyło i dlaczego. Jeśli organ nadzorczy zapyta, dlaczego konto było zablokowane przez sześć godzin, bank musi być w stanie pokazać dokładną sekwencję decyzji pracowników i wezwań narzędzi, a nie jedynie szacunki.

Kierunek rozwoju

Kierunek ruchu jest łatwy do odczytania. Protokoły takie jak MCP stają się warstwą sterowników urządzeń w sztucznej inteligencji, standardową ścieżką od dowolnego modelu do dowolnego narzędzia bez konieczności tworzenia specjalnych rozwiązań. Można oczekiwać, że systemy operacyjne oparte na sztucznej inteligencji staną się odrębną kategorią, w której serwery w stylu MCP będą stanowić infrastrukturę pierwszej klasy, podobną do baz danych i kolejków wiadomości, a serwer bankowy będzie elementem, do którego każdy wewnętrzny projekt oparty na sztucznej inteligencji będzie mógł się podłączyć bez konieczności jego ponownego tworzenia. Oczekuje się również rynków serwerów przeszczegółowo sprawdzonych i audytowanych, dzięki czemu bank może zastosować serwer weryfikacji KYC zatwierdzony pod kątem zgodności z regulacjami, zamiast go samodzielnie projektować. Rozwijają się również narzędzia do zarządzania, które umożliwiają audyt wywołań MCP oraz delegacji typu A2A, ponieważ zespoły odpowiedzialne za zgodność z regulacjami i zarządzanie ryzykiem będą potrzebować takiej przejrzystości, zanim cokolwiek z tego dotknie rzeczywistych pieniędzy. Można się spodziewać, że te same wzorce dotrą daleko poza bankowość, do każdej dziedziny, w której systemy rozumowania potrzebują standardowego, audytowalnego sposobu działania w świecie.

Wersja skrócona

Sam model nie może sprawdzić salda, nałożyć blokady ani ocenić kredytu hipotecznego. Standard MCP standaryzuje sposób dostępu do narzędzi, danych i poleceń, umożliwiając asystentowi ds. oszustw i asystentowi ds. pożyczek dzielenie się jednym serwerem bankowym bez konieczności powtarzającej się integracji. Standard A2A standaryzuje sposób przekazywania zadań pomiędzy specjalistycznymi agentami bez konieczności poznawania ich wewnętrznej struktury. Standard ACP standaryzuje komunikację, zarządzanie stanem oraz obsługę błędów w długich procesach, takich jak zatwierdzanie pożyczek trwających kilka dni. W bankach protokoły te nie są jedynie udogodnieniami – to one umożliwiają skuteczne wdrażanie procedur autoryzacji, śledzenia działań oraz ludzkiego zatwierdzenia na dużą skalę.

Two zasady projektowe nie pasują do tego podejścia. MCP oddziela zasoby tylko do odczytu od narzędzi zmieniających stan, a projekt autoryzacji powinien podążać za tym podziałem, ponieważ sprawdzanie salda i wysyłanie sygnału carry niosą zupełnie różne ryzyko. Ponadto bramy zatwierdzenia przez ludzi oraz ślady audytowe przy każdej wywołanej procedurze są podstawowymi wymaganiami, więc powinny znajdować się w pierwszej linii kodu, a nie w późniejszych poprawkach.