Narzędzia agenta, czyli skąd bierze się różnica

Cztery narzędzia, które robią większość roboty

Katalogi potrafią wymieniać dziesiątki pozycji. W katalogu skilli ClawLabs jest ich czterdzieści, rozłożonych na dziesięć kategorii od Web & Search po Finanse, i to nie jest wyjątkowo bogata lista jak na rok 2026. Codzienne wdrożenia opierają się mimo to na czterech zdolnościach, a reszta okazuje się ich odmianą.

Widać to, gdy przejrzy się taki katalog pozycja po pozycji. PDF Reader i CSV Analyzer to szczególne przypadki pracy na plikach. Cron Scheduler nie daje agentowi żadnej nowej umiejętności, tylko decyduje, kiedy ma się obudzić; w OpenClaw tę samą rolę pełni plik HEARTBEAT.md. Slack Connector i Email Drafter to wywołania cudzego API w ładnym opakowaniu.

Stąd prosty test przy dokładaniu kolejnej pozycji: czy to nowa zdolność, czy wygodniejsza wersja czegoś, co agent już potrafi? Jeśli to drugie, zysk jest niewielki, a rachunek za każde uruchomienie rośnie od razu.

• Przeglądarka. Agent otwiera stronę, czyta ją i wyciąga dane. To narzędzie odpowiada za większość zadań researchowych.
• Pliki. Odczyt i zapis dokumentów, arkuszy, PDF-ów. Bez tego agent nie odda wyniku w formie, którą da się wysłać dalej.
• Kod. Uruchamianie obliczeń i przetwarzanie danych. Przydaje się tam, gdzie trzeba coś policzyć dokładnie, a nie oszacować.
• Wywołania API. Połączenie z Waszym CRM-em, kalendarzem, systemem magazynowym. To najczęściej odróżnia demo od wdrożenia.

Każde wywołanie ma cenę, wyższą niż wygląda

Narzędzie kosztuje dwa razy. Raz opisem w promptcie, bo model musi wiedzieć, że coś takiego istnieje i kiedy po to sięgnąć. Drugi raz wynikiem, który wraca do kontekstu i jedzie z nim przy każdym kolejnym kroku.

Skalę dobrze pokazuje zestawienie Iternal AI z lipca 2026: prosty agent z jednym, dwoma wywołaniami narzędzi mieści się w 5–15 tysiącach tokenów na zadanie, wieloetapowe rozumowanie zjada 50–200 tysięcy, a orkiestracja kilku agentów startuje od 200 tysięcy i potrafi przekroczyć milion.

Ta sama różnica w złotówkach jest policzona w lekcji czwartej: to samo zadanie wykonane krok po kroku z narzędziami kosztuje ponad trzy razy więcej niż zadane raz w czacie. Płacicie za możliwość sprawdzenia, a nie za lepszą odpowiedź, dlatego ma to sens tylko tam, gdzie odpowiedź trzeba na czymś oprzeć.

Praktyczny wniosek jest niewygodny dla entuzjastów: narzędzia są tym, co odróżnia agenta od czatu, i jednocześnie tym, co przesuwa rachunek. Zadanie, które da się zrobić jednym zapytaniem, rób jednym zapytaniem i nie rób z niego agenta.

Dlaczego mniej narzędzi bywa lepsze

Intuicja podpowiada, żeby włączyć wszystko, bo a nuż się przyda. W praktyce działa to odwrotnie. Im więcej narzędzi ma agent, tym więcej czasu zajmuje mu wybór właściwego i tym częściej sięga po nieoczywiste.

Widzieliśmy agenta, który zamiast odczytać wartość z arkusza, napisał skrypt liczący ją od zera. Wynik był poprawny, tylko zajęło to trzy razy dłużej i kosztowało kilkanaście razy więcej tokenów. Zabranie mu narzędzia do uruchamiania kodu rozwiązało sprawę w minutę, czego żadne zdanie w promptcie nie załatwiło przez tydzień.

Zasada, która z tego wynika: włączaj narzędzia wtedy, gdy zadanie ich wymaga, a nie na zapas. Dokładanie zajmuje trzydzieści sekund, więc nic nie tracisz, odkładając decyzję do momentu, w którym agent zgłosi, że czegoś mu brakuje.

Drugi zysk widać dopiero przy awarii. Przy trzech narzędziach wiadomo, gdzie szukać, bo są trzy możliwe miejsca. Przy dwudziestu log z jednego uruchomienia ma kilkaset linii i poranek schodzi na czytanie, co agent właściwie próbował zrobić.

Czytające i zmieniające: linia, którą rysuje się raz

Narzędzia to miejsce, w którym agent przestaje być niegroźny. Czytanie stron jest bezpieczne. Zapis do Waszego systemu produkcyjnego już nie, i między tymi dwiema sytuacjami nie ma stanu pośredniego.

Rozdziel więc narzędzia na dwie grupy: czytające i zmieniające. Czytające możesz włączyć szeroko. Zmieniające włączaj pojedynczo, świadomie i z ograniczonym zakresem uprawnień. Agent z dostępem do kalendarza wyłącznie do odczytu nie odwoła Ci spotkania przez pomyłkę, choćby bardzo chciał, bo uprawnienie jest ścianą, a reguła w promptcie tylko prośbą.

Ten podział rozwiązuje też rozmowę, która i tak Was czeka. Według badania McKinsey „State of AI trust in 2026”, obejmującego około 500 organizacji na przełomie 2025 i 2026 roku, prawie dwie trzecie respondentów wskazuje bezpieczeństwo i ryzyko jako główną barierę skalowania agentów, a dojrzałe procesy nadzoru ma mniej więcej jedna trzecia. Deloitte podaje jeszcze niższą liczbę: dojrzały model zarządzania autonomicznymi agentami ma 20% organizacji.

Konkret na godzinę pracy: spisz listę narzędzi z jedną kolumną „czyta czy zmienia” i drugą z jednym zdaniem o najgorszym możliwym skutku pomyłki. Taka kartka odpowiada na trzy czwarte pytań z działu bezpieczeństwa, zanim ktokolwiek je zada.

Strona internetowa, która wydaje polecenia

Jest jeszcze ryzyko, o którym mówi się rzadko, a robi się coraz ważniejsze. Agent czytający stronę czyta jej treść tak samo jak Wasze polecenia. Jeśli ktoś umieści tam zdanie skierowane do modelu, agent może potraktować je jak instrukcję od Was.

Wniosek jest jeden i nie da się go obejść regułą w promptcie: nie łącz w jednym agencie czytania otwartego internetu z prawem zapisu do systemów firmowych. Rozdziel to na dwie role. Pierwsza zbiera dane i oddaje plik. Druga, z dostępem do CRM-a, pracuje wyłącznie na tym, co dostała od Was, i nigdy nie otwiera adresów z zewnątrz.

Tempo, w jakim ta konfiguracja wchodzi do firm, wyprzedza tempo kontroli. Blisko co piąty polski pracownik korzysta już z autonomicznych agentów, a systemy klasy DLP albo CASB wdrożyło zaledwie 25% organizacji, czyli w większości firm nikt nie widzi, co wychodzi na zewnątrz. Pełny obraz tych proporcji jest w lekcji siódmej.

Trzecia zasada z tej samej rodziny dotyczy wyjścia. Wszystko, co agent wysyła poza firmę (mail, wiadomość do klienta, wpis w cudzym systemie) przechodzi przez akceptację człowieka tak długo, aż zbierzecie kilka tygodni logów pokazujących, że nie ma czego poprawiać.

Co się dzieje, gdy narzędzie zwróci błąd

Dobrze skonfigurowany agent spróbuje ponownie, a potem powie wprost, że się nie udało. Gorszy scenariusz wygląda tak, że agent uzna pusty wynik za wynik i pojedzie dalej: raport przyjdzie o czasie, będzie ładnie sformatowany i będzie opisywał dane, których nikt nie pobrał.

Zabezpieczenie jest tanie i składa się z dwóch części. W promptcie: przy nieudanym pobraniu danych zgłoś problem i przerwij zadanie, zamiast improwizować. W praktyce: sprawdź, co agent zrobi, gdy pobranie danych się nie uda, test opisaliśmy w lekcji o zadaniach cyklicznych. Jeśli przyszedł raport zamiast komunikatu o błędzie, masz problem, o którym inaczej dowiedziałbyś się po miesiącu.

Że to nie jest rzadka luka, widać w danych praktyków. Raport LangChain „State of Agent Engineering”, oparty na 1 340 odpowiedziach zebranych na przełomie listopada i grudnia 2025 roku, pokazuje, że obserwowalność wdrożyło 89% zespołów, ale ewaluacje offline prowadzi 52,4%. Największą barierą wdrożeniową pozostaje jakość działania z 32% wskazań, przed latencją z 20%.

Dla małej firmy nie oznacza to zakupu platformy do monitoringu. Oznacza jedno miejsce, w którym widać: jakie narzędzie zostało wywołane, z jakim argumentem i co zwróciło. Bez tych trzech informacji każda diagnoza jest zgadywaniem, a poprawki wprowadza się na chybił trafił.