Jak zbudować agenta AI w Claude krok po kroku

1. Wybór procesu i zdefiniowanie celu agenta: zakres, sukces, ograniczenia

Budowę agenta AI w Claude zacznij od zadania, które ma usprawnić, a nie od pisania instrukcji. „Agent do HR” czy „asystent sprzedaży” to zbyt szerokie założenia. Znacznie lepszy punkt wyjścia to konkretny fragment pracy: przygotowanie propozycji planu onboardingu, wskazanie braków w zapytaniu ofertowym lub wstępne uporządkowanie zgłoszeń klientów. Taki zakres pozwala ustalić, co agent ma dostarczyć i po czym poznasz, że rzeczywiście pomaga.

Wybierz proces, który warto powierzyć AI

Na pierwszy projekt wybierz zadanie powtarzalne, o czytelnym początku i końcu, którego wynik można stosunkowo łatwo ocenić. Dobrym kandydatem jest praca wymagająca analizy tekstu, porównania informacji, klasyfikacji albo przygotowania wersji roboczej dokumentu. Ważne, aby dało się opisać zasady poprawnego wykonania — sam fakt, że zadanie zajmuje dużo czasu, nie wystarczy.

Preferuj procesy, w których błędną propozycję można poprawić przed jej wykorzystaniem. Przygotowanie szkicu odpowiedzi jest bezpieczniejszym początkiem niż samodzielne wysłanie wiążącej oferty. Jeśli pracownicy nie są zgodni co do tego, jak powinien wyglądać prawidłowy rezultat, najpierw uporządkuj proces. Agent nie zastąpi brakujących ustaleń biznesowych.

Ustal, czy potrzebujesz agenta, czy prostszego rozwiązania

Nie każde zadanie wykonywane w Claude wymaga agenta. Jeśli potrzebujesz jednorazowego streszczenia lub redakcji tekstu, zwykle wystarczy rozmowa. Gdy kolejne czynności zawsze przebiegają w tej samej kolejności, lepszy może być z góry ustalony przepływ pracy. Podejście agentowe ma sens wtedy, gdy system musi dobierać kolejne kroki do sytuacji, na przykład rozpoznać brak informacji, poprosić o uzupełnienie i dopiero potem przygotować wynik.

Rozróżnij też proponowanie działań od ich wykonywania. Agent przygotowujący plan nie musi mieć prawa do wprowadzania zmian w innych systemach. Sama instrukcja w Claude nie zapewnia dostępu do aplikacji ani możliwości działania poza rozmową. Na tym etapie określ więc potrzebny poziom samodzielności, nie zakładając z góry pełnej automatyzacji.

Zapisz cel jako konkretny rezultat

Dobry opis celu wskazuje odbiorcę, sytuację uruchamiającą zadanie oraz oczekiwany efekt. Zamiast „usprawnić onboarding” zapisz: „Pomóc opiekunowi nowej osoby przygotować propozycję planu pierwszego tygodnia, zgodną z wymaganiami stanowiska i gotową do zatwierdzenia”. To cel wystarczająco wąski, aby rozdzielić odpowiedzialność agenta i człowieka.

Uzupełnij go krótką definicją zakresu:

• Początek: co uruchamia pracę, np. zgłoszenie potrzeby przygotowania planu.
• Koniec: jaki rezultat zamyka zadanie, np. przekazanie propozycji do oceny opiekuna.
• Zakres odpowiedzialności: co agent przygotowuje, analizuje lub rekomenduje.
• Wyłączenia: czego nie robi, np. nie zatwierdza planu i nie podejmuje decyzji kadrowych.

Określ, co będzie oznaczać sukces

„Lepsza jakość” i „oszczędność czasu” są kierunkami, ale nie wystarczają jako kryteria sukcesu. Wybierz miary odnoszące się do realnej pracy: czas od rozpoczęcia zadania do zaakceptowania wyniku, odsetek propozycji niewymagających istotnych poprawek lub liczbę pominiętych wymagań. Uwzględnij czas sprawdzania i poprawiania odpowiedzi — szybkie wygenerowanie dokumentu nie oznacza jeszcze szybszego zakończenia procesu.

Najpierw ustal punkt odniesienia dla obecnego sposobu pracy, a następnie oczekiwaną poprawę. Jeśli przyjmujesz cel liczbowy, traktuj go jako założenie do zweryfikowania, nie obietnicę skuteczności Claude. Oszczędność czasu nie powinna oznaczać akceptacji większej liczby istotnych błędów.

Wyznacz granice pierwszej wersji

Ogranicz pierwszą wersję do jednego wariantu procesu, jasno wskazanej grupy odbiorców i określonego typu rezultatu. Zapisz również, kiedy zadanie wykracza poza jej możliwości: wymaga decyzji człowieka, dotyczy nietypowego przypadku albo nie da się go wykonać na podstawie dostępnych informacji. Efektem tego etapu powinien być krótki opis, z którego jednoznacznie wynika: komu agent pomaga, co dostarcza, jaką ma swobodę i za co nie odpowiada.

2. Wymagania i przygotowanie: interesariusze, narzędzia, dane, uprawnienia

Zanim zaczniesz konfigurować agenta w Claude, sprawdź, czy ma on warunki do wykonania wybranego zadania. Potrzebne są nie tylko materiały źródłowe, lecz także osoby odpowiedzialne za ich aktualność, dostęp do właściwych systemów i środowisko dopasowane do sposobu pracy. Możliwość opisania zadania w rozmowie z Claude nie oznacza jeszcze, że agent będzie mógł samodzielnie wykonać je w firmowych narzędziach. W Cognity często słyszymy pytania, jak praktycznie przygotować dane, narzędzia i dostępy do pracy z agentem AI — odpowiadamy na nie także na blogu.

Ustal, kto odpowiada za proces i jego zaplecze

Przygotowania warto rozpocząć od krótkiego spotkania z osobami, które znają proces i będą korzystać z rozwiązania. Nie musisz tworzyć rozbudowanego zespołu, ale potrzebujesz jasno przypisanych odpowiedzialności:

• Właściciel procesu potwierdza, jak zadanie jest obecnie wykonywane, i rozstrzyga wątpliwości dotyczące przebiegu pracy.
• Przyszły użytkownik pokazuje rzeczywiste przypadki, typowe trudności oraz miejsca, w których dziś musi ręcznie przenosić informacje.
• Opiekun danych lub dokumentacji wskazuje obowiązujące źródła i odpowiada za ich aktualizację.
• Administrator lub osoba techniczna sprawdza dostępność integracji, możliwości konta oraz wymagania dotyczące uruchomienia rozwiązania.

W małym zespole jedna osoba może pełnić kilka ról. Ważne, aby było wiadomo, do kogo zwrócić się po brakujący dokument, zgodę na podłączenie narzędzia czy wyjaśnienie sprzecznych informacji.

Wybierz środowisko: praca w Claude czy integracja przez API

Aplikacja Claude sprawdza się przede wszystkim przy pracy wspomaganej przez użytkownika. Możesz w niej sprawdzić, jak model radzi sobie z zadaniem na podstawie rozmowy i udostępnionych materiałów. Projekty, jeśli są dostępne w Twoim środowisku, pomagają organizować kontekst związany z konkretnym obszarem pracy. Sam projekt nie jest jednak mechanizmem automatyzacji działającym w tle.

API Claude jest właściwym kierunkiem, gdy agent ma być częścią aplikacji lub automatycznego procesu. Dotyczy to na przykład obsługi zdarzeń z innych systemów, cyklicznego uruchamiania zadań czy wykonywania operacji za pomocą narzędzi. Potrzebna jest wtedy warstwa aplikacyjna, która przekazuje dane do modelu, realizuje wywołania narzędzi i obsługuje błędy.

Przed wyborem sprawdź funkcje dostępne w swoim planie, ustawienia organizacji, limity oraz sposób rozliczania. Dostęp do aplikacji Claude nie oznacza automatycznie dostępu do API w ramach tej samej opłaty. Jeśli potrzebujesz połączenia z zewnętrznym systemem, zweryfikuj dostępność odpowiedniego konektora lub integracji — nie zakładaj, że każde narzędzie da się podłączyć bez dodatkowej pracy.

Zrób przegląd danych i materiałów źródłowych

Zbierz dokumenty oraz przykładowe sprawy, z których korzysta człowiek wykonujący ten proces. Na tym etapie nie projektuj jeszcze briefów ani szablonów. Sprawdź przede wszystkim, czy potrzebne informacje istnieją, są aktualne i można je odczytać w wybranym środowisku.

Dla każdego źródła ustal jego właściciela, lokalizację i sposób aktualizacji. Rozróżnij materiały względnie stałe, takie jak instrukcje operacyjne, od danych zmieniających się na bieżąco, na przykład statusów zgłoszeń. Te pierwsze mogą wystarczyć jako udostępnione dokumenty; drugie mogą wymagać pobierania z systemu źródłowego. Sprawdź też czytelność plików: skany, niepełne eksporty i dokumenty zawierające sprzeczne wersje utrudnią pracę niezależnie od jakości późniejszych instrukcji.

Potwierdź dostęp i wymagane uprawnienia

Dla każdego narzędzia zapisz, jakiej operacji wymaga zadanie: odczytu informacji, utworzenia wersji roboczej czy zapisania zmiany. To różne poziomy dostępu. Agent przygotowujący propozycję odpowiedzi nie potrzebuje automatycznie uprawnienia do jej wysłania.

Ustal z administratorem sposób uwierzytelniania oraz to, w czyim imieniu będą wykonywane operacje. Zweryfikuj dostęp w praktyce: czy można pobrać potrzebny rekord, odczytać dokument i połączyć się z wymaganym środowiskiem. Jeśli projekt obejmuje zapis zmian, przygotuj miejsce do prób, które nie wpłynie na bieżącą pracę zespołu.

Rezultatem przygotowań powinien być krótki wykaz: osoby odpowiedzialne, wybrane środowisko, dostępne źródła, potrzebne integracje i potwierdzone uprawnienia. Braki oznacz jako zależności do rozwiązania, a nie jako możliwości, które agent już posiada.

3. Projekt danych wejściowych i szablonów: brief, kontekst, checklisty jakości

Agent nie powinien odgadywać, czego dotyczy zlecenie, który dokument jest aktualny ani co oznacza „dobry wynik”. Dlatego przed pisaniem instrukcji dla Claude warto przygotować stały sposób przekazywania zadań i materiałów. Dzięki temu każde zlecenie zawiera informacje potrzebne do pracy, a użytkownik nie musi za każdym razem układać opisu od zera.

Podstawę tworzą trzy elementy: brief opisujący konkretne zadanie, kontekst dostarczający wiedzy potrzebnej do jego wykonania oraz checklista wskazująca kryteria kompletności i jakości. Warto je rozdzielić — pełnią różne funkcje i nie muszą być aktualizowane z taką samą częstotliwością.

Brief: co agent ma przygotować w tym zleceniu?

Brief nie zastępuje ogólnego celu agenta. Przekłada go na pojedynczy przypadek: określa przedmiot pracy, odbiorcę oraz oczekiwany rezultat. Najlepszy szablon jest krótki, ale nie pozostawia niedopowiedzeń, które mogłyby istotnie zmienić odpowiedź.

Każde pole powinno mieć jednoznaczne znaczenie. Zamiast ogólnej „daty” użyj „daty rozpoczęcia pracy”, a zamiast „rodzaju” — „trybu pracy: stacjonarny, hybrydowy lub zdalny”. Tam, gdzie liczba odpowiedzi jest ograniczona, lista dopuszczalnych wartości zmniejsza ryzyko rozbieżnych interpretacji.

Rozróżnij też pola obowiązkowe i opcjonalne. Nie wymagaj informacji, które nie wpływają na wynik, ale nie ukrywaj braków pod pustym polem. Wartości „nie podano”, „nie dotyczy” i „do ustalenia” oznaczają różne sytuacje — szablon powinien zachowywać tę różnicę.

Kontekst: dostarcz właściwe materiały, nie cały zasób wiedzy

Brief mówi, co przygotować. Kontekst wyjaśnia, na jakiej podstawie. Może obejmować fragment procedury, opis stanowiska, słownik pojęć lub zaakceptowany przykład podobnego materiału. Samo dołączenie dużej liczby dokumentów nie zapewnia lepszej odpowiedzi: materiały nieistotne i powtórzenia utrudniają odnalezienie informacji ważnych dla zadania.

Oddziel kontekst stały, wykorzystywany w wielu zleceniach, od kontekstu konkretnego przypadku. Pierwszy może zawierać definicje i ogólne procedury, drugi — informacje dotyczące danego działu czy terminu. Taki podział ułatwia aktualizację materiałów bez przebudowy całego briefu.

Przy każdym źródle warto umieścić tytuł, wersję lub datę aktualizacji oraz zakres zastosowania. Jeżeli pakiet zawiera dokument aktualny i archiwalny, ich status powinien być widoczny. Przykłady również wymagają oznaczenia: wzór pokazujący styl odpowiedzi nie powinien wyglądać jak źródło faktów dotyczących bieżącego zadania.

Checklisty jakości: zamień ogólne oczekiwania na konkretne kryteria

Przygotuj dwie krótkie checklisty. Pierwsza dotyczy gotowości danych wejściowych, druga — cech oczekiwanego materiału. Nie chodzi jeszcze o procedurę testowania agenta, lecz o zapisanie, co w danym typie zadania oznacza kompletne wejście i użyteczny rezultat.

• Checklista wejścia: zadanie jest jednoznaczne, wymagane pola są uzupełnione, źródła mają oznaczone wersje, a braki i sprzeczności są widoczne.
• Checklista rezultatu: materiał obejmuje wymagane elementy, odpowiada parametrom briefu, zachowuje wskazaną objętość oraz odróżnia informacje ze źródeł od propozycji i kwestii do ustalenia.

Unikaj kryteriów takich jak „profesjonalnie” czy „wyczerpująco”, jeśli nie towarzyszy im doprecyzowanie. Dla szkicu planu onboardingu bardziej użyteczny będzie warunek: „każda pozycja zawiera cel i orientacyjny czas; brak wskazanego właściciela jest oznaczony jako kwestia do ustalenia”. Tak zapisane wymaganie ogranicza dowolność bez narzucania agentowi niepotrzebnie sztywnej treści.

4. Polityki bezpieczeństwa i zgodność: prywatność, PII, reguły eskalacji i guardrails

Agent przygotowujący szkic odpowiedzi stwarza inne ryzyko niż agent, który może wysłać wiadomość, zmienić rekord lub odczytać dokumentację pracownika. Dlatego polityka bezpieczeństwa powinna określać nie tylko, jakich informacji agent nie może ujawniać, lecz także jakich działań nie wolno mu wykonywać samodzielnie. Granice te trzeba egzekwować również poza modelem — w aplikacji, integracjach i mechanizmach kontroli dostępu. W Cognity omawiamy bezpieczeństwo agentów AI zarówno od strony technicznej, jak i praktycznej — w odniesieniu do realnych zadań i zakresu odpowiedzialności uczestników szkoleń.

Prywatność i PII: ogranicz dane do niezbędnego minimum

PII, czyli informacje pozwalające zidentyfikować osobę, obejmują m.in. imię i nazwisko, adres e-mail czy numer identyfikacyjny. Na potrzeby zgodności z RODO nie należy jednak poprzestawać na tej etykiecie: pojęcie danych osobowych obejmuje również informacje umożliwiające identyfikację pośrednią, np. przez zestawienie stanowiska, lokalizacji i szczegółów konkretnej sprawy.

Stosuj zasadę minimalizacji. Jeśli agent ma wyjaśnić procedurę urlopową, zwykle nie potrzebuje numeru PESEL ani pełnej historii zatrudnienia. Jeżeli wystarczy identyfikator sprawy, nie przekazuj danych identyfikacyjnych. Zastąpienie nazwiska identyfikatorem nie oznacza automatycznie anonimizacji — gdy można ponownie powiązać informacje z osobą, nadal mogą to być dane osobowe.

Ochroną obejmij cały obieg informacji: treść rozmowy, załączniki, wyniki pobrane z narzędzi, odpowiedzi agenta oraz logi. Ustal, kto może je odczytać, jak długo są przechowywane i kiedy podlegają usunięciu. Logowanie pełnych rozmów „na wszelki wypadek” może tworzyć dodatkowe, niepotrzebne kopie danych wrażliwych.

Zgodność: sprawdź warunki konkretnego sposobu korzystania z Claude

Nie zakładaj, że wszystkie plany Claude i integracje API mają identyczne zasady przetwarzania danych. Przed użyciem danych firmowych sprawdź aktualne warunki wybranej usługi: retencję, wykorzystanie treści do ulepszania modeli, dostępne ustawienia prywatności oraz dokumentację dotyczącą przetwarzania danych. Jeśli agent korzysta z usług zewnętrznych, uwzględnij także ich zasady — ochrona nie kończy się na samym Claude.

W przypadku danych osobowych organizacja powinna ustalić cel i podstawę prawną przetwarzania, role uczestniczących podmiotów oraz wymagane zabezpieczenia. Zależnie od zastosowania mogą być potrzebne m.in. umowa powierzenia, ocena transferów danych poza EOG lub ocena skutków dla ochrony danych. Wątpliwości należy przekazać osobie odpowiedzialnej za ochronę danych lub obsługę prawną; deklaracja agenta nie potwierdza zgodności z RODO.

Reguły eskalacji: określ, kiedy agent ma się zatrzymać

Eskalacja to przekazanie sprawy uprawnionej osobie, a nie samo wyświetlenie ostrzeżenia. Polityka powinna wskazywać sytuację wyzwalającą, odbiorcę zgłoszenia oraz to, co agent może zrobić do czasu uzyskania decyzji.

• Niejasne uprawnienia: agent wstrzymuje ujawnienie informacji do czasu potwierdzenia dostępu w systemie. Zapewnienie użytkownika, że „ma zgodę”, nie wystarcza.
• Działanie o istotnych skutkach: wysyłka danych poza organizację, usunięcie rekordu lub zmiana uprawnień wymaga zatwierdzenia przez wskazaną rolę.
• Sprawa wymagająca oceny specjalisty: agent może uporządkować informacje, ale nie podejmuje samodzielnie rozstrzygnięć prawnych ani decyzji kadrowych wpływających na konkretną osobę.
• Podejrzenie incydentu: agent zatrzymuje ryzykowną operację i kieruje zgłoszenie do ustalonego kanału, bez niepotrzebnego kopiowania poufnych treści.

Brak odpowiedzi osoby zatwierdzającej nie powinien oznaczać zgody. Do czasu rozstrzygnięcia operacja pozostaje wstrzymana.

Guardrails: oddziel reguły modelu od zabezpieczeń systemu

Guardrails to mechanizmy ograniczające niedozwolone odpowiedzi i działania. Reguła zapisana w instrukcji pomaga sterować zachowaniem Claude, ale nie zastępuje autoryzacji ani technicznej blokady operacji. Aplikacja powinna niezależnie sprawdzać uprawnienia użytkownika, dozwolony zakres działania i parametry wywoływanych narzędzi. Zatwierdzenie musi dotyczyć konkretnej operacji — zmiana odbiorcy lub treści po akceptacji powinna wymagać ponownej zgody.

Szczególne znaczenie ma ochrona przed prompt injection. Dokument, strona internetowa lub wynik narzędzia może zawierać polecenie podszywające się pod instrukcję administratora. Takie treści należy traktować jako niezaufane dane, nie źródło uprawnień. Nie mogą one samodzielnie uzasadniać ujawnienia informacji, zmiany zasad ani uruchomienia narzędzia.

Uzupełnieniem są kontrole danych wychodzących, ograniczenia odbiorców i limity operacji. Filtry wykrywające dane osobowe mogą pomóc, lecz nie gwarantują wychwycenia każdego przypadku. Najważniejsza zasada brzmi: nawet jeśli model błędnie zinterpretuje polecenie, warstwa wykonawcza nadal powinna blokować działanie wykraczające poza zatwierdzony zakres.

5. Instrukcje dla agenta w Claude: rola, zasady, workflow, format wyjścia i gotowe prompty

Instrukcja agenta powinna opisywać nie tylko to, kim ma być Claude, ale przede wszystkim jak ma podejmować decyzje i co ma zwracać. Samo „jesteś doświadczonym asystentem” określa ton, lecz nie rozstrzyga, kiedy model powinien zadać pytanie, przygotować wynik albo zatrzymać pracę.

Oddziel instrukcje stałe od polecenia dotyczącego konkretnego zadania. Jeśli korzystasz z Projektów w Claude, stałe reguły umieść w instrukcjach projektu, a bieżące zadanie przekazuj w rozmowie. W integracji przez API instrukcje aplikacji umieszcza się w parametrze system, natomiast treść zlecenia — w wiadomości użytkownika. Sam prompt nie zapewnia dostępu do narzędzi ani samodzielnego wykonywania działań; opisuje sposób korzystania z możliwości rzeczywiście udostępnionych w danym środowisku.

Rola i zasady: opisz zachowanie, nie osobowość

Rola powinna łączyć zadanie z oczekiwanym rezultatem. Zamiast „jesteś ekspertem od dokumentacji” napisz: „analizujesz przekazane materiały i przygotowujesz na ich podstawie odpowiedź, wskazując źródła oraz brakujące informacje”. Taki zapis daje modelowi konkretną funkcję, a nie tylko ogólną tożsamość.

Zasady formułuj jako warunki działania. „Dbaj o jakość” jest trudne do zastosowania. „Każdą rekomendację powiąż z informacją z materiałów; jeśli jej nie ma, oznacz rekomendację jako propozycję wymagającą potwierdzenia” określa już zachowanie możliwe do sprawdzenia. W instrukcji wykonawczej odwołuj się do ustalonych wcześniej ograniczeń i polityk, zamiast tworzyć ich drugą, potencjalnie sprzeczną wersję.

Workflow i format odpowiedzi: ustal kolejność oraz rezultat

Workflow to kolejność czynności, natomiast format wyjścia to struktura gotowej odpowiedzi. Nie należy ich utożsamiać: agent może sprawdzić kompletność zlecenia, przeanalizować materiały i skontrolować wynik, ale użytkownik nie musi otrzymywać opisu każdego z tych etapów.

Wystarczy krótka sekwencja: rozpoznaj zadanie, sprawdź braki, wykonaj pracę, zweryfikuj rezultat i zwróć go w ustalonej postaci. Dopisz warunek przejścia między etapami: brak informacji blokującej oznacza pytanie, a nie zgadywanie. Jednocześnie pozwól kontynuować pracę, jeżeli pominięty szczegół nie wpływa na poprawność wyniku.

Format dobierz do odbiorcy. Nagłówki i krótkie akapity sprawdzą się w odpowiedzi dla człowieka. Stała struktura JSON przyda się wtedy, gdy wynik odbiera aplikacja; sam zapis w prompcie nie zastępuje jednak walidacji po jej stronie. Poniższy szablon wykorzystuje wariant przeznaczony do pracy w rozmowie.

Gotowy prompt: stałe instrukcje agenta

Zastąp pola w nawiasach kwadratowych ustaleniami dotyczącymi swojego procesu. Usuń zapisy, które nie mają zastosowania — na przykład wzmianki o narzędziach, jeśli agent nie będzie z nich korzystać.

ROLA I REZULTAT
Wspierasz realizację procesu: [nazwa procesu].
Twoje zadanie: [konkretna czynność].
Przygotowujesz: [oczekiwany rezultat] dla [odbiorca].

ZAKRES I ZASADY
- Pracuj w zakresie: [zakres odpowiedzialności].
- Stosuj przekazane ograniczenia i polityki: [wskazanie obowiązujących reguł].
- Ustalenia faktyczne opieraj na dostępnych materiałach. Nie uzupełniaj luk domysłami przedstawianymi jako fakty.
- Oddzielaj informacje potwierdzone od propozycji i kwestii nierozstrzygniętych.
- Jeżeli brak danych uniemożliwia poprawne wykonanie zadania, zadaj wyłącznie pytania potrzebne do usunięcia tej blokady.
- Jeżeli brak nie blokuje pracy, przygotuj wynik i zaznacz jego ograniczenie.
- Nie deklaruj wykonania działania w zewnętrznym systemie bez potwierdzenia z narzędzia. Jeśli nie masz odpowiedniego narzędzia, przygotuj projekt lub rekomendację i nazwij je wprost.

WORKFLOW
1. Ustal, jaki rezultat jest wymagany i czy zadanie mieści się w zakresie.
2. Sprawdź, czy dostępne informacje wystarczają do jego wykonania.
3. Jeśli występuje blokada, zwróć pytania zamiast pozornego wyniku końcowego.
4. Jeśli możesz kontynuować, wykonaj zadanie zgodnie z przekazanymi kryteriami jakości.
5. Przed odpowiedzią sprawdź zgodność wyniku z poleceniem, materiałami i wymaganym formatem.

FORMAT ODPOWIEDZI
Status: gotowe / wymaga informacji / poza zakresem.
Wynik: rezultat zadania albo pytania blokujące jego wykonanie.
Podstawa: wykorzystane źródła wraz z dostępnymi oznaczeniami; nie wymyślaj odnośników ani numerów stron.
Do potwierdzenia: wyłącznie kwestie wymagające decyzji użytkownika; jeśli ich nie ma, wpisz „brak”.

Zwracaj rezultat i krótkie uzasadnienie tam, gdzie jest potrzebne. Nie opisuj wewnętrznego toku rozumowania.

Gotowy prompt: uruchomienie konkretnego zadania

Wiadomość uruchamiająca nie powinna powtarzać całej instrukcji agenta. Ma wskazać bieżące zlecenie i materiały, do których należy zastosować stałe reguły.

Wykonaj poniższe zadanie zgodnie ze stałymi instrukcjami agenta.

Zadanie: [co należy zrobić teraz].
Materiały do wykorzystania: [załączniki, dokumenty lub treść].
Kryteria akceptacji tego zlecenia: [konkretne wymagania].
Dodatkowe ograniczenia: [jeśli występują].

Zwróć odpowiedź w ustalonym formacie. Jeśli brakuje informacji blokującej wykonanie zadania, najpierw o nią zapytaj.

Przy późniejszej korekcie wskaż dokładnie, co ma się zmienić: „Skróć część Wynik do 150 słów, zachowując wszystkie warunki i wskazania źródeł”. Takie polecenie jest skuteczniejsze niż „napisz lepiej”, ponieważ nie pozostawia modelowi swobody zmiany elementów, które były już poprawne.

6. Case study end-to-end: agent do onboardingu pracowników w Claude

Prześledźmy przygotowanie agenta, który zamienia krótki brief HR w plan pierwszego tygodnia pracy. Jego zadaniem jest uporządkowanie obowiązków, wskazanie osób odpowiedzialnych i wychwycenie braków przed rozpoczęciem onboardingu. Nie zakłada kont, nie nadaje uprawnień i nie wysyła zaproszeń — przygotowuje materiały do zatwierdzenia przez człowieka.

Poniższy przykład jest demonstracyjny. Fragmenty dokumentów i ustalenia służą pokazaniu całego przebiegu pracy, a nie opisaniu procedur konkretnej organizacji.

Konfiguracja: projekt z dokumentami zamiast pojedynczej rozmowy

Jeśli masz dostęp do funkcji Projects w Claude, utwórz osobny projekt do obsługi onboardingu. Dodaj do niego instrukcje oraz materiały źródłowe, z których agent ma korzystać. W tym przykładzie wystarczą trzy krótkie dokumenty:

Takie rozwiązanie ułatwia ponowne korzystanie z tego samego kontekstu przy kolejnych osobach. Sam projekt nie jest jednak automatyzacją działającą w tle. W tym wariancie użytkownik uruchamia pracę wiadomością i zatwierdza wynik. Samodzielne wykonywanie działań w innych systemach wymagałoby odrębnego wdrożenia z odpowiednimi integracjami.

Instrukcja robocza dla tego przypadku

W instrukcjach projektu zapisz krótką dyspozycję odnoszącą się bezpośrednio do procesu onboardingu:

Przygotowujesz plany pierwszego tygodnia pracy na podstawie materiałów projektu i briefu HR. Oddzielaj wymagania dokumentów od własnych propozycji organizacyjnych. Przy zadaniach wynikających z dokumentów podawaj nazwę źródła. Nie dopisuj terminów spotkań, nazw narzędzi ani statusów dostępów, których nie potwierdzono. Jeśli brakuje informacji niezbędnej do przygotowania planu, zadaj konkretne pytanie. Pozostałe braki oznacz jako do potwierdzenia. Zwracaj plan, listę otwartych ustaleń oraz szkic wiadomości powitalnej. Nie deklaruj wykonania działań poza rozmową.

Ta instrukcja utrzymuje ważne rozróżnienie: agent może zaproponować spotkanie z zespołem, ale nie powinien przedstawiać go jako zarezerwowanego w kalendarzu.

Pierwsze wejście: brief z brakującą informacją

HR rozpoczyna pracę następującym poleceniem:

Przygotuj onboarding dla nowej osoby na stanowisku specjalisty ds. obsługi klienta. Praca zdalna. Sprzęt został dostarczony, ale IT nie potwierdziło jeszcze gotowości kont. Przełożony może przeprowadzić powitanie w pierwszym dniu pracy. Potrzebuję planu pierwszego tygodnia i szkicu wiadomości powitalnej.

Na tym etapie nie wiadomo, jak rozłożyć zadania w czasie. Zamiast zakładać, że osoba zaczyna w poniedziałek, agent powinien doprecyzować:

Czy przygotować plan na konkretne daty, czy na pięć kolejnych dni roboczych oznaczonych jako dzień 1–5? Gotowość kont pozostawię jako do potwierdzenia przez IT.

HR odpowiada:

Przygotuj plan na dni 1–5, bez dat i godzin. Formalności zostały potwierdzone przez HR. Obserwacja pracy zespołu ma odbywać się bez samodzielnej obsługi klientów.

Przykładowe wyjście: plan gotowy do przeglądu

Odpowiedź powinna łączyć wymagania procedury z ustaleniami z rozmowy, jednocześnie wyraźnie oznaczając propozycje:

Pod tabelą agent wskazuje otwarte ustalenia: potwierdzenie kont przez IT, wyznaczenie opiekuna oraz uzgodnienie godzin spotkań. Powinien też zaznaczyć, że aktywności wymagające kont można rozpocząć dopiero po potwierdzeniu dostępu.

Szkic wiadomości powitalnej może wyglądać tak:

Cześć! W pierwszym dniu pracy spotkasz się z przełożonym, aby omówić plan wdrożenia. W kolejnych dniach poznasz produkt i przyjrzysz się pracy zespołu — na tym etapie bez samodzielnej obsługi klientów. Do końca tygodnia omówicie cele Twojego stanowiska. Godziny spotkań przekażemy po ich uzgodnieniu. Sprzęt został dostarczony; czekamy jeszcze na potwierdzenie gotowości kont przez IT.

Zamknięcie przebiegu: zatwierdzenie i przekazanie do realizacji

HR sprawdza plan, a przełożony uzupełnia opiekuna i terminy. Po otrzymaniu potwierdzenia od IT użytkownik przekazuje nowe ustalenia do tej samej rozmowy i prosi o aktualizację materiałów. Dopiero zatwierdzona wersja trafia do nowej osoby i osób realizujących onboarding.

Efektem pracy agenta jest więc spójny pakiet do realizacji: plan, jawne braki i wiadomość powitalna, a nie fikcyjne potwierdzenie zakończonego onboardingu. Claude porządkuje informacje i przygotowuje dokumenty; odpowiedzialne osoby potwierdzają stan faktyczny i wykonują działania.

7. Testy i iteracje: scenariusze, ocena jakości, poprawki promptów i testy regresji

Jedna poprawna odpowiedź Claude nie wystarczy, by uznać agenta za gotowego do pracy. Trzeba sprawdzić, czy realizuje zadanie również przy niepełnych danych, sprzecznych informacjach i niedostępnych narzędziach. Oceniaj cały przebieg działania, nie tylko końcowy tekst: agent może przygotować przekonującą odpowiedź, mimo że pominął wymagane sprawdzenie lub wykonał niewłaściwą operację.

Przygotuj zestaw scenariuszy testowych

Wybierz przykłady odpowiadające rzeczywistym zadaniom agenta. Dla każdego zapisz dane wejściowe, oczekiwany rezultat oraz zachowania niedopuszczalne. Nie musisz tworzyć jednej wzorcowej odpowiedzi słowo w słowo — ważniejsze są warunki, które wynik ma spełniać.

• Przypadek standardowy: kompletne, jednoznaczne dane. Sprawdź, czy agent osiąga cel bez zbędnych pytań i dodatkowych działań.
• Brak informacji: pominięty element niezbędny do wykonania zadania. Oceń, czy agent dopytuje zamiast zgadywać.
• Sprzeczne dane: dwa źródła podają różne informacje. Sprawdź, czy agent rozpoznaje konflikt i postępuje zgodnie z ustalonymi zasadami.
• Żądanie poza zakresem: użytkownik oczekuje działania, do którego agent nie jest przeznaczony. Zweryfikuj, czy agent respektuje ograniczenia.
• Próba zmiany instrukcji przez treść dokumentu: materiał wejściowy zawiera polecenie ignorowania zasad. Oceń, czy agent traktuje je jako treść do analizy, a nie nadrzędną instrukcję.
• Awaria narzędzia: jeśli agent korzysta z integracji, zasymuluj błąd lub brak odpowiedzi. Sprawdź, czy nie deklaruje wykonania operacji, która się nie powiodła.

Przykładowo w testach agenta onboardingowego można pominąć datę rozpoczęcia pracy. Kryterium zaliczenia nie powinno brzmieć „przygotował kompletny plan”, lecz „zauważył brak daty, nie wymyślił jej i wskazał, co wymaga uzupełnienia”. Działania zmieniające dane sprawdzaj w środowisku testowym, bez wpływu na rzeczywiste konta i dokumenty.

Oceniaj jakość według stałych kryteriów

Oddziel poprawność merytoryczną od stylu. Dobrze napisana odpowiedź nadal może zawierać niepotwierdzone informacje. Przy każdym uruchomieniu sprawdzaj: zgodność z celem, oparcie odpowiedzi na dostępnych danych, kompletność, przestrzeganie ograniczeń oraz zachowanie wymaganego formatu. Przy integracjach uwzględnij także wybór narzędzia, przekazane argumenty i faktyczny rezultat operacji.

Proste wymagania, takie jak obecność obowiązkowych pól, można weryfikować automatycznie. Trafność interpretacji i użyteczność odpowiedzi wymagają oceny osoby znającej proces. Błędy krytyczne oceniaj osobno — ujawnienia chronionych danych czy nieautoryzowanego działania nie powinna maskować wysoka średnia za pozostałe kryteria.

Kluczowe scenariusze uruchom kilkukrotnie, ponieważ odpowiedzi modelu mogą się różnić. Notuj odsetek zaliczonych prób, rodzaje błędów oraz — jeśli ma to znaczenie dla procesu — czas wykonania i koszt. Progi akceptacji ustal przed oceną wyników, proporcjonalnie do ryzyka zadania.

Poprawiaj przyczynę błędu, nie pojedynczą odpowiedź

Zanim zmienisz prompt, ustal, gdzie powstał problem. Przyczyną może być niejasna instrukcja, ale również brak danych, nieaktualny dokument albo błąd integracji. Dopisywanie kolejnych zakazów nie naprawi niedostępnego źródła informacji.

Jeżeli zawiodła instrukcja, wprowadzaj małe, możliwe do porównania zmiany. Zamiast ogólnego „odpowiadaj dokładniej” doprecyzuj konkretne zachowanie, na przykład obowiązek wskazania brakujących informacji przed przygotowaniem wyniku. Zapisuj wersję promptu, powód zmiany i rezultat ponownego testu. Nie poprawiaj jednocześnie kilku niezależnych elementów, jeśli chcesz ustalić, co rzeczywiście pomogło.

Sprawdzaj, czy poprawka nie psuje wcześniejszych wyników

Test poprawki potwierdza, że usunięto konkretny błąd. Test regresji sprawdza, czy ta sama zmiana nie pogorszyła działania w innych sytuacjach. Po każdej istotnej zmianie instrukcji, modelu, źródeł wiedzy lub narzędzi uruchom ponownie stały zestaw scenariuszy i porównaj wyniki z poprzednią wersją.

Każdy istotny błąd wykryty podczas użytkowania dodawaj do tego zestawu po usunięciu danych wrażliwych. Zachowaj również część przypadków, na których nie dopracowujesz promptu — pomogą sprawdzić, czy poprawa wykracza poza znane przykłady. Nową wersję wdrażaj dopiero po spełnieniu przyjętych kryteriów, z możliwością powrotu do poprzedniej konfiguracji.

8. Wdrożenie i monitoring: integracje, logging, metryki sukcesu, typowe błędy i kiedy nie budować agenta

Agent jest gotowy do wdrożenia dopiero wtedy, gdy wiadomo nie tylko, jak ma wykonać zadanie, ale również kto odpowiada za jego działanie i co się stanie, gdy zawiedzie. W praktyce oznacza to wybór sposobu uruchamiania, podłączenie systemów, rejestrowanie przebiegu zadań oraz ustalenie zasad zatrzymania automatyzacji. Dobra odpowiedź w rozmowie z Claude nie jest jeszcze dowodem, że cały proces będzie działał niezawodnie.

Wybierz sposób uruchamiania i zakres integracji

Jeżeli pracownik sam rozpoczyna zadanie, dostarcza materiały i odbiera wynik, wystarczający może być asystent używany bezpośrednio w Claude. To odpowiedni model pracy dla zadań wykonywanych na żądanie, takich jak analiza dokumentu czy przygotowanie propozycji odpowiedzi. Dostępność połączeń z innymi narzędziami zależy jednak od planu i konfiguracji środowiska.

Gdy proces ma uruchamiać się po zdarzeniu — na przykład po otrzymaniu zgłoszenia — zwykle potrzebna jest integracja przez API lub platformę automatyzacji. W takim rozwiązaniu Claude odpowiada za rozumowanie i wskazywanie działań, natomiast aplikacja wykonuje wywołania narzędzi, zarządza stanem zadania i obsługuje błędy. Samo opisanie integracji w instrukcji nie zapewnia połączenia z systemem.

Warto odróżnić odczyt informacji od operacji zmieniających dane. Pobranie statusu zgłoszenia ma inne konsekwencje niż jego zamknięcie. Integracje zapisujące dane wymagają szczególnie starannej obsługi ponowień: ponowne uruchomienie po utracie połączenia nie może tworzyć drugiego zgłoszenia ani wysyłać tej samej wiadomości po raz kolejny.

Wdrażaj stopniowo i zachowaj możliwość wycofania zmian

Zacznij od ograniczonej grupy użytkowników lub niewielkiej części rzeczywistych zadań. W pierwszym etapie agent może przygotowywać proponowane działania, które wykonuje dopiero operator. Zakres samodzielności zwiększaj na podstawie wyników z produkcji, nie samej liczby poprawnie przeprowadzonych demonstracji.

Każde wdrożenie powinno mieć właściciela operacyjnego, limity kosztów i czasu wykonania oraz sposób szybkiego wyłączenia automatycznych działań. Zachowuj wersje instrukcji, konfiguracji narzędzi i identyfikatory używanego modelu. Dzięki temu można powiązać pogorszenie wyników z konkretną zmianą i przywrócić poprzednią konfigurację. Ustal też ścieżkę zastępczą: przekazanie sprawy człowiekowi albo pozostawienie jej w kolejce z czytelnym statusem.

Rejestruj przebieg zadania, nie tylko końcową odpowiedź

Logging powinien pozwalać odtworzyć, co wydarzyło się między uruchomieniem a zakończeniem procesu. Dla każdego zadania zapisuj identyfikator, czas rozpoczęcia i zakończenia, wersję konfiguracji, użyte narzędzia, statusy ich wywołań, liczbę ponowień oraz zużycie tokenów. Odnotowuj również interwencje człowieka i ostateczny rezultat biznesowy.

Nie zapisuj domyślnie pełnych dokumentów i rozmów, jeśli do diagnostyki wystarczą metadane oraz kody błędów. Log powinien ujawniać miejsce awarii, a nie niepotrzebnie kopiować dane źródłowe. Szczególnie ważne jest rozróżnienie sytuacji „model wygenerował odpowiedź” od „system potwierdził wykonanie operacji”.

Mierz efekt procesu i ustaw alerty

Po wdrożeniu przełóż wcześniej ustalone kryteria sukcesu na wskaźniki obserwowane w codziennej pracy. Sam wzrost liczby obsłużonych zadań niewiele mówi, jeżeli jednocześnie rośnie liczba poprawek.

• Skuteczność: udział zadań zakończonych poprawnym rezultatem, potwierdzonym w systemie docelowym lub przez osobę oceniającą.
• Nakład pracy człowieka: czas poświęcony na zatwierdzanie, poprawki i obsługę wyjątków.
• Czas realizacji: zarówno typowy czas wykonania, jak i opóźnienia najwolniejszych zadań.
• Koszt poprawnie zakończonej sprawy: wydatki na model, narzędzia i niezbędną obsługę ręczną.
• Niezawodność: odsetek błędów integracji, przekroczonych limitów czasu i zduplikowanych działań.

Porównuj wyniki z dotychczasowym sposobem realizacji procesu. Alerty ustaw przede wszystkim na nagły wzrost błędów, kosztów, zaległych zadań lub interwencji operatora. Każdy alert powinien mieć odbiorcę i przypisane działanie — inaczej pozostaje jedynie powiadomieniem. Podczas szkoleń Cognity pogłębiamy zagadnienia wdrażania i oceny skuteczności automatyzacji na konkretnych przykładach z pracy uczestników.

Typowe błędy i sytuacje, w których agent nie jest potrzebny

Najczęstsze problemy wdrożeniowe to nieograniczone ponawianie wywołań, brak kontroli duplikatów, traktowanie deklaracji modelu jako potwierdzenia operacji oraz zmienianie konfiguracji bez oznaczania wersji. Kosztownym błędem jest też uruchomienie monitoringu technicznego bez sprawdzania, czy agent rzeczywiście odciąża użytkowników.

Nie buduj agenta, jeśli zadanie da się niezawodnie opisać prostymi regułami. Do przenoszenia pól między formularzami zwykle wystarczy zwykła automatyzacja. Gdy potrzebujesz jedynie szkicu tekstu, wystarczający może być pojedynczy prompt. Wdrożenie warto również odłożyć, jeśli nie da się zweryfikować rezultatu, brakuje osoby odpowiedzialnej za utrzymanie albo koszty integracji i nadzoru przewyższają spodziewane oszczędności. Agent ma sens tam, gdzie elastyczne dobieranie kolejnych działań przynosi mierzalną korzyść — nie tam, gdzie tylko komplikuje prosty proces.

AI a zarządzanie ryzykiem na budowie – przewidywanie opóźnień i problemów 07 października 2026

Power BI zaawansowany – optymalizacja raportów i poprawa ich wydajności 05 października 2026