Od chatbotów do agentów AI: MCP, A2A i systemy Multi-Agent
Co odróżnia agentów AI od chatbotów. Protokoły MCP i A2A, architektura agentów, orkiestracja Multi-Agent dla firm.
Chatbot odpowiada. Agent działa.
Ta różnica określa wartość AI w firmach w 2026 roku. Chatbot odpowiada na pytania: „Ile dni urlopu mi zostało?”. Agent realizuje procesy. Różnica nie jest stopniowa – jest fundamentalna.
Konkretny przykład: Pracownik zgłasza się na zwolnienie chorobowe. Agent HR przyjmuje zgłoszenie, sprawdza formularz pod kątem kompletności, porównuje okres z harmonogramem pracy, informuje kierownika zespołu, aktualizuje planowanie zasobów i dokumentuje zdarzenie w aktach osobowych. Cztery systemy, jeden agent, zero ręcznych operacji. Każdy krok możliwy do prześledzenia, każdy krok w Audit Trail.
To nie jest scenariusz przyszłości. To stan techniki w 2026 roku. I to jest powód, dla którego architektura agentów AI jest decyzją strategiczną, a nie zadaniem wyłącznie dla działu IT.
Ten artykuł opisuje architekturę agentów dla środowisk korporacyjnych, wyjaśnia nowe standardy MCP i A2A, przedstawia pięć konkretnych przypadków biznesowych z potencjałem oszczędności i definiuje wymagania Governance, bez których żaden agent nie powinien trafić na produkcję.
Architektura agenta: pięć warstw
Agent AI nie jest systemem monolitycznym. Architektura korporacyjna składa się z pięciu warstw, z których każda ma jasno zdefiniowaną odpowiedzialność:
┌─────────────────────────────────────────┐
│ Interfejs użytkownika │
│ (very-ai / Teams / Custom) │
├─────────────────────────────────────────┤
│ Warstwa orkiestracji │
│ (Routing, silnik reguł, eskalacja) │
├─────────────────────────────────────────┤
│ Warstwa modelu AI │
│ (Claude / GPT / Llama – zależnie od │
│ zadania) │
├─────────────────────────────────────────┤
│ Integracja narzędzi (MCP) │
│ (ERP, CRM, DMS, e-mail, kalendarz...) │
├─────────────────────────────────────────┤
│ Governance & Audit Layer │
│ (Logowanie, polityki, Human-in-the-Loop)│
└─────────────────────────────────────────┘
Interfejs użytkownika. Warstwa, przez którą pracownicy wchodzą w interakcję z agentem. Może to być dedykowany portal AI (jak opisano w artykule Portal Enterprise AI: Więcej niż interfejs czatu), integracja z Microsoft Teams lub dedykowany interfejs dla konkretnych działów.
Warstwa orkiestracji. Tu zapada decyzja, który agent przejmuje zadanie, który model zostanie użyty i kiedy nastąpi eskalacja. Warstwa orkiestracji zna zestawy reguł, zakresy odpowiedzialności i ścieżki eskalacji. To centrum dowodzenia.
Warstwa modelu AI. Model językowy wykonujący właściwe przetwarzanie: rozumienie tekstu, rozpoznawanie zależności, generowanie odpowiedzi. W architekturze niezależnej od modelu warstwa ta jest wymienna. Tańszy model do standardowych zapytań, wydajniejszy do złożonych analiz. Routing odbywa się automatycznie.
Integracja narzędzi (MCP). Połączenie z istniejącymi systemami: ERP, CRM, zarządzanie dokumentami, e-mail, kalendarz, system ticketowy. Przez Model Context Protocol (MCP) agenci uzyskują standaryzowany dostęp do tych systemów.
Governance & Audit Layer. Każda akcja agenta jest rejestrowana. Polityki definiują, co agent może, a czego nie może robić. Human-in-the-Loop jest wymuszany tam, gdzie jest wymagany. Ta warstwa nie jest opcjonalna. Jest warunkiem wstępnym wdrożenia produkcyjnego. Decision Layer stanowi architektoniczny fundament tego Governance.
MCP i A2A: nowe standardy
Dwa protokoły zmieniły w latach 2025/2026 sposób komunikacji agentów AI ze światem zewnętrznym i między sobą: MCP (Model Context Protocol) i A2A (Agent-to-Agent).
MCP: Port USB dla AI
MCP to otwarty standard umożliwiający modelom AI dostęp do zewnętrznych źródeł danych i narzędzi. Analogia jest trafna: tak jak USB stworzył uniwersalny interfejs dla sprzętu, MCP tworzy uniwersalny interfejs dla integracji AI.
Przed MCP dla każdej kombinacji modelu AI i systemu docelowego trzeba było budować osobny konektor. Agent A łączy się z SAP – jeden konektor. Agent B łączy się z DMS – kolejny konektor. Agent C łączy się z kalendarzem – jeszcze jeden konektor. Przy dziesięciu systemach i trzech modelach daje to trzydzieści indywidualnych integracji.
Z MCP każdy system definiuje swoje możliwości raz, w standaryzowanym formacie: Jakie dane może dostarczyć? Jakie akcje może wykonać? Jakie parametry są wymagane? Każdy model kompatybilny z MCP może korzystać z tych możliwości bez kodu specyficznego dla systemu.
Dla firm oznacza to: nowe systemy można podłączać szybciej. Modele można wymieniać bez przebudowy integracji. Zależność od pojedynczych dostawców modeli maleje.
A2A: Agenci rozmawiają ze sobą
A2A (Agent-to-Agent) jest odpowiednikiem MCP dla komunikacji między agentami. Podczas gdy MCP reguluje połączenie agent-system, A2A reguluje połączenie agent-agent.
Dlaczego to istotne? Ponieważ złożone procesy biznesowe rzadko są obsługiwane przez jednego agenta. Zgłoszenie chorobowe dotyczy HR, planowania zasobów, listy płac i potencjalnie zarządzania projektami. Każdy obszar ma wyspecjalizowanego agenta. A2A umożliwia tym agentom delegowanie zadań i wymianę wyników – z zdefiniowanymi uprawnieniami.
Co kluczowe: A2A nie oznacza współdzielonego dostępu do danych. Agent HR przekazuje agentowi Finance informację „Pracownik X jest nieobecny od daty Y”, a nie pełne akta osobowe. Każdy agent widzi tylko to, czego potrzebuje do swojego zadania. Granice uprawnień pozostają nienaruszone.
5 przypadków biznesowych z konkretnym potencjałem oszczędności
Pytanie, które zadają decydenci, to nie „Co potrafi agent?” lecz „Co daje agent?”. Oto pięć przypadków użycia z mierzalnym potencjałem oszczędności:
| Obszar | Przypadek użycia | Co robi agent | Potencjał oszczędności |
|---|---|---|---|
| HR | Onboarding | Zakładanie kont, przydzielanie szkoleń, planowanie spotkań wprowadzających, wysyłka maila powitalnego | 4-6 godz. na zatrudnienie |
| Finanse | Weryfikacja faktur | Odczyt faktury, weryfikacja z zamówieniem, kontrola kontowania, uruchomienie workflow zatwierdzenia | 70-80% mniej czasu przetwarzania |
| Dział prawny | Analiza umów | Ekstrakcja klauzul, porównanie ze standardowymi umowami, oznaczanie odchyleń | Godziny zamiast dni |
| IT | Triażowanie incydentów | Analiza zgłoszenia błędu, porównanie z known issues, tworzenie ticketu z priorytetem | Szybsza pierwsza reakcja |
| Operacje | Monitoring dostawców | Śledzenie terminów dostaw, porównanie z planem produkcji, proaktywne powiadomienie o opóźnieniu | Wczesne ostrzeganie zamiast naprawy |
Każdy z tych przypadków użycia podąża za tym samym wzorcem: agent przejmuje strukturalną, opartą na regułach część procesu. Człowiek zajmuje się wyjątkami, decyzjami wymagającymi oceny i zatwierdzeniami. Oszczędność czasu wynika nie z eliminacji pracy ludzkiej, lecz z eliminacji ręcznych czynności rutynowych.
Onboarding HR w szczegółach. Dziś pracownik kadr przy każdym nowym zatrudnieniu ręcznie koordynuje: zakładanie kont IT, konfigurację praw dostępu, przydzielanie obowiązkowych szkoleń, tworzenie planu wdrożenia, redagowanie maila powitalnego, konfigurację listy płac. Każdy krok to osobny system, każdy krok to ręczna operacja. Agent onboardingowy orkiestruje te kroki automatycznie: czyta umowę o pracę, rozpoznaje stanowisko, lokalizację i dział, i wykonuje kroki w odpowiednich systemach. Pracownik kadr zatwierdza cały proces, nie każdy pojedynczy krok.
Weryfikacja faktur w szczegółach. Faktura przychodząca jest odczytywana przez Document Agent. Agent wyodrębnia wystawcę, kwotę, pozycje, numer zamówienia. Automatycznie weryfikuje: Czy istnieje powiązane zamówienie? Czy pozycje i kwoty się zgadzają? Czy kontowanie jest prawidłowe? Czy kwota mieści się w granicach zatwierdzenia? Przy wyniku pozytywnym księgowanie jest przygotowywane. Przy odchyleniach sprawa jest eskalowana do odpowiedzialnego pracownika – z konkretnym powodem odchylenia, nie z generycznym komunikatem „Proszę sprawdzić”.
Wymagania Governance dla agentów
Agent bez Governance to ryzyko. Cztery wymagania muszą być spełnione przed wdrożeniem produkcyjnym:
1. Decision Layer. Każda decyzja agenta przechodzi przez Decision Layer. Dla każdej mikrodecyzji zdefiniowano: Czy agent może działać autonomicznie, czy obowiązuje zestaw reguł, czy musi zatwierdzić człowiek? Te reguły są wersjonowane, możliwe do prześledzenia i nie mogą być modyfikowane przez samego agenta.
2. Human-in-the-Loop. Przy zdefiniowanych typach decyzji architektura wymusza ludzką weryfikację. To nie jest funkcja, którą można aktywować. To zasada architektoniczna. Agent nie może obejść wymagania Human-in-the-Loop, ponieważ jest ono wymuszone technicznie, nie uzgodnione organizacyjnie.
3. Audit Trail. Każda akcja agenta generuje niezmienny wpis w dzienniku: Co było inputem? Który model został użyty? Która reguła została zastosowana? Jaki był wynik? Kiedy akcja została wykonana? Audit Trail jest podstawą audytu finansowego, rewizji wewnętrznej i kontroli Rady Zakładowej.
4. Rollback. Każda akcja agenta musi być odwracalna. Jeśli agent wygeneruje błędne księgowanie lub wyśle nieprawidłowe powiadomienie, proces musi dać się skorygować – technicznie, nie tylko organizacyjnie. Zdolność do rollbacku jest wymaganiem architektonicznym, nie późniejszym dodatkiem.
Te cztery wymagania są nienegocjowalne. Bez nich żadna Rada Zakładowa nie wyda pozytywnej opinii w procesie konsultacji, żaden biegły rewident nie zatwierdzi i żaden CIO nie przyjmie odpowiedzialności. Więcej o architekturze Governance w następnym artykule: Decision Layer & Shadow AI.
Systemy Multi-Agent: specjalizacja zamiast uniwersalnego agenta
Następny poziom po pojedynczym agencie: wielu wyspecjalizowanych agentów współpracujących ze sobą. Nie jeden uniwersalny agent, który potrafi wszystko, lecz specjaliści, z których każdy opanował jedną domenę.
Przykład zgłoszenia chorobowego jako system Multi-Agent:
Zgłoszenie chorobowe otrzymane
│
Document Agent → Odczytuje i klasyfikuje zgłoszenie chorobowe
│
HR Agent → Sprawdza reguły: wynagrodzenie chorobowe, reintegracja, terminy
│
Workflow Agent → Informuje kierownika, aktualizuje harmonogram
│
Finance Agent → Aktualizuje listę płac
Każdy agent ma własne uprawnienia. Document Agent może czytać dokumenty, ale nie może tworzyć księgowań. Finance Agent może aktualizować listę płac, ale nie ma dostępu do akt osobowych. Granice uprawnień są wymuszone architektonicznie. Przez protokół A2A agenci komunikują tylko informacje, których agent odbierający potrzebuje do swojego zadania.
Agent orkiestrator koordynuje cały przebieg. Wie, który agent wykonuje który krok, w jakiej kolejności i co dzieje się w przypadku błędów. Orkiestrator ma przegląd, ale nie ma uprawnień operacyjnych. Deleguje, ale sam nie wykonuje.
Systemy Multi-Agent są wydajne, ale złożone. Liczba interakcji rośnie kwadratowo wraz z liczbą agentów. Debugowanie staje się bardziej pracochłonne. Wymagania Governance rosną.
Zalecenie praktyczne: zacznij od małego
Pokusa, by od razu zacząć od systemu Multi-Agent, jest duża. Zalecenie jest jasne: zacznij od jednego agenta dla jasno zdefiniowanego procesu.
Krok 1: Zidentyfikuj proces, który jest strukturalny, oparty na regułach i wystarczająco częsty, by uzasadnić nakład pracy. Weryfikacja faktur, onboarding, analiza umów – wybierz jeden.
Krok 2: Wdróż jednego agenta AI dla tego procesu. Z Decision Layer, z Human-in-the-Loop, z Audit Trail. Nie jako prototyp, lecz jako system produkcyjny.
Krok 3: Mierz. Czas przetwarzania przed i po. Wskaźnik błędów. Koszt na transakcję. Satysfakcja pracowników operacyjnych.
Krok 4: Dopiero gdy pierwszy agent działa stabilnie, planuj drugiego. I dopiero gdy wielu agentów działa stabilnie, myśl o orkiestracji Multi-Agent.
To podejście nie jest zachowawcze. Jest pragmatyczne. Działający agent z udowodnioną wartością jest więcej wart niż ambitna koncepcja Multi-Agent, która utknęła w fazie pilotażu.
Infrastruktura – hosting modeli, wektorowe bazy danych, silnik orkiestracji, API gateway – jest budowana przy pierwszym agencie i jest dostępna dla każdego kolejnego. Inwestycja w pierwszego agenta jest jednocześnie inwestycją w platformę.
Konkretny przykład: W portalu Enterprise AI very-ai użytkownicy mogą bezpośrednio z czatu uruchamiać przepływy n8n. Agent staje się wyzwalaczem łańcucha procesów – nie tylko rozmówcą. Platforma orkiestracji (→ Artykuł 10) przejmuje realizację.
Gdzie te agenty faktycznie działają, na jakiej platformie, pokazuje Artykuł 10: Orkiestracja agentów.
Enterprise AI-Infrastruktur Blueprint 2026 – Seria artykułów
| ← Poprzedni | Przegląd | Następny → |
|---|---|---|
| RAG i Document Intelligence: Jak AI rozumie Twoje dokumenty | Przegląd | Decision Layer & Shadow AI: Kontrola zamiast chaosu |
Wszystkie artykuły w tej serii: Enterprise AI-Infrastruktur Blueprint 2026
Chcesz wdrożyć pierwszego agenta AI dla konkretnego procesu biznesowego? Gosign wspiera klientów korporacyjnych od analizy procesu do produkcyjnego agenta – niezależnie od modelu, z Decision Layer i pełnym Audit Trail.
Umów spotkanie. 30 minut, w których zidentyfikujemy właściwy pierwszy przypadek użycia dla Twojej firmy.