Architektura agentów AI w przedsiębiorstwie: kiedy jeden agent wystarczy – a subagenci szkodzą

1. Kontekst rynkowy i ramy biznesowe (Executive Summary)

Październik 2024 przyniósł istotny sygnał ze strony Anthropic — twórców modelu Claude — który powinien trafić na biurka każdego dyrektora technicznego i architekta IT odpowiedzialnego za wdrożenia sztucznej inteligencji w przedsiębiorstwie. Opublikowany przewodnik inżynieryjny pt. „When to fold subagents into your main agent loop" obala jeden z najczęstszych mitów ery agentowej AI: że im więcej wyspecjalizowanych subagentów, tym system jest potężniejszy i bardziej skalowalny.

Rzeczywistość inżynieryjna jest znacznie bardziej wymagająca. W ciągu ostatnich dwóch lat rynek agentów AI rozwinął się w zawrotnym tempie. Organizacje — często pod presją konkurencji i narracji marketingowej dostawców — budowały rozległe sieci subagentów: jeden agent zbierał dane, drugi je analizował, trzeci generował raporty, czwarty decydował o kolejnych krokach. Efekt? Systemy trudne do debugowania, kosztowne w utrzymaniu, podatne na kaskadowe błędy i o wiele mniej przewidywalne niż zakładano na etapie projektowania.

Dla zarządów i właścicieli MŚP, którzy zainwestowali lub planują inwestycje w AI, ten sygnał ma konkretne implikacje strategiczne:

• Koszty operacyjne: każdy dodatkowy subagent to dodatkowe tokeny, wywołania API, latencja i ryzyko błędu propagowanego przez cały pipeline.
• Niezawodność: złożone grafy agentów mają wykładniczo więcej punktów awarii niż jeden dobrze zaprojektowany główny pętla z narzędziami.
• Zgodność i audytowalność: w środowisku regulowanym (RODO, NIS2, KSeF) każdy nieoczekiwany wynik agenta musi być możliwy do prześledzenia — co przy głębokiej hierarchii subagentów jest niemal niemożliwe.
• ROI: uproszczenie architektury skraca czas wdrożenia, obniża koszty infrastruktury i przyspiesza moment osiągnięcia realnej wartości biznesowej.

W AbejaIT od 2003 roku projektujemy systemy, które muszą działać niezawodnie w środowiskach o krytycznym znaczeniu — skupy złomu, składy węgla, ogrody działkowe, systemy ERP. Wdrożenia AI nie są dla nas eksperymentem — są inżynieryjnym zadaniem, które musi przynosić wymierny efekt. Dlatego podejście „najpierw upraszczaj" jest nam bliskie z natury.

2. Dogłębna analiza techniczna i wektory ryzyka

Zanim przejdziemy do rekomendowanej architektury, warto zrozumieć, dlaczego rozbudowane sieci subagentów są tak kuszące — i dlaczego w praktyce zawodzą.

Mit skalowalności przez specjalizację

Intuicja podpowiada, że podział pracy między wyspecjalizowanych agentów powinien działać tak samo jak w przypadku ludzkich zespołów: jeden specjalista od finansów, drugi od logistyki, trzeci od obsługi klienta. Problem polega na tym, że modele językowe (LLM) nie działają jak ludzie. Każde wywołanie subagenta to nowy kontekst, nowy koszt tokenów i — co kluczowe — ryzyko utraty spójności kontekstowej między wywołaniami.

W praktyce oznacza to, że subagent B może podjąć decyzję sprzeczną z tym, co ustalił subagent A, ponieważ nie ma dostępu do pełnego kontekstu rozmowy. Wynik: błędy, które są trudne do wychwycenia w testach, ale katastrofalne w produkcji.

Wektory ryzyka w architekturach wieloagentowych

• Prompt injection między agentami: złośliwe dane wejściowe mogą być przekazywane przez pipeline agentów, eskalując uprawnienia lub zmieniając intencje zadania. To poważny wektor ataku w systemach B2B przetwarzających dane zewnętrzne.
• Token bloat i koszty ukryte: każde wywołanie agenta generuje koszty. Przy 10 subagentach obsługujących jedno zapytanie, koszt może być 5–20× wyższy niż przy jednym dobrze zaprojektowanym agencie z narzędziami.
• Latencja kaskadowa: sekwencyjne wywołania subagentów sumują opóźnienia. W systemach czasu rzeczywistego (np. integracje z wagami, systemy ERP) latencja powyżej 2–3 sekund jest nieakceptowalna biznesowo.
• Brak deterministyczności: wieloagentowe systemy są z natury niedeterministyczne. Dla systemów wymagających audytu (np. transakcje finansowe, dokumenty podatkowe) to poważne ryzyko regulacyjne.
• Trudność debugowania: gdy system wieloagentowy zwróci błędny wynik, identyfikacja przyczyny wymaga analizy każdego węzła grafu — co przy produkcyjnych systemach 24/7 jest kosztowne i czasochłonne.
• Ryzyko pętli i deadlocków: agenci mogą wzajemnie na siebie czekać lub wywoływać się rekurencyjnie, prowadząc do zawieszenia całego systemu.

Kluczowa obserwacja Anthropic: redukcja promptu Claude Code o ponad 80%

Jednym z najbardziej wymownych przykładów z przewodnika Anthropic jest informacja, że zredukowali system prompt Claude Code o ponad 80% — bez utraty funkcjonalności, a z zyskiem na niezawodności i przewidywalności. To nie jest kosmetyczna zmiana. To fundamentalna rewizja myślenia o tym, jak model powinien rozumieć swoje zadanie. Zamiast instruować każdy możliwy przypadek brzegowy przez dedykowane subagenty, wystarczy jeden dobrze skalibrowany kontekst z dynamicznym dostępem do narzędzi.

3. Architektura rozwiązania i przewodnik wdrożeniowy krok po kroku

Poniżej przedstawiamy wzorcową architekturę agenta AI dla środowiska B2B, zgodną z rekomendacjami Anthropic i zweryfikowaną w praktyce przez inżynierów AbejaIT.

Zasada #1: Jeden model, jedno okno kontekstowe, jeden główny loop

Domyślna architektura powinna opierać się na jednym modelu LLM (np. Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro) działającym w ramach jednego ciągłego okna kontekstowego. Subagenci powinni być wprowadzani tylko wtedy, gdy istnieje udowodniona potrzeba równoległości lub izolacji bezpieczeństwa — nie jako domyślny wzorzec projektowy.

Zasada #2: Tool search zamiast specjalizowanych subagentów

Zamiast tworzyć oddzielnego agenta dla każdej funkcji (agent bazodanowy, agent mailingowy, agent raportujący), model powinien mieć dostęp do repozytorium narzędzi i dynamicznie wybierać odpowiednie w danym kontekście. To podejście RAG (Retrieval-Augmented Generation) zastosowane do samych narzędzi — agent „szuka" właściwego narzędzia tak samo, jak szuka właściwego fragmentu dokumentu.

# Przykład konfiguracji tool registry w Pythonie
tools = [
    {
        "name": "query_erp_database",
        "description": "Zapytaj system ERP o stan magazynu, faktury lub rozrachunki",
        "parameters": {"query": "string", "module": "enum[warehouse, invoices, crm]"}
    },
    {
        "name": "send_notification",
        "description": "Wyślij powiadomienie email lub SMS do użytkownika lub kontrahenta",
        "parameters": {"recipient": "string", "message": "string", "channel": "enum[email, sms]"}
    },
    {
        "name": "generate_document",
        "description": "Wygeneruj dokument PDF (faktura, WZ, raport) na podstawie danych",
        "parameters": {"template": "string", "data": "object"}
    },
    {
        "name": "search_bdo_registry",
        "description": "Sprawdź numer BDO kontrahenta w bazie danych BDO",
        "parameters": {"nip": "string"}
    }
]

# Agent decyduje, których narzędzi użyć na podstawie kontekstu
# Nie potrzebuje osobnych subagentów dla każdej funkcji

Zasada #3: Skills jako zorganizowane bloki promptów

Zamiast delegować do subagenta, warto zdefiniować umiejętności (skills) — predefiniowane bloki instrukcji, które agent aktywuje w zależności od kontekstu. Skill to nie osobny model — to fragment promptu ładowany dynamicznie do okna kontekstowego głównego agenta.

# Przykład struktury skills w konfiguracji YAML
skills:
  - name: "analiza_faktury"
    trigger: "faktura|invoice|VAT|KSeF"
    context_injection: |
      Analizujesz dane faktury w kontekście polskich przepisów podatkowych.
      Sprawdź: NIP kontrahenta, stawki VAT, termin płatności, zgodność z KSeF.
      Zwróć uwagę na split payment przy transakcjach powyżej 15 000 PLN.

  - name: "analiza_kkio"
    trigger: "złom|surowiec|BDO|KPO|odpady"
    context_injection: |
      Analizujesz dane w kontekście skupu surowców wtórnych.
      Sprawdź: numer BDO, limity gotówkowe (ustawa o ograniczeniu płatności),
      wymagania dla kart KPO/KPOk, formularzy FPO.

Zasada #4: Kiedy subagenci są uzasadnieni

Subagenci mają sens tylko w konkretnych scenariuszach:

• Prawdziwa równoległość: 50 niezależnych zadań musi być wykonanych jednocześnie, a ich wyniki zebrane (fan-out/fan-in pattern).
• Izolacja bezpieczeństwa: agent przetwarzający dane z zewnętrznych, niezaufanych źródeł powinien działać w izolowanym sandbox — bez dostępu do wewnętrznych systemów.
• Przekroczenie okna kontekstowego: zadanie wymaga przetworzenia danych przekraczających limit tokenów jednego wywołania.
• Specjalistyczne modele: np. model wizyjny do OCR dokumentów + model językowy do analizy — różne modalności wymagają różnych modeli.

Infrastruktura dla agentów AI w środowisku B2B

Wzorcowa architektura infrastruktury dla produkcyjnego agenta AI w firmie:

# Docker Compose – minimalna produkcyjna architektura agenta AI
version: '3.9'
services:
  agent-api:
    image: abejait/agent-api:latest
    environment:
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - DATABASE_URL=postgresql://agent:${DB_PASS}@postgres:5432/agentdb
      - REDIS_URL=redis://redis:6379
    ports:
      - "8080:8080"
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3

  postgres:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: agentdb
      POSTGRES_USER: agent
      POSTGRES_PASSWORD: ${DB_PASS}

  redis:
    image: redis:7-alpine
    command: redis-server --appendonly yes
    volumes:
      - redisdata:/data

  nginx:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/ssl/certs:ro

volumes:
  pgdata:
  redisdata:

4. Inżynieryjna checklista wdrożeniowa i audytowa

• ☑ Audyt istniejącej architektury: zinwentaryzuj wszystkich subagentów — dla każdego z nich odpowiedz: „czy ten subagent musi być osobnym modelem, czy wystarczy narzędzie lub skill w głównym agencie?"
• ☑ Pomiar kosztów tokenów: zmierz dokładny koszt każdego wywołania agenta w produkcji (inputy + outputy) — wiele organizacji odkrywa, że 60–80% kosztów generuje overhead komunikacji między agentami, nie samo zadanie.
• ☑ Benchmark latencji: zmierz end-to-end latencję aktualnego systemu i porównaj z jednopętlową architekturą na tym samym zadaniu testowym.
• ☑ Test prompt injection: przeprowadź testy bezpieczeństwa — sprawdź, czy dane z zewnętrznych źródeł (np. treść maili, dokumenty klientów) mogą zmodyfikować zachowanie agenta lub eskalować jego uprawnienia.
• ☑ Walidacja deterministyczności: dla kluczowych ścieżek biznesowych (generowanie faktur, dostęp do danych finansowych) zweryfikuj, czy agent zawsze produkuje ten sam wynik dla tego samego wejścia (lub czy odchylenia są dopuszczalne).
• ☑ Konfiguracja limitów i circuit breakers: każde wywołanie narzędzia powinno mieć timeout, retry policy i fallback — nigdy nie ufaj zewnętrznemu API bez mechanizmu odporności.
• ☑ Logowanie i audit trail: każda decyzja agenta musi być logowana (timestamp, wejście, wybrane narzędzie, wyjście) — wymaganie RODO i NIS2 dla systemów przetwarzających dane osobowe lub krytyczne biznesowo.
• ☑ Testy regresji po każdej zmianie promptu: przygotuj zestaw co najmniej 20 przypadków testowych (golden dataset) i uruchamiaj je automatycznie przy każdej modyfikacji systemu promptu.
• ☑ Monitoring kosztów API w czasie rzeczywistym: ustaw alerty na anomalie kosztowe — nagły wzrost liczby tokenów może oznaczać pętlę nieskończoną lub atak prompt injection.
• ☑ Plan Disaster Recovery dla agenta: co się dzieje, gdy API dostawcy LLM jest niedostępne? Czy system gracefully degraduje do alternatywnego modelu lub trybu manualnego?
• ☑ Przegląd uprawnień narzędzi: zasada minimalnych uprawnień — agent powinien mieć dostęp tylko do narzędzi i danych niezbędnych do wykonania konkretnego zadania, nie do całego systemu.
• ☑ Dokumentacja architektury: diagram przepływu danych (DFD) i diagram sekwencji dla każdej ścieżki agenta — wymaganie przy audytach bezpieczeństwa i wdrożeniach zgodnych z NIS2.

5. Wymogi prawne, podatkowe i zgodność regulacyjna

Wdrożenie agentów AI w środowisku B2B w Polsce i UE wiąże się z konkretnymi wymaganiami regulacyjnymi, które architekci systemów muszą uwzględnić już na etapie projektowania.

AI Act (Rozporządzenie UE 2024/1689)

Europejskie rozporządzenie o AI, które weszło w życie 1 sierpnia 2024 roku, klasyfikuje systemy AI według poziomów ryzyka. Agenci AI automatyzujący decyzje biznesowe (np. ocena zdolności kredytowej kontrahenta, automatyczna weryfikacja BDO, decyzje kadrowe) mogą zostać sklasyfikowani jako systemy wysokiego ryzyka, co nakłada obowiązki: dokumentacji technicznej, rejestracji w unijnej bazie, transparentności algorytmicznej i ludzkiego nadzoru nad decyzjami.

RODO i przetwarzanie danych przez agentów AI

Agent AI przetwarzający dane osobowe kontrahentów, pracowników lub klientów jest procesorem danych w rozumieniu RODO. Wymagania:

• Rejestr czynności przetwarzania (RCP) musi uwzględniać przetwarzanie przez AI.
• Dane osobowe nie mogą być wysyłane do zewnętrznych modeli AI bez odpowiedniej podstawy prawnej i umowy powierzenia (DPA) z dostawcą.
• Dla modeli hostowanych lokalnie (private inference) — wymagana jest ocena ryzyka (DPIA) przy przetwarzaniu danych wrażliwych.

Dyrektywa NIS2 i DORA

Dla podmiotów objętych NIS2 (operatorzy usług kluczowych, dostawcy usług cyfrowych) wdrożenie agentów AI w procesach krytycznych wymaga:

• Oceny ryzyka bezpieczeństwa łańcucha dostaw AI (w tym ryzyka od dostawców modeli).
• Planów ciągłości działania uwzględniających niedostępność zewnętrznych API LLM.
• Zgłaszania incydentów bezpieczeństwa związanych z działaniem systemów AI w ciągu 24/72 godzin.

KSeF i automatyzacja fakturowania przez AI

Agenci AI integrujący się z Krajowym Systemem e-Faktur muszą spełniać wymagania techniczne MF: schemat XML FA(2)/FA(3), podpisy kwalifikowane lub tokeny API KSeF, zgodność JPK_V7. Każda faktura wystawiona automatycznie przez agenta AI podlega tym samym wymogom co faktura wystawiona manualnie — błąd agenta nie jest okolicznością łagodzącą w przypadku kontroli skarbowej.

6. Analiza kosztów (TCO) vs Zwrot z inwestycji (ROI)

Decyzja o uproszczeniu architektury agentów AI ma bezpośrednie przełożenie finansowe. Poniżej szacunkowa analiza dla typowej firmy MŚP wdrażającej AI do automatyzacji procesów dokumentowych.

Koszty złożonej architektury wieloagentowej (scenariusz A)

• 5 subagentów obsługujących 1000 zapytań dziennie: średnio 8000 tokenów na zapytanie × 5 wywołań = 40 000 tokenów/zapytanie
• Koszt: ~0,12 USD/zapytanie × 1000 = 120 USD/dzień (~3600 USD/miesiąc)
• Dodatkowe koszty: debugowanie awarii (5h/tydzień × senior dev), latencja 8–15s (negatywny UX), trudność wdrożenia zmian
• Szacowany TCO roczny: ~65 000–80 000 PLN (API + utrzymanie + incydenty)

Koszty uproszczonej architektury jednopętlowej (scenariusz B)

• 1 główny agent + tool search: średnio 6000 tokenów/zapytanie (brak overheadu komunikacyjnego między agentami)
• Koszt: ~0,018 USD/zapytanie × 1000 = 18 USD/dzień (~540 USD/miesiąc)
• Redukcja kosztów debugowania: 80% (prostszy stack = łatwiejsza diagnostyka)
• Szacowany TCO roczny: ~12 000–18 000 PLN

ROI z uproszczenia architektury

Oszczędność roczna: 47 000–62 000 PLN przy tym samym wolumenie zapytań. Dodatkowo: szybsze wdrożenie nowych funkcji (czas refaktoryzacji narzędzi vs budowania nowych subagentów), wyższa niezawodność (mniej incydentów P1), łatwiejsza zgodność z wymogami audytowymi.

Wniosek AbejaIT: Uproszczenie architektury agentów AI o 80% złożoności może obniżyć koszty operacyjne o 50–85% przy tej samej lub wyższej jakości wyników. To jedna z najlepszych inwestycji optymalizacyjnych dostępnych dziś dla firm wdrażających AI.

7. Najczęściej zadawane pytania (FAQ)

Czy jeden agent AI może obsłużyć wszystkie procesy w firmie?

Nie — i nie o to chodzi w podejściu „single main loop". Jeden agent powinien odpowiadać za jeden spójny proces lub domenę (np. obsługa dokumentów przychodzących, wsparcie dla handlowców, analiza danych magazynowych). Dla różnych procesów warto mieć oddzielne, wyspecjalizowane konfiguracje agenta — ale każda z nich powinna być jak najprostsza wewnętrznie. Kluczowa różnica: separacja na poziomie konfiguracji i domeny, nie na poziomie modeli i subagentów wewnątrz jednego przepływu.

Jak bezpiecznie połączyć agenta AI z wewnętrznymi systemami ERP lub bazami danych?

Rekomendowana architektura: agent nigdy nie łączy się bezpośrednio z bazą danych — zamiast tego wywołuje dedykowane mikroserwisy API z granularnymi uprawnieniami (zasada least privilege). Każde narzędzie agenta to osobny endpoint API z własną autentykacją (API key lub OAuth2), rate limitingiem i logowaniem. Nigdy nie umieszczaj connection string do bazy danych w promptach systemowych agenta — to jeden z najpoważniejszych błędów bezpieczeństwa w systemach AI.

Jak mierzyć skuteczność agenta AI i kiedy przełączyć się na inną architekturę?

Kluczowe metryki to: success rate (% zadań zakończonych poprawnie bez interwencji człowieka), koszt per task (tokeny × cena), latencja end-to-end, false positive rate (% błędnych wyników wymagających korekcji) oraz error escalation rate (% zadań wymagających interwencji ludzkiej). Jeśli success rate spada poniżej 90% lub koszt per task rośnie wykładniczo wraz ze wzrostem złożoności zadań — to sygnał, że architektura wymaga rewizji. Dla większości zastosowań B2B benchmark: <3s latencja, >95% success rate, koszt <0,05 USD/task.

Czy można wdrożyć agenta AI z zachowaniem pełnej prywatności danych — bez wysyłania danych do chmury zewnętrznej?

Tak — i w wielu branżach regulowanych (finanse, ochrona zdrowia, dane osobowe pracowników) jest to wymaganie bezwzględne. Dostępne rozwiązania: prywatne instancje modeli open-source (Llama 3, Mistral, Qwen) hostowane na własnej infrastrukturze lub w prywatnej chmurze, fine-tuning modeli na danych firmowych bez wysyłania ich do dostawcy, oraz architektura RAG z lokalną bazą wektorową (Qdrant, Milvus, pgvector). AbejaIT oferuje wdrożenia prywatnych instancji modeli AI na zarządzanej infrastrukturze w Polsce, co eliminuje ryzyko przekazania danych poza jurysdykcję UE.

8. Dedykowane rozwiązania i wdrożenie w ekosystemie AbejaIT

W AbejaIT od ponad 23 lat budujemy systemy dla wymagających środowisk biznesowych. Nasze podejście do AI jest pragmatyczne: wdrażamy to, co działa niezawodnie i przynosi wymierny zwrot z inwestycji — nie to, co jest modne. Opisane w tym artykule zasady projektowania agentów (single main loop, tool search, skills) stosujemy w naszych własnych wdrożeniach oraz w projektach dla klientów.

Jeśli Twoja firma korzysta z naszych systemów branżowych, możliwości integracji AI są gotowe do uruchomienia:

• Dla skupów złomu i surowców wtórnych — system ESSW (zlom.io) z automatyczną weryfikacją BDO, obsługą kart KPO/KPOk i integracją z wagami może być uzupełniony o agenta AI analizującego trendy cenowe surowców, klasyfikującego odpady i generującego dokumenty FPO.
• Dla składów węgla i opału — platforma wegiel.io może korzystać z agenta AI do automatycznego wypełniania oświadczeń AKC-WW na podstawie danych z zamówień i ewidencji wyrobów węglowych.
• Dla firm zarządzających finansami i fakturami — system ERP mojafirma.io z integracją KSeF może być rozszerzony o agenta automatycznie opisującego faktury kosztowe, kontrolującego białą listę VAT i generującego raporty JPK.
• Dla zarządów Rodzinnych Ogrodów Działkowych — system dzialkowiec.io może korzystać z AI do automatycznego odpowiadania na zapytania działkowców, naliczania opłat i analizowania zużycia mediów.

Oferujemy również kompleksowe wdrożenia rozwiązań AI i agentów dla firm, które chcą zautomatyzować procesy niezwiązane z powyższymi branżami, a dla organizacji wymagających bezpiecznej infrastruktury — usługi infrastruktury IT z monitoringiem 24/7 i SLA gwarantującym ciągłość działania.

Skontaktuj się z naszym zespołem inżynierów: konsultacja z zespołem AbejaIT — bezpłatna analiza Twojego przypadku użycia AI i rekomendacja optymalnej architektury.

Źródło inspiracji: Anthropic Watch