Dlaczego logi agentów nie spełnią wymogów artykułu 12: zapisy decyzji, przyczynowość i pochodzenie
Zapisy działań agentów nie spełnią wymogów artykułu 12 unijnej ustawy o sztucznej inteligencji. Rejestruj decyzje agentów sztucznej inteligencji jako trwałe obiekty z powiązaniami przyczynowo-skutkowymi, łańcuchem haszów wskazującym źródło pochodzenia oraz ustalonymi regułami.
W sierpniu 2026 roku weszła w pełną moc zasada, której większość zespołów inżynieryjnych jeszcze nie odczuła. Artykuł 12 Rozporządzenia UE w sprawie sztucznej inteligencji stanowi, że systemy AI o wysokim ryzyku muszą technicznie umożliwiać automatyczne rejestrowanie zdarzeń przez cały okres ich funkcjonowania, przy czym możliwość śledzenia musi być proporcjonalna do celu systemu. Artykuł 26 nakłada na osoby odpowiedzialne za wdrożenie obowiązek przechowywania tych zapisów przez co najmniej sześć miesięcy, a dłużej, jeśli wymaga to inny przepis prawa.
Inżynier czytający ten tekst zauważa dziwną nierównowagę. Cel jest precyzyjnie określony, natomiast wymagany format jest ledwo wspomniany. Celem jest możliwość odtworzenia później pojedynczej decyzji. Produkt APM tego nie zapewnia, ponieważ został stworzony do innych celów. Sklep wektorowy również tego nie zapewnia.
Czas jest nieodpowiedni, ponieważ pracownicy właśnie przestali odpowiadać na pytania i zaczęli podejmować działania. Zatwierdzają wydatki, zmieniają rozmiar infrastruktury, przekierowują roszczenia ubezpieczeniowe, odrzucają aplikantów i zatwierdzają zwolnienia. Każda z tych decyzji może kiedyś zostać poddana pod krytykę ze strony firmy, która będzie musiała ją uzasadnić, a w większości organizacji dzisiaj prawdziwa odpowiedź brzmiałaby, że nie jest w stanie tego zrobić.
Zanim powstały przepisy i zanim pracownicy mogli podejmować działania, trybunał w Kolumbii Brytyjskiej przetestował tę samą słabość w małej skali. Pozostaje to najjaśniejszym dostępnym przykładem.
Babcia Jake’a Moffatta zmarła w listopadzie 2022 roku. Tego samego dnia odwiedził stronę internetową Air Canada, aby zarezerwować lot do Toronto, a nie wiedząc, jak funkcjonują taryfy dla osób w żałobie, zapytał o to chatbotu linii lotniczych. Bot poinformował go, że może natychmiast kupić bilet w pełnej cenie i poprosić o zwrot różnicy w cenie z tytułu taryfy żałobnej w ciągu 90 dni. Zanim na to poszedł, Moffatt postąpił rozsądnie i zrobił skrynkotek z odpowiedzią. Następnie zarezerwował bilet, poleciał, uczestniczył w pogrzebie i złożył wniosek o zwrot pieniędzy.
Air Canada odrzuciła jego prośbę. Takiej polityki nie istniało, a bot ją wymyślił.
Część instruktażowa to kontynuacja opisu. W Trybunale ds. Rozstrzygania Sporów Cywilnych linia lotnicza twierdziła, że nie może być pociągnięta do odpowiedzialności za to, co powiedział jej chatbot, określając go jako odrębną jednostkę odpowiedzialną za własne działania. Członek trybunału, Christopher Rivers, nazwał to argumentowanie godnym uwagi i zauważył, że linia lotnicza nigdy nie wyjaśniła, dlaczego ktoś miałby je przyjąć. Chatbot jest częścią strony internetowej, a firma odpowiada za swoją stronę. Air Canada zapłaciła 812,02 CAD.
Ta kwota jest znikoma. Decydującą liczbą jest zero – liczba dokumentów, które Air Canada mogłaby przedstawić, aby wykazać, dlaczego jej własny system wypowiedział się w taki sposób. Jedynym trwałym dowodem z całego rozprawy była zrzutka ekranu klienta.
To samo zaniedbanie stopniowo się pogłębiało. W kwietniu 2025 roku bot obsługi klienta w firmie Cursor opracował zasadę ograniczającą subskrypcje do jednego urządzenia. Klienci zaczęli je anulować, a firma dowiedziała się o tym tylko dlatego, że jeden z założycieli znalazł odpowiedni temat na Reddit. Wzorzec jest identyczny, zasięg skutków większy, a tempo szybsze, przy czym nie było potrzeby żadnego sądu.
A teraz wyobraźmy sobie tę samą słabość dowodową przedstawioną regulatorowi, powiązaną z agentem obsługującym przenoszenie pieniędzy.
Debugowanie i odpowiedzialność to różne zadania
Większość rozwiązań technologicznych nigdy nie robi tu istotnego rozróżnienia.
Obserwowalność skupia się na procesie wykonywania zadań. Rejestruje to, co proces zrobił podczas jednego uruchomienia: okna czasowe, wywołania narzędzi, liczbę tokenów, próby ponownego wykonania i opóźnienia. Jest ona pobierana losowo, wygasza po określonym oknie przechowywania i dotyczy tylko jednej prośby. To dokładnie to, co jest potrzebne do znalezienia błędu we wtorek.
Odpowiedzialność jest skoncentrowana wokół konkretnych dziedzin. Odzwierciedla to, do jakich wniosków doszła organizacja, na jakich dowodach, zgodnie z jaką polityką oraz co wydarzyło się później. Musi przetrwać migracje frameworków, wycofywanie modeli, odbudowę indeksów, reorganizację oraz odejście dwóch kolegów.
W innych obszarach biznesu jest to rutyna. Zmiany w produkcji nigdy nie są odbudowywane na podstawie logów aplikacji, ponieważ zapis zmiany zawiera informacje o autorze, numerze zgłoszenia oraz zatwierdzeniu. Sytuację finansową również nigdy nie odbudowuje się na podstawie śladów HTTP, gdyż istnieją wpisy w dzienniku księgowym. Zamówienia, płatności, zatwierdzenia i wdrożenia to trwałe obiekty, z których każdy ma swój cykl życia, właściciela oraz zasady przechowywania.
Decyzje agentów to jedyny rodzaj istotnych zdarzeń, które nadal pozostają w formie nieustrukturyzowanych informacji, bez żadnych mechanizmów kontrolnych.
Wersja o 3 nad ranem
Przedstawienie sytuacji w kategoriach zgodności z regulacjami sprawia, że niepowodzenie brzmi egzotycznie, podczas gdy w rzeczywistości jest dość powszechne, dlatego konkretny przypadek może pomóc.
Dwadzieścia minut po wypuszczeniu aktualizacji system zaczyna zwracać błędy typu 5xx. Pracownik odpowiedzialny za analizę błędów porównuje ich liczbę z okresem wdrażania, nie widzi żadnych ostrzeżeń dotyczących infrastruktury i klasyfikuje zdarzenie jako regresję po aktualizacji. Pracownik zajmujący się naprawami cofa aktualizację – błędy wracają do normy. Pracownik odpowiedzialny za wdrażanie ponownie otwiera kolejkę z zadaniami. Ktoś wysyła sygnał potwierdzenia w kanale przeznaczonym do komunikacji w razie incydentów, a zespół może iść spać. W sumie minęło jedenaście minut, a nie odbywa się żadna analiza incydentu, ponieważ problem wydawał się sam się rozwiązać.
Jednak to nie aktualizacja była winna. Usługodawca zajmujący się płatnościami miał problemy z wydajnością i akurat w momencie cofnięcia aktualizacji odzyskał normalną pracę. Związek tych dwóch zdarzeń był przypadkowy, a pracownicy stworzyli na jego podstawie wiarygodną historię wydarzeń.
Prawda wyjdzie na jaw w październiku, gdy powtórzy się ten sam wzorzec i ktoś zapyta, czy incydent z kwietnia miał tę samą przyczynę. Czas to sprawdzić.
Do tej pory ślady już wygasły – zostały usunięte w czerwcu. Szablon zapytania przeszedł dwie modyfikacje. Gdy zmienił się model embeddingowy, zbudowano na nowo indeks wyszukiwania, więc fragmenty instrukcji, które agent czytał wtedy, to nie te, które wyświetliłby dziś. Wersja modelu podana w nagłówku żądania została wycofana. To, co pozostało, to wątek rozmowy zakończony emotikonem kciuka w górę.
Na to pytanie nie można odpowiedzieć. Nikt nie był nieostrożny. Nic w całym systemie nie zostało zaprojektowane tak, by przechowywać odpowiedź.
Dlaczego lepsza pamięć tego nie naprawi
Zwykłym instynktem jest użycie warstwy pamięci, która zazwyczaj stanowi magazyn wektorów. To rozwiązuje zupełnie inny problem.
Wbudowane systemy wyszukiwania dobrze radzą sobie z jednym pytaniem: co wygląda tak samo? Nie mogą jednak podać, co system sądził o godzinie 14:02 w danym dniu, jakie wcześniejsze wnioski doprowadziły do tych ustaleń, skąd pochodzi dany fakt, ani czy zasada mająca na celu ograniczenie określonej akcji rzeczywiście została wdrożona.
Istnieje również subtelniejszy defekt. Proces wydobywania informacji nie jest stale powtarzalny. Po ponownym wdrożeniu korpusu za pomocą nowszego modelu identyczne zapytanie zwraca inny obszar danych, więc to, co traktowano jako rekord, w tle uległo zmianie. Ślad audytowy, który można po cichu przepisać poprzez aktualizację zależności, nie jest już prawdziwym śladem audytowym.
Każda warstwa odpowiada na swoje własne pytanie:
- Wyszukiwanie wektorowe: które elementy wyglądają tak samo jak ten?
- Graph wiedzy: z czym jest on powiązany?
- Pochodzenie: skąd pochodzi i czy nadal jest ważny?
- Zapisy decyzji: co zostało ustalone i na jakich podstawach?
- Związki przyczynowe: które zdarzenie wpłynęło na które?
- Reguły: jaka polityka określa wynik?
- Stan czasowy: jakie były wartości systemu z dnia 14 marca?
Prawdziwe śledztwo typu „dlaczego to zrobiło?” wymaga większości z tych elementów. Tylko jeden z nich to magazyn wektorów.
Przekształcanie decyzji w obiekt
W tym miejscu warto przyjrzeć się Semantica. Jest to warstwa w Pythonie licencjonowana przez MIT, która działa pod frameworkiem agentów i traktuje kontekst jako graf zamiast jako zbiór tekstu. Budowa grafu, rozumowanie i śledzenie pochodzenia są deterministyczne, bez udziału modeli językowych, co jest ważne, gdy wynik ma służyć jako dowód.
Idea główna jest prosta. Decyzja staje się czymś celowo zapisanym, a nie czymś, co jest po prostu zapisywane w dzienniku zdarzeń.
from semantica.context import ContextGraph
ctx = ContextGraph(advanced_analytics=True)
decision_id = ctx.record_decision(
category="incident_triage",
scenario="Checkout 5xx elevated 20 minutes after release 2026.31",
reasoning="Error onset correlates with rollout window; no infra alerts; "
"no dependency alarms visible at time of assessment",
outcome="classified_as_release_regression",
confidence=0.83,
)
Mechanizm jest prosty. To, co się zmienia, to to, co autor jest zmuszony dokładnie opisać. Zamiast wolnego tekstu w linii dziennika konieczne jest podanie kategorii, scenariusza, przyczyn, wyniku oraz wartości pewności. Wszystko to można sprawdzić po osiemnastu miesiącach, czego nie da się zrobić w przypadku zwykłego tekstu.
Rozważmy ciąg reasoning w scenariuszu z października. Stwierdza on, że podczas dokonywania oceny nie widoczne były żadne alarmy dotyczące zależności. Ta jedna fraza zmienia narrację z opisu agenta, który popełnił błąd, na opis agenta, który wyciągnął słuszny wniosek na podstawie niepełnych danych, co wskazuje na lukę w monitorowaniu, którą należy zamknąć. Te dwa podejścia prowadzą do zupełnie różnych spotkań.
Uwaga dotycząca tego pola. Nie jest to miejsce na surowy ciąg rozumowań modelu, który jest niestabilny, czasami wymyślony i niemożliwy do obrony punkt po punkcie przed osobą z zewnątrz. Zapisz uzasadnienie, za które organizacja jest gotowa wziąć odpowiedzialność: rozważone dowody, przekroczona granica, zastosowana polityka, osoba, która ją anulowała. W każdym razie to lepiej służy procesowi produkcyjnemu.
Jeden rekord to linia dziennika, łańcuch to infrastruktura
Prawdziwe procesy pracy agentów rozprzestrzeniają się, a szkody rzadko występują tylko w jednym węźle. Pojawiają się we wszystkim, co znajduje się poniżej w łańcuchu i w milczeniu przyjęło błędny wniosek.
Najbardziej znanym przykładem z okresu przed sztuczną inteligencją jest Knight Capital. Błąd podczas wdrożenia w 2012 roku spowodował, że przestarzały kod nadal był w użyciu, i w ciągu około 45 minut firma straciła około 440 milionów dolarów. Nikt nie wątpił w to, co robi oprogramowanie, a każda transakcja została zarejestrowana. Problem polegał na tym, że nikt nie mógł ręcznie śledzić konsekwencji w takim tempie, w jakim się one pojawiały.
Semantica umożliwia określenie powiązań pomiędzy decyzjami w momencie ich pisania:
triage_id = ctx.record_decision(
category="incident_triage",
scenario="Checkout 5xx elevated after release 2026.31",
reasoning="Error onset correlates with rollout window; no infra alerts",
outcome="classified_as_release_regression",
confidence=0.83,
)
rollback_id = ctx.record_decision(
category="remediation",
scenario="Contain checkout 5xx",
reasoning="Regression attributed to release; rollback is lowest-risk action",
outcome="rolled_back_to_2026.30",
confidence=0.91,
)
unblock_id = ctx.record_decision(
category="release_gate",
scenario="Resume deploy queue after containment",
reasoning="Error rate normal for 30 minutes post-rollback",
outcome="deploy_queue_reopened",
confidence=0.86,
)
ctx.add_causal_relationship(triage_id, rollback_id, relationship_type="CAUSED")
ctx.add_causal_relationship(rollback_id, unblock_id, relationship_type="INFLUENCED")
why = ctx.trace_decision_chain(unblock_id)
blast_radius = ctx.analyze_decision_impact(triage_id)
Istnieją trzy typy relacji: CAUSED, INFLUENCED oraz PRECEDENT_FOR. Słownictwo jest niewielkie, co jest do przyjęcia. Prawie cała wartość pochodzi z jednej operacji.
Gdy w październiku odkryto, że triaż był błędny, pytanie się zmienia. Zapytanie o to, które ślady odnoszą się do zwrotów towarów, zwraca czterdzieści tysięcy wierszy. Zapytanie o to, które decyzje przejęły ten wniosek, zwraca krótką, ograniczoną listę: odwołanie zmian, ponowne otwarcie kolejki, wysłane wiadomości do klientów oraz raport z analizy incydentu, którego nikt nie napisał. To właśnie jest zasięg wpływu decyzji subiektywnych, a jest to również operacja niezbędna, gdy agenci przestają tylko sugerować i zaczynają działać.
find_similar_decisions() działa w przeciwnym kierunku i zwraca precedensy. Czy system już kiedyś miał do czynienia z takim żądaniem i co wtedy zrobił? W ten sposób zostaje wykryty agent, który co trzeci wtorek po cichu sobie zaprzecza – prawdziwy błąd, którego nikt nie obserwuje, ponieważ nie istnieje na niego żadna metryka.
Kauzalność to nie pochodzenie
Często myli się te dwa pojęcia, choć odpowiadają one na różne pytania. Wiedza o tym, że decyzja C opierała się na decyzji A, ma niewielką wartość bez informacji o dowodach, na których opierała się decyzja A.
Moduł pochodzenia w Semantica follows W3C PROV-O. Jest niepopularny, ale poprawny.
from semantica.provenance import ProvenanceManager
prov = ProvenanceManager(storage_path="./provenance.db")
prov.track_entity(
entity_id="release_2026_31",
source="ci/pipeline_runs/2026-31/manifest.json",
metadata={"stage": "canary", "extractor": "ManifestParser", "confidence": 0.99},
)
lineage = prov.get_lineage("release_2026_31")
Dwa wybrane tu rozwiązania projektowe warto przejąć nawet przez zespoły, które nigdy nie instalują tej biblioteki.
Po pierwsze, wpisy dotyczące pochodzenia tworzą łańcuch haszowy. Każdy rekord zawiera numer sekwencyjny oraz checksum łączący go z rekordem poprzednim, a funkcja verify_chain() pokazuje, czy historia została zmodyfikowana, czy też jakieś wpisy zostały usunięte. To właśnie odróżnia tabelę, którą każdy może po cichu edytować za pomocą polecenia UPDATE, od takiej, która służy jako dowód.
Po drugie, fakty są unieważniane, a nie usuwane. Gdy coś przestaje być prawdą, jest zastępowane wraz z informacjami o osoby, która to zrobiła, oraz powodem:
prov.invalidate(
"release_2026_31",
agent_id="human_sre_lead",
reason="Error attribution corrected; degradation traced to payments provider",
)
Kolumna z zmienną wartością valid=false pokazuje aktualny stan. Rejestr odnotowuje, że stan kiedyś się różnił, kto go zmienił, kiedy i dlaczego. Wróć do rozprawy w Air Canada i zapytaj, którą z tych informacji potrzebowała linia lotnicza. Odpowiedź jest oczywista.
Wyłączenie polityki z promptu
Kolejną niewidoczną zaletą jest to, że Semantica zawiera prawdziwe silniki rozumowania: forward chaining, Rete, Datalog i SPARQL. Logika jest prosta – jeśli organizacja już zna jakąś zasadę, nie ma powodu, by za każdym razem prosić model językowy o jej improwizowane sformułowanie po angielsku.
from semantica.reasoning import ReteEngine, Rule, Fact, RuleType
engine = ReteEngine()
engine.build_network([
Rule(
rule_id="dual_control_prod",
name="Human approval required for high blast-radius prod changes",
conditions=[
{"field": "env", "operator": "==", "value": "production"},
{"field": "blast_radius", "operator": "in", "value": ["high", "critical"]},
],
conclusion="require_human_approval",
rule_type=RuleType.IMPLICATION,
)
])
engine.add_fact(Fact("chg_014", "change", [{"env": "production", "blast_radius": "high"}]))
matches = engine.match_patterns()
Model nadal przetwarza nieuporządkowane dane wejściowe i proponuje działanie. Zmiana dotyczy sprawdzania, które zatwierdza lub blokuje to działanie: nie jest to już jedynie obiecujący akapit w instrukcjach systemu, który mógłby zostać obejrzany dzięki dziwnie sformułowanemu wyjątkowi. Ponieważ rule_id może być przechowywany w rekordzie decyzji, pytanie o to, która zasadą kierowało się działanie, staje się prostym wyszukiwaniem, a nie debatą między dwiema grupami.
Uwaga: narzędzie do dopasowywania warunków jest celowo proste. Przed tym, jak zostanie użyte pomiędzy agentem a jakimkolwiek regulowanym działaniem, należy je przetestować pod kątem rzeczywistego zestawu zasad. Silnik reguł demonstracyjny nie stanowi kontroli zgodności, a odkrycie braków w trakcie audytu to drogi sposób na ich poznanie.
Monotonne standardy przetrwają ramy
PROV-O obsługuje pochodzenie danych, reprezentację w formacie RDF, zapytania SPARQL, ograniczenia SHACL oraz ontologie OWL. Nic z tego nie jest ekscytujące, a właśnie o to chodzi.
Frameworki agentów mają okres trwania około osiemnastu miesięcy. Wymagania audytowe nie. Osoba przeglądająca dane w 2030 roku nie będzie się przejmować tym, która biblioteka orkiestracji była popularna w momencie podjęcia decyzji, a nikt nie chce trwałego zapisu zamkniętego w proprietarnym formacie eksportu firmy startupowej, która od tamtej pory zmieniła kierunek działania.
Istnieje również serwer MCP, uruchamiany za pomocą python -m semantica.mcp_server. Jego narzędzia obejmują wydobywanie informacji, rejestrowanie decyzji, wyszukiwanie precedensów, analizę łańcuchów przyczynowo-skutkowych oraz rozumowanie. Dzięki temu agent może rejestrować własne decyzje poprzez zwykłe wywołanie narzędzia, bez konieczności dodawania dodatkowych mechanizmów logowania, których mógłby uniknąć.
Prawdziwa cena
Koszty wymagają jasnego sformułowania.
Pierwszym kosztem jest nowy serwis z funkcjami stanowymi, wraz z jego kopiami zapasowymi, migracjami, schematem oraz kontrolą dostępu. Drugim kosztem jest wysiłek związany z modelowaniem, ponieważ nikt inny nie może określić, co stanowi decyzję wartą zapisania. Rejestrowanie każdego kroku generuje kolejny log, tylko znacznie droższy. Rejestrowanie zbyt mało informacji powoduje luki w łańcuchu dokładnie w tych miejscach, gdzie pojawi się pytanie.
Istnieje również koszt kulturowy, który ma tendencję do bycia niedocenianym. Graf decyzji sprawia, że błyskawicznie widać, iż dany agent od czterech miesięcy źle podejmuje określoną decyzję. To właśnie ma służyć temu grafowi, mimo to spotkanie będzie nadal nieprzyjemne.
Projekt rozwija się również szybko. Należy zaznaczyć wersję, która została zweryfikowana. Każdy, kto potrzebuje niepublikowanej wersji oprogramowania, powinien pobrać ją z źródła zaznaczonego konkretnym commitem. Traktuj to jak infrastrukturę, a nie jako wygodny import.
Zacznij od jednego procesu pracy
Rysowanie wykresów wszystkiego to błąd. Rysuj wykresy tego, co wymaga obrony.
Wybierz jeden proces pracy, w którym błędna decyzja może kosztować prawdziwe pieniądze lub zaufanie. Rejestruj decyzje tylko w tych momentach, gdy wykonywana jest władza, np. przy zatwierdzaniu, odrzucaniu, wydawaniu środków, wysyłaniu treści do produkcji lub przy podejmowaniu zobowiązań wobec klienta. Razem z każdą decyzją przechowuj dowody, na których się opierała, oraz identyfikator reguły, jeśli chodziło o deterministyczną politykę. Zapisuj dane do wykresu asynchronicznie, aby operacje zapisu nigdy nie blokowały ścieżki, na której użytkownik oczekuje.
Po trzydziestu dniach spróbuj odpowiedzieć na prawdziwe pytanie „dlaczego to zrobił?” używając wyłącznie wykresu. Natychmiast pojawią się luki, które nie będą tymi przewidzianymi. To ćwiczenie uczy więcej niż jakikolwiek projekt schematu przeprowadzony z góry.
Co zapamiętać
Minęły dwa lata na poszukiwania wyjaśnialności, co w większości oznaczało próby zajrzenia do wnętrza modelu. Ten cel jest błędny i nie jest realizowany. Model pozostaje probabilistyczny, a żadne sprytne instrukcje nie sprawiają, że jego mechanizmy staną się przyjęte w żadnym istotnym kontekście.
Odpowiedzialność jest osiągalną alternatywą, a każdy jej element znajduje się poza modelem: decyzja, jej przyczyny, dowody, źródło, zastosowana polityka, skutki późniejsze oraz korekty. Wszystko to to zwykłe dane strukturyzowane. Takie zapisy są przechowywane od czasów rachunkowości podwójnej. Ten zwyczaj po prostu zniknął, gdy decydentem stał się model językowy, jakby to zmieniło funkcję zapisu.
Jeśli usunąć język prawniczy, wymóg określony w artykule 12 jest umiarkowany. Nie żąda on większej ilości zapisów. Prosi jedynie o dokumentację, której znaczenie będzie zachowane przez trzy lata – nawet po wycofaniu ram regulacyjnych, dwukrotnym odbudowaniu indeksu oraz odejściu autora zapytania.
Lepszym testem niż ten regulacyjny jest ponowne przyjrzenie się incydentowi o godzinie 3 nad ranem. Nikt nie był winny. Pracownicy wyciągnęli rozsądne wnioski na podstawie dostępnych im informacji, a incydent został zamknięty w jedenastu minutach; jednak wyjaśnienie zniknęło w ciągu kwartału. Jeśli zwykły wtorek może zniszczyć możliwość wyjaśnienia decyzji, audytor nie będzie pierwszym, który to zauważy. Zespół, na spotkaniu kilka miesięcy później, stopniowo uświadomi sobie, że nikt z obecnych nie wie, co się stało.
To, co naprawdę kosztowało Air Canada, to nie 812 dolarów kanadyjskich. Podczas rozprawy nie mieli żadnych wyjaśnień na temat zachowania własnego systemu i polegali na założeniu, że o oprogramowanie odpowiada ktoś inny. Obrona upadła, mimo że chodziło tylko o jeden bilet i jednego smutnego pasażera, który próbował zapisać rozmowę.
Dziś pracownicy szybciej zatwierdzają, wydają, wdrażają i odrzucają decyzje, niż ktokolwiek zdąży to sprawdzić, a nikt nie robi z tego zrzutów ekranu. Najpierw należy sporządzić dokumentację, zanim ktokolwiek o nią poprosi. Pytanie zawsze pojawia się w najgorszym możliwym momencie, a do tego czasu odpowiedź albo jest przechowywana w bazie danych, albo traci się na zawsze.
Literatura pokrewna
- Notatki praktyczne: 10 najpraktyczniejszych umiejętności agentów w 2026 roku (oraz w przyszłych generacjach) — Szczegółowy przewodnik po Notatkach praktycznych: 10 najpraktyczniejszych umiejętności agentów w 2026 roku (oraz w przyszłych generacjach): kontrakty, sprawdzenia oraz miejsca na kod do wstawienia dla zespołów wdrażających ten model.
- Agenci samodoskonalący się dzięki umiejętnościom: ponowne wykorzystanie, selekcja, naprawa i weryfikacja — Czteroczęściowy model dla agentów, które mogą doskonalić swoje umiejętności: przechowywanie działającego kodu, udoskonalanie opisów, proponowanie sprawdzonych poprawek oraz weryfikacja wyników przed przekazaniem zadania.