Przez ostatnie tygodnie pracuję z agentem AI jak z nowym współpracownikiem: daję mu dostęp do systemów, ustalam zasady, zlecam zadania i sprawdzam rezultat. Nie jest to demonstracja możliwości modelu ani lista pomysłów na „AI w biznesie”. To zapis pracy na prawdziwych systemach: CRM, serwerach, raportach, automatyzacjach, poczcie i danych operacyjnych.
Tanova jest eksperymentem i dziennikiem współpracy człowieka z agentami AI w realnym środowisku biznesowym. Publikowane tutaj case study powstają na podstawie faktycznie wykonanych zadań, błędów, logów, raportów i korekt. Część tekstów współtworzy agent, którego pracę opisują. Dane pozwalające identyfikować klientów i pracowników są pomijane albo agregowane.
Ten wpis nie opisuje jednego konkretnego tygodnia z kalendarza. To tydzień typowy, złożony z reprezentatywnych zdarzeń z ostatnich tygodni. Pokazuję zarówno rzeczy, które zadziałały, jak i sytuacje, w których agent się pomylił, zapętlił albo wymagał zatrzymania przez człowieka.
Wskaźnik Wynik
| Wskaźnik | Wynik |
|---|---|
| Monitorowane bramki SMS | 65 |
| Rekordy analizowane w pojedynczej analizie CRM | kilkanaście tysięcy |
| Raporty CRM i połączeń w tygodniu | kilkanaście |
| Błędnie przygotowane SMS-y wykryte przed wysyłką | 297 |
| Czas od pomysłu do pierwszej działającej wersji narzędzia | 1 dzień |
| Wpisy case study opublikowane jednego dnia | 3 |
| Szacowana oszczędność mojego czasu | kilka godzin dziennie |
Te liczby nie są benchmarkiem laboratoryjnym. Są skutkiem codziennej pracy. Dalej pokazuję, skąd się wzięły, co rzeczywiście robi agent i gdzie nadal potrzebny jest człowiek.
Internet jest pełen opisów tego, co agent AI może zrobić. Mnie interesuje coś innego: co rzeczywiście robi, kiedy dostanie dostęp do prawdziwego środowiska i zacznie odpowiadać za powtarzalną pracę operacyjną.
Dlatego na Tanovie dokumentuję wdrożenie od środka: raporty, monitoring, budowę narzędzi, pamięć, bezpieczeństwo, awarie, błędne decyzje i zasady, które powstają po błędach. Chcę zostawić materiał źródłowy dla osób, które za kilka miesięcy lub kilka lat będą chciały sprawdzić, jak wyglądała praktyczna współpraca człowieka z agentem AI — nie w prezentacji sprzedażowej, tylko w firmie.
Agent AI to system, w którym model językowy nie tylko generuje odpowiedź, ale może korzystać z narzędzi, odczytywać stan środowiska, wykonywać działania i weryfikować ich rezultat. W praktyce różnica między czatbotem a agentem nie polega więc na sposobie prowadzenia rozmowy, lecz na tym, czy AI może przejść od odpowiedzi do działania.
Mój agent działa na platformie OpenClaw i ma dostęp do:
Do tego dochodzi pamięć operacyjna: zapisane decyzje, korekty, wiedza o środowisku i rejestr metod, które wcześniej zawiodły. Dzięki temu kolejna sesja nie musi zaczynać się od poznawania firmy od zera.
O szerszym przeglądzie tego środowiska pisałem osobno: OpenClaw — asystent AI do automatyzacji pracy.
Najważniejsza decyzja na starcie: podział ról. Agent nie dostaje „pełnej swobody” — dostaje zakres. Zasada jest prosta: im wyższa stawka błędu, tym wyżej decyzja schodzi do człowieka.
Obszar Kto decyduje Co robi agent
| Obszar | Kto decyduje | Co robi agent |
|---|---|---|
| Raporty i analizy danych | człowiek ustala temat i zakres | generuje, weryfikuje, wysyła |
| Monitoring systemów | człowiek ustala progi i zasady | odczytuje, porównuje, alarmuje |
| Budowa narzędzi | człowiek określa wymagania | pisze kod, testuje, dokumentuje |
| Decyzje operacyjne, np. usuwanie rekordów | człowiek | proponuje i czeka na akceptację |
| Masowe wysyłki e-mail/SMS | zawsze człowiek | przygotowuje, weryfikuje, czeka na potwierdzenie |
| Bezpieczeństwo i dostęp | zawsze człowiek | audytuje i raportuje; nie rozszerza sam uprawnień |
Ten podział nie jest biurokracją — to dokładnie to, co robi się z każdym nowym pracownikiem. I to jest szkielet, na którym stoi praca z agentem AI: jasny zakres, jasne granice, jasne eskalacje. Różnica: agent nie zapomni zasady, którą raz ustaliłem.
Pierwszy sukces, o którym chcę opowiedzieć, bo jest symbolem tego, jak wygląda praca z agentem AI w praktyce: automatyzacja raportu dziennego z połączeń.
To nie powstało w jeden dzień. Drogę można podzielić na etapy:
Co się dzieje za kulisami? Agent pobiera dane z CRM, deduplikuje rekordy (kilkaset surowych zamienia w dwieście kilka unikalnych), buduje raport HTML i wysyła mailem. Jeśli coś się psuje — dostaję raport z błędem, a nie cicho zepsuty raport.
Przekaz: praca z agentem AI nie jest „włącz i zapomnij”. Automatyzacja to kilka iteracji z człowiekiem, a potem działa sama. Od drugiego tygodnia ten raport wyszedł bez mojego udziału — i tak jest do dziś.
Drugi przykład jest ciekawszy, bo pokazuje coś niespodziewanego: agent napisał od zera narzędzie zarządcze, którego nikt wcześniej nie pisał.
Było tak: potrzebowałem raportu aktywności pracowników w CRM — kto, ile czasu pracował, w jakie rekordy wchodził. W umiejętnościach agenta nie było gotowego kodu, były tylko informacje o strukturze CRM. Poprosiłem: „zbuduj to”.
Wynik po pierwszym dniu: działający raport z dowolnym zakresem dat. A potem przyszły iteracje — i tu zaczyna się ciekawa część, bo każda zmiana wynikała z realnej obserwacji biznesowej:
Efekt: narzędzie, które dziś służy do monitorowania pracy zespołu w CRM. Od pomysłu do działającego raportu: jeden dzień. Tak wygląda praca z agentem AI, gdy agent dostaje dostęp do danych i struktury systemu. Od pierwszego raportu do wersji, z której dziś korzystam: kilka iteracji na przestrzeni tygodni.
To jest dokładnie ten moment, w którym praca z agentem AI przestaje być „asystentem” i zaczyna być „współpracownikiem”: agent nie tylko wykonuje — on rozumie, po co mu się to buduje, i proponuje, co dodać.
Środa to dzień, na którym najlepiej widać drugą supermoc agenta: pytania ad hoc zamieniane w gotowe tabele.
W tym tygodniu padło kilka pytań — i każde dostało odpowiedź w postaci tabeli, często wysłanej mailem:
Ten ostatni przykład jest dla mnie najważniejszy: agent łączy dane z systemów, które normalnie nie rozmawiają ze sobą. W takim ujęciu agent staje się interfejsem do danych: pytasz naturalnym językiem, dostajesz tabelę. CRM przestaje być systemem, w którym „trzeba wejść i poszukać” — staje się dashboardem, do którego zadajesz pytania.
O tym, jak wygląda u mnie automatyzacja raportów sprzedażowych w CRM, pisałem szerzej w osobnym wpisie: Agent AI w CRM — automatyzacja raportów sprzedaży.
Czwartek to dzień bramek SMS. Mamy ich 65 — każda to osobny serwer z kolejką wiadomości, własną bazą i własnym tekstem kampanii. Żaden człowiek nie trzyma ręki na pulsie wszystkich 65 jednocześnie. Agent — tak.
Co agent zrobił w tym tygodniu:
Była też wpadka: podczas zmiany nazwy bramki w trakcie działającego batcha, agent wysłał 297 SMS ze starym tekstem kampanii. Wyłapał to sam, zanim wiadomości wyszły do klientów, i naprawił — szczegóły w sekcji o błędach.
Pełny opis tego, jak wygląda u mnie automatyzacja bramek SMS, jest w osobnym wpisie: Automatyzacja bramek SMS przez agenta AI.
Przekaz: praca z agentem AI oznacza, że nikt nie musi trzymać ręki na pulsie 65 systemów jednocześnie — agent to robi, a przy awarii nie staje: robi, co może, i podaje pałeczkę człowiekowi tam, gdzie trzeba.
Piątek to dzień, w którym powstawała nowa możliwość: obsługa systemu do masowych maili (newslettery, kampanie, listy kontaktów).
To była budowa etapowa — i tu widać, jak wygląda praca z agentem AI przy czymś, czego agent „jeszcze nie potrafi”:
Każdy etap kończył się moją akceptacją — tak powinna wyglądać praca z agentem AI przy budowie nowych możliwości. Agent budował i dokumentował, ja zatwierdzałem.
Dwie rzeczy z tego tygodnia są dla mnie ważne:
O tym, jak wygląda u mnie automatyzacja newslettera, pisałem osobno: Agent AI do automatyzacji newslettera.
W weekend nic się „nie dzieje” — i to jest dokładnie taki stan, jaki chcę. Ale agent nie śpi:
A teraz meta-historia — jeden z najciekawszych momentów ostatnich tygodni: agent napisał pierwszy wpis na tym blogu — o własnej pracy.
Było tak: poprosiłem o artykuł o naszym doświadczeniu — „opowiedz, co robimy, pozytywne i negatywne aspekty, pisz w formie, jak ja bym pisał”. Agent napisał treść, ja podał ramy (tytuł, meta opis, slug), agent podmienił tekst na stronie. Od tamtej pory blog jest w dużej mierze prowadzony przez agenta:
Przekaz: agent nie tylko wykonuje zadania — on dokumentuje własną pracę. W tym modelu agent uczestniczy również w prowadzeniu bloga. „Nie śpi” nie znaczy „działa sam”: rano dostaję podsumowanie i listę decyzji.
Gdyby agent nie pamiętał, co robiliśmy wczoraj, praca z agentem AI byłaby jak praca z kimś, kto codziennie budzi się z amnezją. Dlatego pamięć to nie dodatek — to fundament wdrożenia.
U mnie działa to tak:
Efekt: agent się uczy, a praca z agentem AI z tygodnia na tydzień wymaga od mnie coraz mniej korekt. Nie w sensie „model się doskonali” — w sensie „znajomość mojego środowiska i moich zasad rośnie z każdym tygodniem”.
Jedna z mniej oczywistych, a najbardziej użytecznych ról: agent jako konsultant własnych automatyzacji.
Trzy przykłady z tego tygodnia:
To jest rola, której bym nie przypisał człowiekowi w pierwszym miesiącu — a agentowi przypisuję od początku. Bo agent nie broni się, gdy okazuje się, że się mylił: poprawia dokumentację i idzie dalej.
Teraz część, o której większość case study nie pisze — bo praca z agentem AI wygląda w demie inaczej niż w produkcji. Agent się myli. Trzy przykłady z ostatnich tygodni — każdy z naprawą i stałą regułą:
Błąd Przyczyna Naprawa Stała reguła
| Błąd | Przyczyna | Naprawa | Stała reguła |
|---|---|---|---|
| Pętla paginacji; cztery nieudane próby pobrania danych | API zwracało rekordy spoza zakresu dat; brak warunku stopu | diagnoza i naprawa tego samego dnia | warunek stopu + test przesunięcia strony przed masowym pobraniem |
| Podwójna weryfikacja po wysyłce maila | po zmianie modelu agent zaczął spontanicznie dodawać kolejne kontrole | weryfikacja tylko wynikiem wysyłki | zamknięta lista dopuszczalnych „dowodów” w promptach |
| 297 SMS-ów ze starym tekstem kampanii | batch trzymał w pamięci starą listę po zmianie nazwy bramki | dokładna identyfikacja plików, backup, usunięcie i kontrola kolejki | odświeżenie listy przed każdym batchem; brak zmiany nazwy w trakcie batcha |
Do trzeciego przykładu wrócę, bo to najlepsza historia o realnej pracy agenta na produkcji.
Był czwartek. Batch uzupełniał kolejki na kilkunastu bramkach. W trakcie batcha przemianowałem jedną bramkę i ustawiłem na niej nowy tekst kampanii. Batch trzymał w pamięci starą listę — i obsłużył tę bramkę ze starym tekstem. 297 SMS z kampanią, która była aktualna jeszcze miesiąc wcześniej.
Agent wyłapał to sam, przy weryfikacji. Zrobił trzy rzeczy: zlokalizował dokładnie te 297 plików w kolejce (grep po unikalnym fragmencie starego tekstu), zrobił lokalny backup i usunął z kolejki tylko te pliki. Weryfikacja po usunięciu: kolejka czysta, zero plików ze starym tekstem. Wiadomości nie wyszły do klientów.
A teraz druga część tej historii, ważniejsza od pierwszej. W podobnej sytuacji — gdy agent utknął w pętli debugowania i godzinę testował to, co już wiedziałem — powiedziałem wprost: „głupi jesteś, bo robisz od godziny nie wiem co. Skoro coś za pierwszym razem zadziałało, to co się dzieje teraz? Nic nie rób, tylko mi opisz.”
Agent się nie obraził. Został i opisał: lista, którą mi pokazał, jest prawidłowa; problem leży po stronie serwera, który oknami po kilka minut odrzuca token autoryzacji. Potem naprawił swój kod, dokończył zadanie (przeniesienie kilkunastu rekordów do właściwej grupy, utworzenie kopii kampanii) i zapisał wszystko w dokumentacji — łącznie z tym, że się pomylił.
Przekaz: błąd nie jest wstydliwy. Wstydliwe byłoby, gdyby się powtórzył. Każdy błąd w moim środowisku kończy się stałą regułą — i to jest mechanizm, dzięki któremu agent z miesiąca do miesiąca robi mniej błędów, a nie więcej.
Lista jest krótka, ale trzymam się jej bez wyjątków:
Te zasady to nie ograniczenia — to fundament, który pozwala mi dać agentowi tak szeroki dostęp do produkcji. Bez nich praca z agentem AI na produkcji byłaby grą w ruletkę. Gdybym nie miał pewności, że agent nie wyśle maila bez mojej zgody, nie dałbym mu dostępu do poczty.
Dwa mechanizmy, które nauczyłem się doceniać po konkretnych incydentach:
Pętle. Jeden z najgorszych momentów: agent szukał pliku na serwerze i robił to samo ponad 40 razy z rzędu — równoważne komendy, zero postępu. Po tym incydencie weszły reguły anty-pętlowe: zmiana hipotezy zamiast powtarzania, stop po dwóch pustych wynikach z rzędu, zmiana źródła lub narzędzia. Od tamtej pory pętla się nie powtórzyła.
Halucynacje. Reguła jest prosta: każda zmiana wymaga weryfikacji wyniku. Agent nie mówi „zrobiłem” — pokazuje wynik polecenia. Rozróżniamy trzy poziomy: fakt potwierdzony (wynik narzędzia), wniosek (wyprowadzony z danych) i hipoteza (wymagająca sprawdzenia). W raportach biznesowych pojawiają się tylko dwa pierwsze.
Do tego dochodzą zamknięte listy „dowodów” w promptach: gdy agent weryfikuje wysyłkę, weryfikuje tylko to, co jest na liście. Nie „domyśla się”, że może jeszcze coś sprawdzić. To brzydkie w pisaniu, a działa bezbłędnie.
Gdybym miał wskazać jedno miejsce, w którym praca z agentem AI daje największy zwrot, to nie jest to „szybkie raporty”. To jakość danych.
Przykłady z ostatnich tygodni:
Przekaz: agent jest dobrym inspektorem jakości, bo nie ignoruje dziwności. Człowiek po trzech miesiącach przy tych danych zaczyna je „widzieć oczami przyzwyczajenia”. Agent widzi je zawsze.
Agent ma dostęp do produkcji, dlatego jego środowisko jest audytowane tak samo jak każdy inny system — i agent sam pomaga w audycie.
Co wyszło z ostatnich przeglądów:
Przekaz: dostęp agenta do produkcji to nie wyjątek od zasad bezpieczeństwa. Agent AI jest kolejnym systemem, który trzeba objąć tymi samymi zasadami co resztę.
Pieniądze:
Co trzeba, żeby zacząć:
Nie potrzebujesz być programistą, żeby praca z agentem AI dała efekt. Potrzebujesz umieć opisać, czego chcesz, i sprawdzić, czy agent to zrobił. Reszta — kod, skrypty, integracje — to już sprawa agenta.
Pora Co się dzieje Kto
| Pora | Co się dzieje | Kto |
|---|---|---|
| 6:00–8:00 | raporty za poprzedni dzień roboczy: CRM i połączenia | agent, zadanie cykliczne |
| rano | podsumowanie nocy i lista decyzji czekających na mnie | agent → człowiek |
| dzień | analizy, budowa narzędzi, naprawy i monitoring ad hoc | człowiek + agent |
| wieczór | backup do NAS i monitoring | agent, zadania cykliczne |
| noc | konsolidacja pamięci i archiwizacja sesji | agent, zadania cykliczne |
Widzisz wzorzec? Człowiek wchodzi do gry rano (decyzje) i w ciągu dnia (zadania ad hoc), reszta dnia i cała noc to agent. To jest praca z agentem AI w skrócie.
Poniższe odpowiedzi odnoszą się do doświadczeń opisanych w tym podsumowaniu. Nie są listą hipotetycznych możliwości agentów AI — wynikają z zadań, błędów, raportów i automatyzacji, które rzeczywiście pojawiły się w mojej pracy.
Nie ma jednego stałego scenariusza. Część pracy jest przewidywalna: cykliczne raporty, monitoring, backup i konsolidacja pamięci. Druga część wynika z bieżących potrzeb firmy — pytania o dane z CRM, budowa nowego raportu, diagnoza awarii, zmiana kampanii albo połączenie informacji z dwóch systemów.
W tygodniu opisanym w tym materiale agent pracował m.in. z raportami CRM, monitorował 65 bramek SMS, budował narzędzie do analizy aktywności, poznawał system do masowych maili i wykonywał zadania cykliczne poza godzinami mojej pracy. Nie oznacza to jednak pełnej autonomii. Tam, gdzie koszt błędu jest wysoki — np. masowa wysyłka albo istotna zmiana produkcyjna — decyzja nadal należy do człowieka.
Jeżeli interesuje Cię samo środowisko, na którym opieram tę współpracę, opisałem je szerzej we wpisie OpenClaw — asystent AI do automatyzacji pracy.
Największą część stanowiła praca na danych i systemach, a nie rozmowa z modelem. Agent generował raporty, analizował tysiące rekordów CRM, monitorował kolejki wiadomości, łączył dane z różnych źródeł, budował kod i przygotowywał kolejne elementy automatyzacji.
Dobrym przykładem jest CRM. Zamiast ręcznie przeklikiwać rekordy, mogłem zadać pytanie naturalnym językiem: ile leadów przypisano poszczególnym osobom, gdzie są przeterminowane rozmowy albo jak wygląda lejek od początku roku. Agent pobierał dane, przetwarzał je i zwracał gotowe zestawienie. Ten obszar opisuję dokładniej w case study Agent AI w CRM — automatyzacja raportów sprzedaży.
Innym przykładem było 65 bramek SMS. Tutaj agent nie tylko odczytywał stan kolejek, ale wykrywał anomalie, wykonywał kontrolowane uzupełnienia i sprawdzał rezultat. Szczegółowy przebieg tego procesu znajduje się we wpisie Automatyzacja bramek SMS przez agenta AI.
Więcej, niż zakładałem na początku, ale nie traktuję autonomii jako celu samego w sobie. Ważniejsze jest to, czy rezultat można sprawdzić i czy koszt potencjalnego błędu jest akceptowalny.
W pełni automatycznie działają u mnie przede wszystkim zadania powtarzalne i dobrze zdefiniowane: raporty cykliczne, część monitoringu, backup oraz nocna konsolidacja pamięci. Agent zna warunki wykonania, oczekiwany rezultat i sposób jego weryfikacji. Jeżeli coś odbiega od ustalonego schematu, powinien zgłosić problem zamiast improwizować.
Inaczej wygląda praca ad hoc. Agent może sam napisać skrypt, przeanalizować dane albo przygotować operację, ale decyzje o większym wpływie pozostają po mojej stronie. W tym tygodniu dobrze było to widać podczas awarii jednej z bramek: ja naprawiłem serwer, a agent kontynuował bezpieczną część pracy na pozostałych systemach i później zweryfikował stan całości.
Błędy są jednym z powodów, dla których publikuję te podsumowania. Sam opis sukcesów niewiele mówi o rzeczywistej pracy z agentem.
W ostatnich tygodniach pojawiła się m.in. pętla paginacji, w której skrypt nie potrafił prawidłowo zakończyć pobierania danych. Innym razem agent po zmianie modelu zaczął dodawać niepotrzebne kroki weryfikacyjne. Najbardziej konkretny przypadek dotyczył 297 SMS-ów przygotowanych ze starym tekstem kampanii po zmianie konfiguracji bramki w trakcie działającego batcha.
Istotne jest to, co wydarzyło się później. Agent wykrył problem przed wysyłką, zlokalizował dokładnie błędne pliki, wykonał backup, usunął je z kolejki i sprawdził rezultat. Następnie przyczyna została zamieniona w stałą regułę: lista ma być odświeżana przed każdym batchem, a nazwa bramki nie jest zmieniana podczas jego wykonywania.
To jest model, który staram się utrzymywać: błąd → diagnoza → naprawa → weryfikacja → trwała reguła. Pełny kontekst pracy z bramkami opisuję w case study automatyzacji SMS.
Najczęściej wtedy, gdy pojawia się sytuacja nieprzewidziana albo operacja ma duży wpływ na produkcję. Nie chcę, żeby agent „wykazywał inicjatywę” w miejscu, w którym błędna interpretacja może oznaczać masową wysyłkę, usunięcie danych albo zmianę dostępu.
W opisanym okresie interweniowałem np. podczas awarii bazy jednej z bramek oraz wtedy, gdy agent zapętlił się w debugowaniu. W drugim przypadku najlepszym poleceniem nie było „spróbuj jeszcze raz”, tylko zatrzymanie działania i żądanie samego opisu sytuacji. Dopiero po ustaleniu faktycznego stanu wróciliśmy do wykonywania zadania.
To jest ważna część eksperymentu Tanovy: obserwuję nie tylko, co można oddać agentowi, ale również gdzie autonomia przestaje być opłacalna i człowiek powinien pozostać punktem decyzyjnym.
CRM jest jednym z najlepszych przykładów różnicy między czatbotem a agentem. Sam model może opowiedzieć, jak analizować sprzedaż. Agent z dostępem do API może rzeczywiście pobrać rekordy, zastosować reguły biznesowe, połączyć dane i przygotować wynik.
W tym tygodniu pytania dotyczyły m.in. liczby kontaktów i leadów przypisanych do pracowników, lejka sprzedażowego, przeterminowanych rozmów, jakości pojedynczych rekordów oraz wyszukiwania leadów według znaczenia opisu. W jednym z zadań agent połączył CRM z bazą telefonii i przygotował tabelę zawierającą informacje, których nie dało się uzyskać z jednego systemu.
To nie jest jednak pełny opis wdrożenia CRM — tutaj pokazuję tylko wydarzenia z tygodnia. Osobny materiał Agent AI w CRM — automatyzacja raportów sprzedaży opisuje ten obszar szerzej.
Nie zaczęliśmy od dania agentowi możliwości masowej wysyłki. Najpierw musiał poznać system, API i rzeczywistą strukturę danych. Potem dostał operacje odczytu, następnie zarządzanie listami i kontaktami, a dopiero później przygotowanie kampanii.
W praktyce ważniejsza od samego wysłania newslettera okazała się wiedza o danych: różne pola opt-out, osoby usunięte, rezygnacje z poszczególnych kanałów kontaktu i konieczność kontroli liczników po zmianach. Agent może przygotować kampanię, ale masowa wysyłka nadal wymaga mojego jawnego potwierdzenia.
Ten wpis pokazuje tylko etap, który przypadł na opisywany okres. Cały workflow rozwinąłem osobno w materiale Agent AI do automatyzacji newslettera.
Szacuję oszczędność na kilka godzin dziennie, ale celowo nie przedstawiam tej liczby jako precyzyjnego pomiaru. Nie prowadzę stopera porównującego każdą czynność wykonywaną ręcznie z pracą agenta.
Największa oszczędność nie wynika z tego, że pojedynczy raport powstaje szybciej. Wynika z kumulacji drobnych zadań: raport przychodzi rano bez mojego udziału, monitoring działa w tle, zestawienie z kilku tysięcy rekordów nie wymaga ręcznego eksportu, a pytanie o dane może zostać zamienione w tabelę bez budowania osobnego raportu w CRM.
Dochodzi jeszcze praca wykonywana poza moimi godzinami: backup, zadania cykliczne i konsolidacja pamięci. Dlatego w tabeli wyników podaję „kilka godzin dziennie” jako mój szacunek, a nie twardy KPI. W kolejnych tygodniowych podsumowaniach chcę zachować to rozróżnienie między tym, co zostało zmierzone, a tym, co jest oceną.
Nie. To celowo tydzień typowy, zbudowany z rzeczywistych wydarzeń i zadań z ostatnich tygodni. Nie chcę tworzyć fałszywej narracji tylko po to, żeby wszystko mieściło się od poniedziałku do niedzieli.
Układ tygodnia służy pokazaniu rytmu pracy: raporty, analizy, monitoring, rozwijanie nowych możliwości, błędy, interwencje człowieka i procesy działające w tle. Same przykłady pochodzą z realnej historii pracy i nie są wymyślonym scenariuszem demonstracyjnym.
To rozróżnienie jest dla mnie ważne również w kolejnych publikacjach. Tanova ma dokumentować doświadczenie, a nie dopasowywać fakty do atrakcyjniejszej historii.
Bo pojedynczy test agenta niewiele mówi o tym, jak zmienia się jego użyteczność w czasie. Ciekawsze jest obserwowanie procesu: czego agent nauczył się o środowisku, jakie nowe zadania dostał, gdzie popełnił błąd, kiedy musiałem interweniować i które poprawki zostały później zapisane jako trwałe zasady.
Tanova jest eksperymentem i dziennikiem współpracy człowieka z agentami AI. Tygodniowe podsumowania mają tworzyć chronologiczny zapis tej współpracy oparty na rzeczywistych zadaniach, a nie na deklaracjach o możliwościach AI. Dzięki temu za kilka miesięcy będzie można porównać nie tylko kolejne modele czy narzędzia, ale przede wszystkim zmianę sposobu pracy: zakres autonomii, liczbę interwencji, rodzaje błędów, nowe automatyzacje i rzeczywiste rezultaty.
Osobne case study — takie jak agent AI w CRM, automatyzacja bramek SMS czy automatyzacja newslettera — rozwijają konkretne obszary. Tygodniowe wpisy mają natomiast pokazywać cały obraz i jego zmianę w czasie.
Tanova nie powstaje po to, żeby opisywać możliwości AI z dokumentacji producentów. Jej wartością ma być ciągły zapis tego, co dzieje się po wdrożeniu agenta do prawdziwej pracy: co działa, co się psuje, ile pracy znika, jakie pojawiają się ryzyka i jakie zasady trzeba dopisać po kolejnych incydentach.
Praca z agentem AI nie jest magią. To podział pracy: agent wykonuje, człowiek decyduje. Agent nie śpi, nie zapomni zasady i nie „poczeka na lepszy moment”, żeby o niej wspomnieć. Ale też się myli — i dlatego każdy błąd kończy się stałą regułą, a każda masowa operacja czeka na potwierdzenie.
Po kilku tygodniach realnej pracy widzę trzy rzeczy:
Jeśli chcesz zobaczyć konkretne case study, na blogu są trzy wpisy: agent AI w CRM, automatyzacja bramek SMS i automatyzacja newslettera.
A jeśli masz podobny problem i szukasz kogoś, kto zbudował agenta AI do raportów, CRM lub monitoringu — napisz: Cześć, mamy podobny problem — szukamy kogoś, kto zbudował agenta AI do raportów/CRM/monitoringu. Czy moglibyśmy umówić się na 30 minut, żeby porozmawiać o naszym przypadku?
