Kto przygotuje agentowi kontrakt działania w systemie?
Agent potrafi rozpoznać prośbę o zmianę terminu, lecz to jeszcze nie znaczy, że wie, który termin wolno zmienić. W jednej aplikacji jest to plan pracy zespołu, w drugiej zobowiązanie wobec klienta, a w trzeciej data wynikająca z dostępności części. Ten sam komunikat może więc uruchamiać różne skutki. Przed podłączeniem narzędzia potrzebna jest wspólna decyzja o znaczeniu operacji, nie tylko poprawny opis jej parametrów.
Poniżej proponujemy sposób przeprowadzenia takiego przeglądu na przykładzie rezerwacji wizyty serwisowej. To autorski przykład projektowy, nie relacja z wdrożenia ani deklaracja osiągniętych wyników. Rezultatem pracy ma być krótka karta, którą właściciel procesu, analityk, programista i tester rozumieją jednakowo.
Od prośby do jednej operacji
Zacznijcie od zdania: „Agent proponuje nowy termin wizyty, ale rezerwuje go dopiero po potwierdzeniu przez uprawnionego użytkownika”. Następnie zaznaczcie słowa wymagające wyjaśnienia. Czy propozycja blokuje miejsce? Jak długo potwierdzenie jest ważne? Czy użytkownik może zmienić wizytę innej osoby? Czy rezerwacja i odwołanie poprzedniego terminu stanowią jedną operację?
To zadania analityczne, a nie kwestie stylu odpowiedzi modelu. Warto ustalić, co robi analityk systemowy, zanim agent otrzyma prawo zmiany danych w systemie. W tym przeglądzie analityk zbiera rozbieżne interpretacje, wskazuje zależności i zapisuje rozstrzygnięcia. Nie przejmuje jednak prawa właściciela procesu do ustalenia zasad obsługi klienta.
Jeżeli zespół dopiero definiuje zadanie, pomocny będzie szerszy poradnik projektowania agenta AI. Tutaj skupiamy się na pojedynczej decyzji integracyjnej: kiedy propozycja staje się wiążącą zmianą rekordu.
Karta decyzji dla rezerwacji wizyty
Karta powinna opisywać jeden skutek, a nie cały system. W naszym przykładzie jej robocza nazwa brzmi „Potwierdzenie zmiany terminu istniejącej wizyty”. Nie wystarczy wpisać, że wymagany jest identyfikator i data. Trzeba połączyć pola z regułami, które pozwolą rozpoznać poprawny wynik.
- Wejście: identyfikator wizyty, wybrany przedział czasu i wersja rekordu odczytana przed pokazaniem propozycji.
- Warunki: użytkownik może zarządzać tą wizytą, nowy termin pozostaje dostępny, a zgoda dotyczy dokładnie tej propozycji.
- Skutek: nowa rezerwacja zastępuje starą; klient nie pozostaje przypadkowo z dwiema wizytami.
- Potwierdzenie: system zwraca identyfikator zakończonej operacji i aktualny stan wizyty, zamiast samego komunikatu o przyjęciu żądania.
- Wyjątek: zmiana dostępności lub stanu rekordu powoduje ponowne przedstawienie propozycji, nie samodzielny wybór innego terminu.
- Właściciel: zasady potwierdza osoba odpowiedzialna za obsługę wizyt, a wykonalność sprawdza zespół utrzymujący kalendarz.
Do karty dodajcie wersję oraz datę uzgodnienia. Zapiszcie też jedną świadomie odrzuconą alternatywę, na przykład automatyczne przesunięcie na najbliższy wolny termin. Powód odrzucenia pomaga przy późniejszej zmianie wymagań: zespół widzi, że brak takiego działania jest decyzją, a nie przeoczeniem.
Sprawdźcie znaczenie i aktualność danych
Oddzielcie dane pochodzące z wypowiedzi klienta od danych systemowych. „Najbliższy piątek po południu” jest preferencją do wyjaśnienia. Konkretny przedział dostępności pochodzi z kalendarza. Agent nie powinien zamieniać przybliżonej prośby w zatwierdzoną rezerwację bez pokazania, jak ją zinterpretował.
W karcie należy wskazać sposób rozpoznawania nieaktualnego odczytu. Jeżeli między propozycją a potwierdzeniem termin zajmie inna osoba, wcześniejsza odpowiedź agenta nie może zastąpić ponownej kontroli. Wspólnie z programistą ustalcie, jak system wykrywa taką kolizję i jaką informację otrzyma użytkownik.
Sprawdźcie również nieoczywiste różnice: strefę czasową, granice przedziału i znaczenie statusu „oczekuje”. W omawianym przykładzie warto zapisać datę wraz ze strefą i osobno tekst wyświetlany klientowi. Dzięki temu tester wie, czy ocenia rzeczywisty termin, czy jedynie jego językową prezentację.
Uprawnienia i wyjątki poza swobodną interpretacją
Prawo do odczytu listy wizyt nie oznacza prawa do ich zmiany. Przegląd kontraktu powinien rozstrzygnąć, kto udziela dostępu do konkretnej operacji i gdzie to uprawnienie jest sprawdzane. Samo zdanie w instrukcji agenta nie zastępuje kontroli w narzędziu wykonującym zapis.
Niejasny wynik operacji wymaga osobnej ścieżki. Gdy po wysłaniu potwierdzenia zabraknie odpowiedzi, agent nie wie jeszcze, czy termin został zmieniony. W takim przypadku potrzebne jest sprawdzenie statusu tej samej operacji. Ponowne wysłanie nowego żądania bez rozpoznania stanu może stworzyć konflikt. Jeśli system nie pozwala ustalić wyniku, sprawę powinien przejąć wskazany operator.
Warto przejść przez te sytuacje z osobą zajmującą się bezpiecznym wdrożeniem agenta. Karta analityczna mówi, jakie zachowanie jest wymagane; projekt wykonania musi wskazać mechanizm, który rzeczywiście je wymusza.
Zamieńcie uzgodnienia na testy i odbiór
Na przeglądzie odtwórzcie trzy historie: poprawną zmianę, utratę dostępności przed potwierdzeniem oraz brak odpowiedzi po zapisie. Dla każdej pokażcie wejście, stan początkowy, oczekiwany komunikat i stan końcowy. Dodajcie czwartą próbę z użytkownikiem bez prawa do danej wizyty. W tym przypadku poprawnym wynikiem jest brak zmiany, nawet jeśli model zrozumiał prośbę.
Tester powinien umieć wyprowadzić oczekiwania z karty bez dopowiadania reguł. Jeżeli nie potrafi ustalić, czy stary termin zostaje zwolniony, przegląd nie jest zakończony. Właściciel procesu potwierdza wtedy decyzję, analityk aktualizuje zapis, a programista sprawdza jej wykonalność.
Gotowy kontrakt nie jest obietnicą bezbłędności agenta. Jest wspólnym punktem odniesienia: pozwala odróżnić niepoprawną interpretację polecenia od błędu integracji oraz od nieuzgodnionej wcześniej reguły. Dzięki temu kolejna rozmowa o poprawce dotyczy konkretnej decyzji i jej testu, zamiast ogólnego zarzutu, że system zachował się niewłaściwie.