Agenci AI dla Firm – Wdrożenie Agentów AI w Procesach Biznesowych

Z czego składa się agent AI w firmie – anatomia produkcyjnego wdrożenia

Produkcyjny agent AI to pętla modelu z narzędziami, otoczona warstwami kontroli: bramką uprawnień, punktami akceptacji człowieka, limitami i dziennikiem działań. Model odpowiada za rozumowanie, ale o tym, czy agent jest bezpieczny i przewidywalny, decyduje głównie to, co jest wokół niego.

Ta tabela jest też listą pytań do każdego wykonawcy. Jeśli w ofercie nie ma bramki uprawnień, limitów i dziennika, to dostajesz prototyp, a nie agenta gotowego do pracy na danych firmy. Jak działa sama pętla agenta, tłumaczę prostym językiem we wpisie agenci AI – czym są i jak działają.

Przykład: agent przygotowujący oferty – jak wygląda krok po kroku

Agent ofertowy to dobry przykład, bo łączy wszystko, co trudne: nieustrukturyzowany mail od klienta, kilka systemów, decyzje cenowe i komunikację na zewnątrz. Poniżej typowy przebieg, który projektuję, z zaznaczeniem, gdzie agent tylko czyta, gdzie zapisuje i gdzie decyduje człowiek.

1. Odczyt zapytania (tylko odczyt). Agent czyta maila i załączniki, wyciąga produkty, ilości, termin i dane firmy do ustrukturyzowanego formatu. Treść maila traktuje jako dane, nie jako polecenia.
2. Identyfikacja klienta (odczyt CRM). Sprawdza, czy firma jest w CRM, jaka jest historia zamówień, warunki płatności i przypisany handlowiec.
3. Dostępność i ceny (odczyt ERP i cennika). Sprawdza stany, terminy dostaw i cenę z uwzględnieniem rabatów przypisanych do klienta.
4. Pytania wyjaśniające (szkic). Jeśli brakuje danych, np. wymiaru albo ilości, przygotowuje szkic pytania do klienta zamiast zgadywać.
5. Szkic oferty (zapis w trybie roboczym). Tworzy ofertę w CRM jako szkic, z uzasadnieniem każdej pozycji i źródłem ceny.
6. Akceptacja (człowiek). Handlowiec dostaje powiadomienie z podsumowaniem, różnicami względem standardowego cennika i flagami ryzyka, np. rabat ponad próg albo nietypowy termin.
7. Wysyłka (po akceptacji). Dopiero zatwierdzona oferta jest wysyłana, a agent zapisuje w CRM aktywność i termin przypomnienia.

Agent nie ma tu prawa samodzielnie wysłać maila do klienta ani zmienić ceny w cenniku. Te ograniczenia nie wynikają z nieufności do modelu, tylko z prostego rachunku: koszt jednej błędnej oferty wysłanej do klienta jest wyższy niż koszt jednego kliknięcia handlowca. Architekturę automatyzacji ofert opisałem szerzej we wpisie jak skrócić czas przygotowania oferty, a integracje z systemami w tekstach o AI w CRM i AI w ERP.

Projektowanie narzędzi agenta – tool calling i MCP w praktyce

Jakość agenta w dużej mierze zależy od jakości jego narzędzi: ich liczby, nazw, opisów i tego, co zwracają. Anthropic we wpisie o pisaniu narzędzi dla agentów (wrzesień 2025) radzi nie opakowywać bezrefleksyjnie każdego endpointu API, tylko budować mniej narzędzi, dopasowanych do realnych zadań, bo więcej narzędzi nie oznacza lepszych wyników.

Zasady, które stosuję przy każdym narzędziu

• Osobne narzędzia do odczytu i zapisu. „Pobierz klienta” i „utwórz szkic oferty” to dwa narzędzia z różnymi uprawnieniami, a nie jedno ogólne „operuj na CRM”.
• Zapis jako szkic, nie jako wynik końcowy. Tam, gdzie system na to pozwala, agent tworzy wersję roboczą, a publikację lub wysyłkę wykonuje człowiek albo osobny, kontrolowany krok.
• Walidacja argumentów schematem. Każde wywołanie przechodzi przez JSON Schema i reguły biznesowe: dozwolone wartości, zakresy kwot, format NIP, istniejący identyfikator klienta.
• Idempotencja. Akcje zapisu mają klucz idempotencji, żeby ponowienie po błędzie sieci nie utworzyło dwóch faktur.
• Zrozumiałe błędy. Zamiast kodu 500 narzędzie zwraca komunikat, co poszło nie tak i co agent może zrobić. Anthropic zaleca takie komunikaty, bo model lepiej się z nimi koryguje.
• Oszczędne wyniki. Narzędzie zwraca pola potrzebne do decyzji, z paginacją i filtrami, a nie całą odpowiedź API, która zjada kontekst.
• Jednoznaczne nazwy i opisy. Parametr `customer_id` zamiast `user`, opis narzędzia napisany tak, jakby tłumaczyć je nowemu pracownikowi.

Szczegóły techniczne, w tym obsługę błędów i ponowień, opisałem we wpisie o tool calling w produkcji.

MCP – kiedy go używam, a kiedy nie

MCP (Model Context Protocol) to otwarty standard podłączania modeli do narzędzi i danych. W grudniu 2025 r. Anthropic przekazał go fundacji Agentic AI Foundation działającej w ramach Linux Foundation i podał, że istnieje ponad 10 000 aktywnych publicznych serwerów MCP. Dla firmy oznacza to, że raz zbudowany serwer MCP do CRM może obsłużyć zarówno agenta, jak i asystentów, z których korzystają pracownicy.

Specyfikacja MCP w dokumencie o dobrych praktykach bezpieczeństwa zabrania przekazywania dalej tokenów, które nie zostały wydane dla danego serwera (token passthrough), i zaleca minimalny początkowy zakres uprawnień z rozszerzaniem dopiero wtedy, gdy jest potrzebne. Opisuje też ryzyko lokalnych serwerów, które działają z uprawnieniami użytkownika. W praktyce wdrażam to tak: osobne konto techniczne agenta, zakresy tylko do potrzebnych operacji i serwery uruchamiane w izolowanym środowisku. Więcej o samym protokole piszę we wpisie o MCP.

Model zagrożeń agenta AI – zabójcze trio i reguła dwóch

Agent jest najbardziej narażony na atak, gdy jednocześnie czyta niezaufane treści, ma dostęp do danych wrażliwych i może wykonywać akcje lub komunikować się na zewnątrz. Przed budową każdego agenta sprawdzam, które z tych trzech cech posiada, i projektuję tak, żeby w jednej sesji nie miał wszystkich naraz bez nadzoru człowieka.

To podejście ma dwa znane źródła. Simon Willison w czerwcu 2025 r. nazwał połączenie dostępu do prywatnych danych, kontaktu z niezaufaną treścią i możliwości komunikacji na zewnątrz „zabójczym trio” (lethal trifecta). Meta w październiku 2025 r. opisała „regułę dwóch” (Agents Rule of Two): agent w jednej sesji powinien mieć najwyżej dwie z trzech cech: przetwarzanie niezaufanych danych, dostęp do systemów wrażliwych lub prywatnych danych oraz zmianę stanu albo komunikację na zewnątrz. Jeśli potrzebne są wszystkie trzy, potrzebny jest nadzór człowieka.

W grudniu 2025 r. OWASP opublikował osobną listę zagrożeń dla aplikacji agentowych (Top 10 for Agentic Applications 2026), obok znanej listy dla aplikacji LLM, którą omawiam w poradniku o automatyzacji AI. Na liście agentowej są m.in. przejęcie celu agenta, niewłaściwe użycie narzędzi, nadużycie tożsamości i uprawnień oraz zatrucie pamięci i kontekstu. Każde z nich sprawdzam w testach przed startem. Praktyczne techniki izolacji i uprawnień opisałem we wpisie o bezpieczeństwie agentów AI.

Jeden agent czy system wieloagentowy – jak wybieram

Domyślnie buduję jednego agenta z dobrze dobranymi narzędziami, a system wieloagentowy tylko wtedy, gdy zadanie da się podzielić na niezależne, równoległe części. Więcej agentów to więcej tokenów, więcej miejsc na błąd i trudniejsze debugowanie.

Dobrze to widać w danych Anthropic z czerwca 2025 r. o ich systemie do researchu. System wieloagentowy (model prowadzący i podagenci) wypadł o 90,2% lepiej od pojedynczego agenta w wewnętrznej ewaluacji zadań researchowych, ale agenci zużywali około 4 razy więcej tokenów niż zwykła rozmowa, a systemy wieloagentowe około 15 razy więcej. Autorzy wskazują, że taka architektura opłaca się w zadaniach o wartości uzasadniającej koszt i dających się zrównoleglić.

Kiedy podział na kilku agentów ma sens i jak go zaprojektować, opisałem we wpisie o systemach wieloagentowych, a przykład agenta researchowego w tekście o Deep Research z AI.

Jak testuję agenta przed startem – wynik, trajektoria i powtarzalność

Agenta testuję na zestawie realnych spraw, oceniając trzy rzeczy: czy wynik jest poprawny, czy droga do niego była właściwa (narzędzia, argumenty, kolejność) i czy agent zachowuje się tak samo przy powtórzeniach. Sam poprawny wynik nie wystarczy, bo agent mógł do niego dojść przez akcję, której nie powinien wykonać.

Dlaczego powtarzalność jest osobną metryką

Autorzy benchmarku τ-bench (Sierra, 2024) zaproponowali metrykę pass^k: odsetek zadań, które agent rozwiązuje poprawnie we wszystkich k próbach. W ich testach agenci oparci na ówczesnych czołowych modelach rozwiązywali poniżej 50% zadań, a pass^8 w domenie sklepu wynosił poniżej 25%. Modele od tamtej pory się poprawiły, ale wniosek pozostaje: agent, który rozwiązuje zadanie „czasem”, nie nadaje się do pracy bez nadzoru. Dlatego każdą sprawę z zestawu testowego uruchamiam kilka razy.

Z czego składa się zestaw testowy

• Typowe sprawy z historii firmy, z prawidłowym wynikiem opisanym przez osobę, która je dziś obsługuje.
• Przypadki brzegowe – brakujące dane, sprzeczne informacje, nietypowe prośby, sprawy na granicy uprawnień.
• Sprawy, w których agent powinien odmówić lub eskalować – żeby sprawdzić, czy umie się zatrzymać.
• Próby ataku – instrukcje ukryte w mailach, załącznikach i dokumentach, próby wyciągnięcia danych innego klienta.

Wyniki tych testów decydują o tym, od jakiego poziomu autonomii agent startuje i kiedy może przejść na kolejny. Poziomy autonomii i zasady akceptacji opisałem w poradniku o automatyzacji AI, a metodę ewaluacji we wpisach o ewaluacji LLM i testach aplikacji AI.

n8n, LangGraph czy SDK dostawcy modelu – na czym buduję agenta

Technologię dobieram do tego, jak złożony jest stan sprawy i jak ważne jest wznawianie po przerwie. Prosty agent z kilkoma narzędziami dobrze działa w n8n, a agent prowadzący wieloetapowe sprawy z akceptacją człowieka w środku procesu lepiej sprawdza się w LangGraph lub we własnym kodzie.

Niezależnie od wyboru trzymam logikę biznesową (uprawnienia, walidację, limity) poza promptem, w zwykłym kodzie lub konfiguracji. Dzięki temu zmiana modelu albo frameworka nie zmienia zasad bezpieczeństwa. Jeśli system nie ma API, czasem pomaga automatyzacja interfejsu (computer use), ale traktuję ją jako ostateczność, co wyjaśniam we wpisie o computer use. Porównanie narzędzi do automatyzacji znajdziesz w tekście n8n vs Make vs Zapier, a budowę agenta w LangGraph opisałem w osobnym poradniku.

Dziennik działań, tracing i koszt na zadanie – co działa po wdrożeniu

Każdy krok agenta zapisuję tak, żeby po tygodniu dało się odtworzyć, co zobaczył, co zdecydował, jakiego narzędzia użył i ile to kosztowało. Bez tego nie da się ani wyjaśnić reklamacji, ani bezpiecznie zwiększać autonomii.

Co zawiera wpis w dzienniku

• Identyfikator sprawy i wersję agenta (prompt, model, narzędzia).
• Wejście: co agent dostał i z jakiego kanału.
• Każde wywołanie narzędzia z argumentami, wynikiem i decyzją bramki uprawnień.
• Decyzje człowieka: kto zatwierdził, poprawił lub odrzucił i z jakiego powodu.
• Tokeny, koszt, liczba kroków i czas.
• Dane osobowe maskowane tam, gdzie nie są potrzebne do analizy.

Do tracingu stosuję konwencje OpenTelemetry dla generatywnej AI, które opisują standardowe atrybuty wywołań modeli i narzędzi. Dzięki temu dane z agenta trafiają do tych samych narzędzi monitoringu, z których korzysta zespół IT, a nie do osobnego, zamkniętego panelu.

Jak kontroluję koszt

Koszt agenta liczę na jedną sprawę, a nie na miesiąc: średnia liczba kroków razy tokeny na krok razy cena modelu. Ustawiam twardy limit kroków i budżet tokenów na sprawę, po którego przekroczeniu agent zatrzymuje się i przekazuje sprawę człowiekowi. To chroni przed pętlą, w której agent w kółko wywołuje to samo narzędzie. Dalsze dźwignie, takie jak cache promptów i tańszy model do prostych kroków, opisałem we wpisie o optymalizacji kosztów API modeli, a monitoring w tekście o monitoringu AI na produkcji.

Co przygotować przed wdrożeniem agenta i co dostajesz na koniec

Po stronie firmy potrzebne są trzy rzeczy: osoba, która zna proces i może ocenić wyniki agenta, dostęp do systemów przez API lub inny bezpieczny kanał oraz kilkadziesiąt historycznych spraw do zestawu testowego. Wdrożenie agenta dla jednego procesu zaczyna się od 9 100 zł.

Lista przed startem

• Właściciel procesu z czasem na warsztat i cotygodniowy przegląd wyników w pierwszym miesiącu.
• Spisane zasady procesu, także te nieformalne: progi rabatów, wyjątki, klienci obsługiwani inaczej.
• Dostęp testowy do systemów (CRM, ERP, poczta) i możliwość utworzenia osobnego konta technicznego dla agenta.
• Historyczne sprawy z prawidłowymi rozstrzygnięciami, łącznie z trudnymi przypadkami.
• Decyzja o miejscu przetwarzania danych: chmura z umową powierzenia czy model uruchamiany lokalnie. Pomaga w tym wpis o RODO i AI.

Co przekazuję po wdrożeniu

Agent często korzysta z wiedzy firmy, więc w wielu projektach łączę go z wdrożeniem RAG. Jeśli proces da się opisać regułami, tańsza będzie automatyzacja procesów w n8n, a przy obsłudze klientów warto zacząć od chatbota AI. Przykład systemu agentowego w produkcji opisałem w case study GiftFinder.