O czym jest ten film
- Niemal każde demo agenta AI kończy się na poczcie i kalendarzu — autor pokazuje, jak przejść od tego etapu do pracy „wysokiego zaufania”: odwołań od decyzji ubezpieczyciela i przygotowania podatków.
- Kluczowa teza: problemy z papierologią (podatki, ubezpieczenia, zdrowie) to z perspektywy agenta jeden i ten sam problem — zamiana bałaganu w ustrukturyzowany kontekst.
- Autor buduje na żywo jeden „szkielet” agenta złożony z dziewięciu elementów: pakiet kontekstu, ingest, chunking, normalizacja, przechowywanie, wyszukiwanie, cytowanie, eksport i bramka (gate).
- Bramka to żelazna zasada: agent może czytać, porządkować, redagować i cytować, ale nigdy nie wysyła, nie płaci i nie podpisuje — ostatni klik należy do człowieka.
- Build 1 (e-mail i kalendarz) to poligon, gdzie błędy są tanie: agent przygotowuje odpowiedź i propozycję terminu, a na końcu zostawia „paragon” — listę źródeł, zmian i rzeczy do zatwierdzenia.
- „Most”, który wszyscy pomijają: te same prymitywy (ingest, normalizacja, paragon, bramka) przenoszą się bez zmian z e-maila na odwołanie ubezpieczeniowe — nie trzeba zaczynać od zera.
- Build 2 (odwołanie od odmowy ubezpieczyciela) działa na prawdziwych dokumentach polis i syntetycznych danych pacjenta; efektem nie jest „list na wyczucie”, lecz sprawdzalna teczka sprawy z mapą cytowań i osią czasu.
- Build 3 (podatki) powstaje najszybciej, bo wszystkie klocki już istnieją — agent przygotowuje pakiet do przeglądu dla podatnika lub księgowego, w tym listę pytań do eksperta, ale niczego nie składa.
- Sekret całości to czyste, znormalizowane dane: gdy daty są datami, a każde twierdzenie ma adres w źródle, większość pracy mogą wykonać tanie, lekkie modele.
- Rada końcowa: nie buduj jednorazowych rozwiązań, tylko „koło zamachowe” — każdy kolejny build jest tańszy, bo korzysta z umiejętności odłożonych na półkę przy poprzednich.
Redakcyjne tłumaczenie
Dlaczego wszystkie dema agentów zatrzymują się na e-mailu
Każde demo agenta AI, które widzieliście w tym roku, zaczyna się w tym samym miejscu: poczta i kalendarz. Agent redaguje odpowiedzi, umawia spotkania — i rozumiem dlaczego. Wielu z nas zmaga się z tym codziennie, tam spędzamy mnóstwo czasu. Ale jest pułapka, w którą wpada mnóstwo osób: konfigurujemy agenta, on jakoś działa — i utykamy. Nie wiemy, jak przejść od poziomu, na którym agent segreguje codzienną drobnicę, do prawdziwej pracy: ubezpieczeń, płatności, spraw zdrowotnych — zadań, które wymagają delikatności i realnego zaufania.
Dziś to rozwiążemy. Zbuduję na żywo jeden szkielet agenta. Nauczymy się go na poczcie i kalendarzu, gdzie błędy są tanie, a potem pokażę, jak z tej samej maszynerii korzystam przy naprawdę delikatnej, wysokostawkowej pracy: przy sprawach ubezpieczeniowych i podatkowych.
Jedna rama myślenia: to zawsze ten sam problem
Kiedy bierzecie się za problemy agentowe, użyjcie tej ramy. Ten folder podatkowy, którego nie otworzyliście, ta odmowa ubezpieczyciela, od której nigdy się nie odwołaliście — dla nas to różne problemy, bo porządkujemy je według dziedzin: zdrowie kontra podatki. Ale gdy w grę wchodzą pliki i papierologia, z perspektywy agenta to nie są różne problemy. To jedno i to samo: potrzebne jest rozumienie polityki (polisy, przepisów), rozumienie kategorii i rozumienie szczegółu — a wy nie macie organizacji, która pozwoliłaby to z tego bałaganu wydobyć. Innymi słowy: najpierw jest problem „z bałaganu do uporządkowanych plików”, a dopiero potem wychodzą z tego ustrukturyzowane wnioski. To wspólny wzorzec wszystkich delikatnych, wymagających zaufania spraw papierkowych, które zatruwają nam życie. Widzę to samo przy umawianiu wizyt lekarskich czy formularzach edukacyjnych. Ilekroć trzeba wziąć stos rzeczy i zamienić go w ustrukturyzowany kontekst dla delikatnej operacji — to ta sama fundamentalna zasada agentowa.
Agent ma dźwigać ciężar, a nie klikać przycisk
Gdy mówimy o agentach, prawie zawsze mówimy o działaniu: agent coś zrobi, wyśle e-mail, coś złoży. Rozumiem — to świetnie wygląda. Ale przy pracy wymagającej zaufania proszę was: skupcie się na tej części, w której agent naprawdę zdejmuje z was ciężar. Agent, który potrafi przekopać się przez biurokrację, przez nieustrukturyzowany kontekst, przez bałagan w moim folderze, jest dla mnie użyteczniejszy niż agent, który umie kliknąć przycisk. Przycisk mogę kliknąć sam. Potrzebuję agenta, który przygotuje wszystko tak, żeby to kliknięcie było łatwe.
Szkielet, który dziś budujemy, robi dziewięć rzeczy: pakiet kontekstu (context pack), pobieranie danych (ingest), dzielenie na fragmenty (chunking), normalizacja, przechowywanie, wyszukiwanie, cytowanie, eksport i bramka (gate). Ta ostatnia to zasada z początku filmu: agent może czytać, porządkować, redagować i cytować — ale nie wolno mu wysyłać, płacić ani podpisywać. I chcę być jasny: to zadanie, które dajemy agentowi od samego początku, żeby miał dobre barierki. Nigdy nie dajemy mu opcji wykonania niedozwolonego kroku. A na was, ludziach, spoczywa utrzymanie tej barierki podczas budowy — i faktyczne testowanie oraz walidacja, zanim złożycie odwołanie ubezpieczeniowe czy zeznanie podatkowe. To wy je składacie, nie agent.
Plan jest taki: trzy buildy w jednym filmie, ta sama fundamentalna struktura. Zaczynamy łatwo — od poczty i kalendarza, czyli nieustrukturyzowanego bałaganu o bardzo niskiej stawce. Potem zatrzymam się i pokażę „most” — ruch, który przenosi was ze świata e-maili do zaawansowanych zastosowań, a który wszyscy pomijają. Na koniec odwołania ubezpieczeniowe i podatki — nasze zaawansowane przypadki.
Build 1: e-mail i kalendarz — poligon, gdzie błędy są tanie
Bądźmy szczerzy: wasza skrzynka to pewnie pożar na wysypisku. Moja też była. I nie dlatego, że jesteśmy niezorganizowani — będę to powtarzał. E-mail to wysiłek, który dają nam inni ludzie. Wszystko tam ląduje nie według naszej agendy, i strasznie trudno to ustrukturyzować.
Zauważmy coś, zanim zaczniemy: to nie jest tylko przykład „na kółkach treningowych”. Wasz formularz W-2 pewnie leży gdzieś w tej skrzynce — mój leżał. (Informacja dodatkowa: W-2 to amerykański odpowiednik PIT-11 — roczna informacja o dochodach od pracodawcy.) List z odmową od ubezpieczyciela mógł przyjść jako załącznik PDF. Notatki od lekarza mogą prowadzić do bezpiecznych wiadomości. Praca wysokiego zaufania, do której zmierzamy, często odbywa się przez e-mail.
Oto wątek, w którym ktoś próbuje umówić ze mną spotkanie. Agent dostaje pakiet kontekstu — to pierwsza idea szkieletu. Pakiet kontekstu po prostu definiuje, co agentowi wolno czytać: ten wątek, ograniczenia mojego kalendarza, zaangażowane osoby. I ma jeden cel: przygotować odpowiedź z propozycją rezerwacji w kalendarzu. Zwróćcie uwagę na słowo „przygotować”.
Patrzcie, co robi. Pobiera wątek. Wyciąga osoby, zakresy dat, niezgodność stref czasowych. Daty stają się datami, ludzie stają się ludźmi — to się nazywa normalizacja. Wiem, że brzmi nudno, ale właśnie ta nudna robota sprawia, że agent może wykonywać użyteczną pracę wysokiego zaufania. Obiecuję, że warto. Agent sprawdza moje ograniczenia, redaguje odpowiedź i buduje proponowaną rezerwację w kalendarzu.
A teraz uwaga, bo na tym momencie obraca się cały film. Szkic jest gotowy i oczywistym następnym krokiem byłoby wysłanie go — a agent się zatrzymuje. I ja tego chcę. Zostawia szkic, zostawia proponowaną rezerwację i zostawia „paragon”: jakich źródeł użył, co zmienił, co wciąż wymaga mojej zgody. Jeśli wszystko się zgadza, po prostu wyślę. Jeśli nie — poprawię. Ten paragon jest dla mnie kluczowy. To różnica między „AI to załatwiło” a „wiem, co tu się stało, i mogę AI zaufać”. Budowanie zaufania od pierwszego dnia jest niezbędne, jeśli kiedykolwiek chcecie, żeby wasze AI zajmowało się delikatną pracą, w której na szali są prawdziwe pieniądze. Bo wszyscy wiemy: wygrane odwołanie ubezpieczeniowe czy poprawnie rozliczone podatki ze zwrotem to realne pieniądze — potencjalnie tysiące dolarów. Jeśli chcecie w tym pomocy, musicie najpierw dobrze załatwić kwestię zaufania.
Most, który wszyscy pomijają
Zatrzymajmy się na chwilę, bo to jest ruch, którego prawie wszyscy nie zauważają — i powód, dla którego większość ludzi nigdy nie wychodzi poza proste demo agenta e-mailowego. Można by pomyśleć, że przejście od agenta pocztowego do odwołania ubezpieczeniowego oznacza start od zera: nowe narzędzie, nowa konfiguracja, nowy system o wyższym zaufaniu. Nie oznacza — jeśli zbudowaliście to dobrze.
Spójrzcie, co już posiadacie po buildzie pierwszym. Macie ingest: zamianę dokumentów na tekst, z którego agent może korzystać, z kotwicami prowadzącymi z powrotem do źródła. Macie normalizację: daty stają się datami, ludzie ludźmi. Macie paragon. Macie bramkę. To są prymitywy, klocki. I żadnego z nich nie obchodzi, czy jesteście w wątku o umawianiu spotkania, czy w sprawie odmowy ubezpieczeniowej. Dla agenta to to samo. Dlatego wciąż nazywam to kołem zamachowym: każdy build, jeśli robimy go dobrze, odkłada umiejętność na półkę — i przez to następny build jest tańszy.
Build 2: odwołanie od decyzji ubezpieczyciela — zadanie, które kosztuje was pieniądze
Najpierw powiem, co tu jest prawdziwe, a co nie, bo chcę, żebyście naprawdę mogli temu demu zaufać. Dokumenty polis, które zobaczycie, są prawdziwe — ubezpieczyciele publikują dokumenty swoich planów, więc ten system odpytuje faktyczny język polisy faktycznego ubezpieczyciela. Pacjent, ze względu na prywatność, jest syntetyczny. List odmowny zbudowano na wzór listów, które ludzie publikują publicznie, ale wszystkie dane identyfikujące zostały zamaskowane. Ten build działa dokładnie tak samo na waszych prawdziwych plikach — a wasze zostają na waszym komputerze.
W pakiecie kontekstu pojawiają się nowe elementy: list odmowny, prawdziwe polisy, historia roszczeń i dokumenty pomocnicze. I nowy cel: nie chcę listu odwoławczego „na wyczucie”. Chcę teczki sprawy, którą mogę skontrolować. To już delikatniejsza praca niż e-mail.
Do dzieła. Agent zaczyna od chunkingu. List odmowny to nie jeden blok tekstu: ma datę, powód odmowy, numer roszczenia, termin — i gdzieś w środku akapit mówiący, jakie dowody mogłyby zmienić tę decyzję. Polisa też nie jest jednym blokiem: ma sekcje, definicje, wyłączenia i zasady odwołań. Agent dzieli wszystko na otagowane, adresowalne fragmenty.
Teraz normalizacja. Jak poprzednio: daty stają się datami, kwoty kwotami. I jedna rzecz, która ma znaczenie: brakujące dokumenty stają się „brakującymi dokumentami”. To szczególnie ważne, gdy macie lukę w dowodach — bo wpływa na to, na czym możecie działać, i nie zaskoczy was na kilka dni przed jakimś terminem. Wszystko jest przechowywane lokalnie: mała baza danych SQLite i folder — możecie sami otworzyć źródła i rekordy. Nic nie opuszcza waszego komputera. Nigdy nie musicie prosić modelu, żeby „pamiętał”, co się stało.
Kiedy ubezpieczyciel wam odmawia, ma obowiązek zacytować konkretny zapis polisy, na którym się opiera. Pomyślcie, co to znaczy: nie szukacie czegoś, czego nie możecie znaleźć. Już znacie adres tego, co wam szkodzi. Nie ma tu więc bazy wektorowej ani wyszukiwania po podobieństwie — system po prostu wyszukuje po strukturze: powód odmowy, dokładną sekcję polisy, cytowania z listu odmownego, termin i checklistę dokumentów. I pierwszą rzeczą, którą agent robi po tym wszystkim, jest test zdrowego rozsądku: czy cytowana sekcja rzeczywiście mówi to, co list sugeruje, że mówi? Czasami nie mówi. A kiedy nie mówi — to jest znalezisko numer jeden.
Spójrzcie, co z tego powstaje. Oś czasu: data usługi, data roszczenia, data odmowy, termin odwołania. Mapa odmowy. Dokładny zapis polisy, który tym wszystkim rządzi. Checklista dowodów: co mam teraz, czego jeszcze nie ma. I owszem, jest szkic listu odwoławczego — ale to nie list jest tu najważniejszy. Naprawdę liczy się cały pakiet dowodowy, bo mapa cytowań pozwala faktycznie zweryfikować, że to, czym argumentujecie, jest prawdą.
I tu przewrotna teza wbrew obiegowej mądrości: agent nie wygrywa odwołania za was. On zamienia stos nieustrukturyzowanych informacji w teczkę sprawy, dzięki której wy możecie wygrać. Przegrywaliście — albo nie wygrywaliście — bo przychodziliście na ustrukturyzowaną walkę z nieustrukturyzowanym stosem. Ten build nie gwarantuje wygranej. Oznacza tylko, że przestaliście przychodzić ze złymi danymi.
I znowu patrzcie, gdzie agent się zatrzymuje. Zredagował odwołanie, adres, numer roszczenia, termin — a viralowe demo powiedziałoby teraz: „No to wysyłamy”. Nie. Agent staje. I powiem to wprost: to wy odpowiadacie za to, co wysyłacie. Nie namawiam nikogo, żeby strzelał takim pakietem do ubezpieczyciela bez przeczytania. Cytowania przyspieszają wasz przegląd — nie czynią go opcjonalnym. Bo jeśli agent sam wyśle złe odwołanie, macie już dwa problemy: odmowę i bałagan, którego narobił agent. To ten sam szkielet co w buildzie e-mailowym. Rzeczowniki się zmieniły, ale struktura danych i sposób rozwiązania problemu są z punktu widzenia agenta dokładnie te same. I tak buduje się rozpęd.
Build 3: podatki — trzeci obrót koła zamachowego
Build numer trzy: podatki. Każdy musi się z nimi mierzyć. I zwróćcie uwagę, jak szybko to teraz idzie — to koło zamachowe robi to, co obiecałem na początku. Znów dokumenty syntetyczne: folderów podatkowych nikt nie powinien oglądać na YouTube. Bierzemy nowe obiekty: W-2, formularze 1099, faktury, paragony, wyciągi bankowe, notatki o przejechanych kilometrach — pełen zestaw. (Informacja dodatkowa: 1099 to amerykańskie formularze dokumentujące dochody spoza etatu, np. z działalności czy zleceń.) I zauważcie, gdzie mieszkała połowa tych rzeczy: w skrzynce pocztowej. Ten pożar na wysypisku z buildu pierwszego jest teraz źródłem danych dla buildu trzeciego.
Nowy cel: nie składamy zeznania. Przygotowujemy pakiet do przeglądu — dla was albo dla waszego księgowego. A jeśli płacicie komuś setki lub tysiące dolarów za mozolne przeczesywanie waszej sterty dokumentów podatkowych, zrozumcie, za co płacicie: płacicie za przeczesywanie. A to jest właśnie przeczesywanie dokumentów.
To ten sam szkielet, który już zbudowaliśmy, i przechodzi tę samą sekwencję: pobieracie dane, dzielicie na formularze — przychody, wydatki, niewiadome — normalizujecie do księgi roku podatkowego z datą, kontrahentem, kwotą, kategorią i plikiem źródłowym. I znów mamy barierki: strażnik cytowań nie przepuści odliczenia bez dowodu. Jeśli agent twierdzi, że coś jest wydatkiem firmowym, wskaże paragon — albo oflaguje tę pozycję, zamiast udawać, że wie.
Eksport, który dostajecie, to pakiet, a nie wypełniony formularz 1040. (Informacja dodatkowa: 1040 to główny formularz amerykańskiego rocznego zeznania podatkowego, odpowiednik PIT-36/37.) Dostajecie podsumowanie przychodów, księgę wydatków, mapę dowodów dla odliczeń, listę brakujących dokumentów — plus listę pytań do księgowego. I ta ostatnia rzecz jest niedoceniana: dobry agent nie tylko daje odpowiedzi. Dobry agent daje wam lepsze pytania do zadania ekspertowi. I spójrzcie: nie składa, nie wysyła, nie mailuje do waszego księgowego. Przygotowuje folder, daje podsumowanie i staje.
Cały build zajął ułamek czasu konfiguracji buildu ubezpieczeniowego. Dlaczego? Bo nic w nim nie było nowe. Trzeci obrót koła — dużo łatwiej. To zasada, którą chcę, żebyście zrozumieli: wkładacie pracę w budowę systemu, a potem możecie robić mnóstwo wrażliwych rzeczy stosunkowo łatwo. To jest rozszerzalny agent. Bawimy się w klocki Lego.
Wspólny mianownik: czyste dane i tanie modele
Postawcie te trzy buildy obok siebie: e-mail, ubezpieczenia, podatki. Jasne, zmieniły się słowa, zmieniły się stawki, ale szkielet agenta — nie. Wciąż potrzebny był pakiet kontekstu, ingest, chunking, normalizacja, przechowywanie, wyszukiwanie, cytowanie, eksport i bramka. Widzieliście, jak przechodzę tę listę trzy razy. To właśnie jest ten build.
I jeszcze jedno, co łączy wszystkie trzy buildy pod spodem: czyste, znormalizowane dane. To jest sekret. Kiedy daty są datami, a każde twierdzenie ma adres, przestajecie potrzebować najdroższego modelu do większości pracy. Często pytają mnie, zwłaszcza po premierze Fable: jaki jest najtańszy model? Model open source. To ta sama zagrywka, którą Apple chce rozegrać na waszym telefonie: lekkie modele potrafią robić zaawansowane rzeczy, gdy dane pod spodem są czyste. Przygotowuję więc grunt pod większy wybór modeli — dbając najpierw o dane.
Cztery zasady na koniec
Po pierwsze: trudną częścią nie jest ostatni klik. Trudną częścią jest kontekst. Najpierw uporządkujcie tę brudną stertę danych. Po drugie: uczcie się bramki tam, gdzie błędy są tanie — i wiedzcie, gdzie robienie czegoś zaczyna być drogie. Po trzecie: rozumiejcie, gdzie potrzebna jest ludzka ekspertyza. Jeśli coś dotyka pieniędzy albo zdrowia, musi się zaangażować profesjonalista — nie udawajcie, że AI po prostu wykona tę robotę. Po czwarte: nie budujcie jednorazówek. Błagam — budujcie koło zamachowe, tak jak dziś pokazałem. Każdy build czyni następny tańszym, a most od waszego agenta na poziomie 101 do poziomu 201 i 301 jest krótszy, niż myślicie.
Wpis na Substacku zawiera oba runbooki — build odwołań zdrowotnych i organizer przygotowania podatków — plus dwa otwarte „skille”, które pod nimi leżą, przewodnik po inżynierii kontekstu i instrukcje krok po kroku. A teraz prośba: napiszcie w komentarzach, na jaki folder skierowalibyście to jako następny — ubezpieczenia, podatki czy coś, o czym nie pomyślałem. Wybiorę kilka i zbudujemy wokół nich przewodniki, bo ta półka będzie z czasem rosła. Następnym razem porozmawiamy o tym, jak mieć pod ręką każdy model na świecie, łącznie z tymi tanimi. Bo gdy wasze dane są tak czyste, jak pokazałem w tym filmie, do większości tej pracy nie potrzebujecie drogiego modelu — wystarczy ten sam szkielet agenta zastosowany do innej papierologii, z ludzkim „tak” albo „nie” na końcu. Subskrybujcie — i otwórzcie wreszcie ten folder.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Buduj jeden szkielet agenta, nie osobne narzędzia do każdej sprawy
Na czym polega: E-mail, odwołanie ubezpieczeniowe i podatki to dla agenta ten sam problem: zamiana nieustrukturyzowanego bałaganu w ustrukturyzowany kontekst. Dziewięć elementów szkieletu (pakiet kontekstu, ingest, chunking, normalizacja, przechowywanie, wyszukiwanie, cytowanie, eksport, bramka) działa we wszystkich domenach.
Jak stosować: Projektując agenta do dowolnej papierologii, przejdź świadomie przez wszystkie dziewięć kroków i buduj każdy jako oddzielny, wielokrotnego użytku klocek, a nie fragment jednorazowego skryptu.
Na co uważać: Pokusa, by „szybko skleić” rozwiązanie pod jedną sprawę — wtedy przy następnym problemie zaczynasz od zera i koło zamachowe nigdy nie ruszy.
2.Bramka od pierwszego dnia: agent nigdy nie wysyła, nie płaci, nie podpisuje
Na czym polega: Agent może czytać, porządkować, redagować i cytować, ale nieodwracalne działania (wysłanie odwołania, złożenie zeznania, płatność) są mu odebrane na poziomie konstrukcji, nie prośby.
Jak stosować: Nie dawaj agentowi w ogóle dostępu do akcji „wyślij/złóż/zapłać” — niech kończy pracę na szkicu i pakiecie do zatwierdzenia. Ostatni klik wykonujesz ty, po lekturze.
Na co uważać: Bramka trzymana tylko w promptcie („nie wysyłaj”) to nie bramka. Jeśli agent technicznie może wykonać akcję, kiedyś ją wykona — a wtedy masz dwa problemy: pierwotny i bałagan po agencie.
3.Skup się na dźwiganiu ciężaru, nie na spektakularnym „kliknięciu”
Na czym polega: W demach imponuje moment, gdy agent coś wysyła. Realna wartość jest gdzie indziej: w przekopaniu się przez biurokrację i przygotowaniu wszystkiego tak, by decyzja człowieka była łatwa.
Jak stosować: Oceniaj agentów pytaniem: „ile godzin przeczesywania dokumentów mi oszczędził?”, a nie „czy umie działać autonomicznie?”. Kliknięcie przycisku zostaw sobie.
Na co uważać: Marketing agentów promuje autonomię akcji. Nie mierz sukcesu liczbą wykonanych działań, tylko jakością przygotowanego kontekstu.
4.Zawsze wymagaj „paragonu” po pracy agenta
Na czym polega: Po każdym zadaniu agent zostawia rozliczenie: jakich źródeł użył, co zmienił, co wymaga twojej zgody. To różnica między „AI to załatwiło” a „wiem, co się stało, i mogę temu zaufać”.
Jak stosować: Dodaj do każdego workflow agenta obowiązkowy krok raportu końcowego ze źródłami i listą otwartych decyzji. Przeglądaj go przed zatwierdzeniem czegokolwiek.
Na co uważać: Paragon przyspiesza weryfikację, ale jej nie zastępuje — cytowania trzeba wyrywkowo sprawdzać w źródłach, zwłaszcza przy sprawach z pieniędzmi na szali.
5.Nudna normalizacja to fundament pracy wysokiego zaufania
Na czym polega: Daty stają się datami, kwoty kwotami, ludzie ludźmi — a brakujące dokumenty jawnie „brakującymi dokumentami”. Bez tego agent operuje na blobie tekstu i zgaduje.
Jak stosować: Zanim poprosisz model o wnioski, każ mu najpierw zbudować znormalizowaną strukturę (np. księgę z datą, kontrahentem, kwotą, kategorią i plikiem źródłowym). Jawnie modeluj luki w danych, żeby nie zaskoczyły cię przed terminem.
Na co uważać: To najmniej efektowny etap i dlatego najczęściej pomijany. Pominięcie go mści się dokładnie wtedy, gdy stawka rośnie.
6.Ćwicz na tanich błędach, zanim zaufasz agentowi przy drogich
Na czym polega: Poczta i kalendarz to poligon: te same prymitywy co przy ubezpieczeniach i podatkach, ale pomyłka kosztuje najwyżej niezręczność, nie pieniądze.
Jak stosować: Uruchom pełny szkielet (z bramką i paragonem) najpierw na niskostawkowych zadaniach. Dopiero gdy nauczysz się, gdzie agent się myli, przenoś te same klocki na sprawy finansowe i zdrowotne.
Na co uważać: Nie przeskakuj etapu nauki dlatego, że „e-mail to nuda” — to właśnie tam tanio kalibrujesz zaufanie. I odwrotnie: nie utknij na e-mailu na zawsze; buildy 2 i 3 to cel.
7.Wykorzystuj strukturę problemu zamiast wyszukiwania wektorowego
Na czym polega: Ubezpieczyciel przy odmowie musi zacytować konkretny zapis polisy — znasz więc „adres” tego, co ci szkodzi. Wystarczy wyszukiwanie po strukturze (sekcja, powód, termin), bez bazy wektorowej i similarity search.
Jak stosować: Zanim sięgniesz po RAG i embeddingi, sprawdź, czy dokumenty nie mają już wbudowanych adresów: numerów sekcji, referencji, identyfikatorów spraw. Pierwszym krokiem analizy zrób sanity check: czy cytowana sekcja naprawdę mówi to, co twierdzi pismo — rozbieżność bywa najmocniejszym argumentem.
Na co uważać: Nie każdy problem tak wygląda; wyszukiwanie strukturalne działa, gdy dokumenty faktycznie się nawzajem cytują. Nie dodawaj też infrastruktury wektorowej „na zapas” tam, gdzie prosta struktura wystarczy.
8.Produktem jest teczka sprawy, nie list
Na czym polega: Agent nie wygrywa odwołania — dostarcza pakiet dowodowy: oś czasu, mapę odmowy, dokładny język polisy, checklistę dowodów i mapę cytowań. Przegrywałeś, bo przychodziłeś na ustrukturyzowaną walkę z nieustrukturyzowanym stosem.
Jak stosować: Definiuj cel agenta jako „przygotuj sprawdzalny pakiet”, nie „napisz pismo”. Przy podatkach analogicznie: podsumowanie przychodów, księga wydatków, mapa dowodów odliczeń, braki — plus lista pytań do eksperta.
Na co uważać: Uporządkowane dane zwiększają szanse, ale niczego nie gwarantują. Nie traktuj ładnego pakietu jako substytutu merytorycznej racji ani profesjonalnej porady.
9.Trzymaj wrażliwe dane lokalnie
Na czym polega: W buildach demo wszystko jest przechowywane na komputerze użytkownika (SQLite plus folder z plikami) — źródła i rekordy można otworzyć samodzielnie, nic nie opuszcza maszyny i nie trzeba liczyć na „pamięć” modelu.
Jak stosować: Dla dokumentów medycznych, ubezpieczeniowych i podatkowych wybieraj architekturę lokalną: lokalna baza, lokalne pliki, dane wysyłane do modelu tylko w niezbędnym zakresie. Do testów i publikacji używaj danych syntetycznych lub zanonimizowanych.
Na co uważać: „Lokalnie” przestaje być lokalne, gdy agent woła zdalne API z pełną treścią dokumentów — świadomie kontroluj, co dokładnie trafia do modelu w chmurze.
10.Czyste dane pozwalają używać tanich modeli
Na czym polega: Gdy dane są znormalizowane, a każde twierdzenie ma adres w źródle, większość pracy nie wymaga najdroższego modelu — wystarczą lekkie, w tym open source. To ta sama strategia, którą Apple planuje na telefonach.
Jak stosować: Zainwestuj w rurociąg danych, a potem dobieraj model do etapu: tani do ekstrakcji i klasyfikacji na czystych danych, mocniejszy tylko tam, gdzie trzeba rozumowania na trudnym materiale.
Na co uważać: Tani model na brudnych danych to fałszywa oszczędność — kolejność jest nieprzypadkowa: najpierw czyste dane, dopiero potem optymalizacja kosztów modelu.