Pięć warstw narzędzia do zarządzania agentami, wraz z kodem, który bez nich nie działa.
Pięć warstw narzędzia do zarządzania agentami, z których każda zawiera kod, który nie może działać bez niej: granica wykonywania, sandboxing, pamięć, pętle weryfikacji oraz pipeline kontekstowy.
Załóżmy zespół, który dodaje jedną linię do konfiguracji agenta: żadna modyfikacja nie może zostać wprowadzona bez zatwierdzenia przez człowieka. Sformułowanie jest jasne, linia znajduje się blisko góry, a agent ładuje ją na początku każdej sesji.
Następnie przychodzi popołudnie, w którym jedna sesja przekracza tę linię jedenastu razy i wprowadza około siedemdziesięciu sześciu niezatwierdzonych zmian do dokumentu przeznaczonego dla klienta. Nie pojawia się żaden błąd. Nic się nie zatrzymuje, by o to zapytać. Po dwóch godzinach ktoś przegląda dokument, zaznaczając każdą linię, którą agent samodzielnie przepisał, i znajduje czterdzieści sześć takich linii w pliku noszącym nazwę klienta.
Sama instrukcja była w porządku. Tylko znajdowała się w niewłaściwym miejscu.
Zamiast tego sprawdza się „hook” – mały skrypt, który jest wykonywany przez narzędzie tuż przed wysłaniem żądania do narzędzia zewnętrznego. Skanuje ono to żądanie i może odpowiedzieć odmową. Agent nadal może chcieć dokonać edycji, ale zmiana ta nigdy nie trafia do pliku. Taki „hook” czasami może działać błędnie, zwykle dlatego, że zasada została sformułowana zbyt wąsko, a zaletą jest to, że można otworzyć kod i wskazać dokładną warunek, który spowodował błąd. Zdanie w instrukcji nie daje żadnego punktu odniesienia.
Odległość pomiędzy zasadą, którą ogłaszasz, a zasadą, którą egzekwujesz, stanowi „harness”. Obejmuje on pięć obszarów:
- Działania, które może podjąć agent
- Miejsca, do których może dotrzeć
- Stan, który przetrwa restart
- Osoba sprawdzająca jego wyniki
- Koszt tego, co mu jest pokazywane
Każda dziedzina otrzymuje poniższy kod. Istnieje zestaw działających demonstracji, w których każda warstwa zawodzi na twoim własnym laptopie, zanim może to zrobić w środowisku produkcyjnym. Jest to skierowane do osób, które już wdrożyły agenta i widziały, jak działa błędnie.
Co tak naprawdę daje harness
Zacznijmy od czegoś tak oczywistego, że aż trudno to sformułować. Główny pętla agenta do programowania składa się z sześciu linijek:
while agent.turns < max_turns:
call = agent.next_call(observations)
if call is None:
break
result = execute(call)
observations.append(result)
Te linie kodu stanowią agenta. Dzięki obsłudze błędów i próbom ponownym liczba ta może się zbliżyć do dwudziestu. Niezależnie od wybranego frameworku, on otacza tę pętlę, a najważniejszą częścią jest funkcja execute. To właśnie ta funkcja określa, co model może robić, na co może mieć dostęp, co zachowuje, kto go audytuje oraz co trafia do jego obszaru działania.
Wszystkie te decyzje razem tworzą „uprząż” sterującą działaniem modelu, a wiele komentarzy twierdzi, że ma ona większe znaczenie niż sam wybór modelu. Dane potwierdzają bardziej ograniczone stwierdzenie, które okazuje się praktyczniejsze.
Układ jest lepszy pod względem kosztu. Przedruk z czerwca 2026 roku porównał trzy układy (Goose, OpenCode, OpenHands-SDK) w dwóch modelach, wykorzystując stratyfikowaną próbę 50 zadań z Terminal-Bench Pro, trudniejszej wersji zestawu agentów Terminal-Bench. Użycie tokenów na rozwiązane zadanie różniło się między układami aż 40 razy. Przejście na lepszy model zmieniło to wartości zaledwie o 1,0 do 1,3 raza.
Nie jest lepszy pod względem możliwości. Wskaźniki skuteczności różniły się między układami od 0 do 8 punktów, a przy przedziałach ufności bootstrapowej wszystko oprócz największej różnicy mieściło się wokół zera. Sami autorzy określają wyniki dokładności jako opisowe, biorąc pod uwagę n=50.
Mówiąc prościej, jedno zadanie w jednym modelu o określonym stopniu skuteczności może kosztować czterdzieści razy więcej przy użyciu jednego narzędzia niż innego. Wszystko, co następuje, pomaga obniżyć koszty i zmniejszyć niespodzianki, a nic z tego nie dodaje inteligencji słabemu modelowi.
Przeniesienie reguły do kodu
Określenie reguły w instrukcji systemowej to w istocie zakład, że model ją przypomni sobie, zinterpretuje zgodnie z intencją i będzie się nią kierować, gdy kontekst stanie się zbyt złożony. Zazwyczaj model wygrywa. To właśnie ten stopień skuteczności sprawia, że sytuacja jest ryzykowna, ponieważ ludzie przestają wtedy sprawdzać.
Reguły na poziomie kodu są uruchamiane przy każdym wezwaniu, nawet wtedy, gdy model stracił z nimi kontakt.
Pętla agenta składa się z pięciu miejsc, w których kod może przejąć kontrolę. Każdy z poniższych rozdziałów opisuje jego przeznaczenie, kod realizujący dane zadanie oraz zachowanie w przypadku braku danej warstwy. Nikt nie potrzebuje wszystkich pięciu naraz. Wybierz warstwę, której awaria najłatwiej możesz sobie wyobrazić w tym tygodniu.
Warstwa 1: granica wykonywania
Cóż jest agentowi dozwolone robić?
Granica ta stanowi funkcję umieszczoną pomiędzy wyborem modelu a faktycznym wywołaniem narzędzia. Zacznijmy od agenta bez żadnych zabezpieczeń. Jego instrukcje mówią, aby nigdy nie usuwać pliku bez uprzedzenia, a w kolejce czekają trzy wywołania narzędzi.
SYSTEM_PROMPT = "IMPORTANT: never delete a file without asking the user first."
def execute(call):
if call.name == "delete_file":
FILES.pop(call.args["path"], None)
return f"deleted {call.args['path']}"
Podczas jego uruchomienia agent usuwa cache.tmp, bezpieczne śmieci, a następnie client-deliverable.md, co dokładnie odpowiada jego nazwie. Nie zadało się żadnego pytania, mimo że w instrukcji od samego początku znajdowało się to zasada.
Funkcja umieszczona przed narzędziem rozwiązuje ten problem:
def boundary(rules):
def wrap(execute):
def guarded(call):
for name, deny_if, reason in rules:
if deny_if(call):
return f"DENIED by {name}: {reason}"
return execute(call)
return guarded
return wrap
NEEDS_APPROVAL = [(
"delete-needs-approval",
lambda c: c.name == "delete_file" and not c.args.get("approved_by_human"),
"deletion requires an explicit human approval flag on the call",
)]
Z tym samym agentem, skryptem i poleceniem nic nie jest usuwane.
Warstwa 2: sandboxing
Do czego może dotrzeć agent?
Sandbox określa, które katalogi i hosty proces agenta może w ogóle dotknąć. Należy go stworzyć od zera: zaczynając od niczego i przyznając tylko to, co jest potrzebne do wykonywania zadań, poprzez listę dozwolonych ścieżek, listę dozwolonych hostów oraz proces nieświadomy wszystkiego innego.
Powszechną alternatywą jest lista zakazanych ścieżek:
DENY = ["secrets/"]
def execute(call):
path = call.args["path"]
if any(path.startswith(d) for d in DENY): # checks the spelling
return "DENIED by deny-list"
real = os.path.normpath(path) # the ../ collapses HERE, after the check
return DISK.get(real, "not found")
Uruchom to, a agent spróbuje dwa razy:
read('secrets/api_key') -> DENIED by deny-list
read('work/../secrets/api_key') -> sk-live-DO-NOT-LEAK
Weryfikacja sprawdzała tekst tak, jak został wpisany, natomiast wyszukiwanie w plikach odnosiło się do lokalizacji, do której tekst odsyła. Dwie prośby, dwa sposoby zapisu, jeden plik.
Naprawa polega na najpierw ustandaryzowaniu ścieżki, a następnie porównaniu jej:
ALLOW_ROOTS = ["work"]
def resolve(path):
real = os.path.normpath(path) # resolve FIRST
if not any(real == r or real.startswith(r + os.sep) for r in ALLOW_ROOTS):
return None
return real
Oba sposoby zapisu sprowadzają się teraz do secrets/api_key, który znajduje się poza żadnym dozwolonym katalogiem głównym, więc oba są odrzucane. Tutaj kluczowe jest zezwolenie zamiast odrzucenia, ponieważ lista odrzuceń blokuje jedynie te formy zapisu, które przewidział jej twórca.
Te przykłady to zwykłe funkcje w Pythonie, więc nie potrzeba żadnego kontenera, aby je przetestować. W rzeczywistym wdrożeniu identyczna kontrola polega na samej granicy procesu: użytkownik lub kontener, który nie ma uprawnień do odczytu poza katalogiem work/, stosuje tę samą kolejność operacji.
Szara warstwa nie może wykonać tej czynności. Kontrola umieszczona wewnątrz programu widzi tylko te wywołania, które rozpoznaje, podczas gdy polecenie w wierszu poleceń, symlink lub ścieżka zawierająca .. mogą dotrzeć do tego samego pliku bez bycia żadnym z tych wywołań.
Warstwa 3: trwałość pamięci
Co pozostaje po sformatowaniu kontekstu?
Jedno nawyku przynosi większe korzyści niż większość innych: zaniechanie rozmowy bez chwili zastanowienia. Kontekst się wypełnia, jakość spada, a agent zaczyna być sprzeczny sam ze sobą. Wielu ludzi nadal kontynuuje takie sesje. Lepiej je wcześnie restartować, pod warunkiem, że wszystko ważne zostanie zapisane w miejscu, którego restart nie może usunąć – czy to skompilowany kod, konfiguracja, sam framework czy streszczone notatki.
Dlatego celowo zdecyduj, gdzie powinien znajdować się każdy element stanu. Istnieją trzy opcje: rozmowa, gdzie znika wraz z sesją; dysk, gdzie pozostaje i może zostać później odzyskany; oraz konfiguracja frameworka, która wpływa na każdą kolejną sesję.
Jedna funkcja dyspozycyjna obejmuje wszystkie trzy przypadki:
CONVERSATION, DISK, HARNESS_CONFIG = [], {}, {}
def remember(kind, key, value):
"""'chat' dies with the session, 'disk' survives it,
'config' shapes every session that follows."""
{"chat": lambda: CONVERSATION.append(value),
"disk": lambda: DISK.__setitem__(key, value),
"config": lambda: HARNESS_CONFIG.__setitem__(key, value)}[kind]()
Funkcja ta praktycznie nic nie robi. Daje jedynie zasadę, zgodnie z którą nic nie może zostać zapisane bez określenia, do których z trzech miejsc ma trafić. Zespoły rzadko dokonują tego wyboru w sposób wyraźny, co tłumaczy, dlaczego agenci wydają się zapominać o niektórych rzeczach, a inaczej uparcie się mylić. W demonstracji lista rozmów wraca pusta, podczas gdy decyzja i zasada pozostają na dysku oraz w konfiguracji.
Warstwa 4: pętle weryfikacyjne
Kto sprawdza wyniki, a co powstrzymuje osobę sprawdzającą przed prostym naprawieniem problemów?
Pętla weryfikacyjna oznacza drugie przejrzenie pracy agenta, przeprowadzone przez coś, co ma prawo zaznaczać problemy, ale nie naprawiać ich.
Druga połowa to to, co ludzie pomijają. Niech podagent recenzenta napisa kod, a on cicho naprawi wszystko, co znajdzie. Wydaje się to efektywne, ale jednocześnie usuwa informacje, których chciałeś: nie możesz już odróżnić poprawnej pracy od tej błędnej, która została naprawiona bez twojej wiedzy.
Dlatego utrzymuj recenzenta w trybie tylko odczytu. Tworzy on ocenę, a działanie na podstawie tej oceny to kolejny krok z własnym śladem. Trzymanie ich oddzielnie pozwala zachować sygnał, który możesz odczytać.
Drugą taktyką jest próba bezpieczna. Przed jakimkolwiek nieodwracalnym działaniem narzędzie przyjmuje flagę, domyślnie opisuje, co by zrobiło, i działa tylko wtedy, gdy ktoś celowo wyłączy tę flagę. Domyślnym zachowaniem jest bezpieczne działanie, więc przeoczenie nic nie kosztuje. W demonstracji narzędzie naprawcze ogłasza, że przepisze plik total.py, nic nie zapisuje, a błąd „off-by-one” pozostaje do końca.
Jedna instrukcja execute zawiera obie zasady:
def execute(call):
if call.name == "review":
snapshot = dict(CODE) # a copy, so the reviewer cannot write
src = snapshot[call.args["path"]]
return f"VERDICT: {'off-by-one' if '+ 1' in src else 'looks good'}"
if call.name == "apply_fix":
if call.args.get("dry_run", True): # on by default, turned off on purpose
return f"DRY RUN: would rewrite {call.args['path']}, nothing written"
CODE[call.args["path"]] = call.args["new"]
return f"wrote {call.args['path']}"
Recenzent zauważa błąd typu „off-by-one”, ale nie ma możliwości go poprawienia.
Warstwa 5: pipeline kontekstowe
Co trafia do modelu i za co jest to opłacane?
Pipeline kontekstowy opisuje, w jaki sposób informacje trafiają do okna modelu oraz ile z nich jest dopuszczanych.
To właśnie tutaj przepływają pieniądze – za każdy token, który trafia do modelu, płaci się w danym kroku oraz ponownie we wszystkich kolejnych krokach, dlatego to tutaj pojawia się czterdziestokrotna różnica w kosztach, a nie w Warstwie 1.
Naiwna konfiguracja ładuje wszystko: cały plik z pytaniem dotyczącym jednej funkcji, pełne wyniki wyszukiwania dla prostej potrzeby oraz całą historię. To funkcjonuje, ale już po dwudziestym kroku ponownie płaci się za to, co zostało przeczytane w krokach od pierwszego do dziewiętnastego.
Rozwiązanie polega na delegowaniu zadań oraz ich przefiltrowaniu. Podagent działa w oddzielnym oknie, przetwarza dziesiątki tysięcy tokenów i przekazuje z powrotem jedno lub dwa tysiące. Główny wątek pomija surowe wyniki wyszukiwania i otrzymuje tylko odpowiedź.
W kodzie chodzi o to, który licznik się zwiększa:
def subagent_search(query):
"""Its own window. The main thread never pays for this reading."""
global subagent_tokens
subagent_tokens += sum(len(v.split()) for v in CORPUS.values())
return next(f"{n}: {b.split('ANSWER:')[1].strip()}"
for n, b in CORPUS.items() if "ANSWER:" in b)
def execute(call):
global main_tokens
distilled = subagent_search(call.args["q"])
main_tokens += len(distilled.split()) # the only line that bills you
return distilled
Demonstracja jest celowo mała i szczera. Pytanie i odpowiedź są identyczne w obu próbach, a mimo to główny wątek przetwarza 9 602 tokeny w jednej z nich i 2 w drugiej.
To również wyjaśnia, dlaczego łańcuchowe podagenty zawodzą. Gdy każdy krok czeka na poprzedni, powstaje izolacja kontekstowa i w ogóle nie ma żadnego przyspieszenia dzięki równoległemu działaniu. Prawdziwie niezależne kroki powinny działać równocześnie. W przeciwnym razie trzeba zaakceptować, że to właśnie izolację się kupuje. Często usprawiedliwia to cenę, o ile wie się, co obejmuje faktura.
Czego nikt jeszcze nie może powiedzieć
Publiczne zaufanie w tej kwestii wyprzedziło dostępne dowody, dlatego zastrzeżenia są istotne.
- Nic tutaj nie przeszło recenzji przez ekspertów. Od sierpnia 2026 roku każde badanie dotyczące tego rozwiązania to jedynie preprint na arXiv, który nie podlegał recenzji. Najdokładniejszy z eksperymentów określa się jako wstępne badanie poddane ocenie na warsztacie, a najsłynniejszy z artykułów opisowych przedstawia się jako dokument stanowiskowy, który nie zawiera żadnego własnego eksperymentu. Traktuj wszystko to, włączając ten tekst, jako materiał nieprzeczytany przez recenzentów i powtórz porównanie w swoich zadaniach przed planowaniem budżetu na jego podstawie.
- Zyski rzadko przenoszą się na zadania niewidziane wcześniej. Artykuł z lipca 2026 roku stwierdził, że automatyczna ewolucja narzędzi nie jest w stanie w sposób niezawodny przewyższyć tradycyjnego skalowania w czasie testowania oraz słabo generalizuje, ponieważ zarówno proces poszukiwań, jak i ostateczny test opierają się na tym samym punkcie odniesienia. W ocenie uczenia się ciągłego na Terminal-Bench 2.0 wskaźnik GEPA wzrósł do 70,8% na zadaniach, do których był dostosowywany, a następnie spadł do 54,5% w szerszym zestawie, co jest wartością niższą od początkowego poziomu 56,8%. Dostosowywanie w rzeczywistości szkodziło. Przetestuj każde narzędzie na zadaniach, których nie użyto do jego budowy, ponieważ ulepszenia widoczne tylko na zestawie do dostosowywania znikają w warunkach rzeczywistych.
- Dobrze znany sukces w drobnej optymalizacji modelu oceniany jest na podstawie jego własnego sygnału treningowego. Na przykład model Gemma 3 27B, dostosowany do pisania notatek klinicznych, poprawił swoje wyniki z 35% poniżej Claude Sonnet 4 do 60% powyżej. W opisie otwarcie stwierdza się, że narzędzie oceny pełniło jednocześnie rolę nagrody w procesie treningu. To ważna metoda, ale ocena pochodzi od tego samego elementu, który służył do nauki. Gdy dostawca twierdzi o korzyściach wynikających z drobnej optymalizacji, należy zapytać, jakie narzędzie oceny było używane podczas treningu; jeśli jest to to samo narzędzie, liczba ta wskazuje, że model nauczył się właśnie tego narzędzia oceny.
- Pas nie przenosi się sprawnie między różnymi modelami. Badanie przeprowadzone w czerwcu 2026 roku wykazało, że dodanie pasa po szkoleniu przywraca jedynie niewielką część korzyści wynikających ze szkolenia z jego użyciem. Modele szkolone z użyciem minimalnego pasa dawały błąd „Nieprawidłowy format narzędzia” w 75,1% prób po zmianie definicji narzędzi, a wersja Qwen2.5-7B osiągnęła o 10,8 punktu gorszy wynik niż jej bazowy model. Pas pasujący do każdego modelu pasuje do każdego z nich nieco gorzej. Wybierz pas przed szkoleniem, a jeśli nie szkolisz własnego modelu, spodziewaj się, że wymiana pasa w trakcie projektu będzie droższa, niż się wydaje przy migracji.
- Terminologia nie jest ustalona. W maju 2026 roku Hugging Face opublikował glosariusz, w którym rozróżnia się pojęcia „harness” i „scaffold”, przyznając jednocześnie, że Claude Code, Codex oraz inne narzędzia i tak używają terminu „harness” na określenie całego stacku. Pięć warstw to zaledwie jeden sposób ich podziału. Zgodnie z węższą definicją, około połowa powyższych dowodów odnosi się do czegoś innego. Wybierz słownictwo, trzymaj się go w swoim zespole i uważnie czytaj porównania różnych badań. Z tego powodu pięć warstw najlepiej sprawdza się jako lista kontrolna dla własnej konfiguracji, ponieważ lista kontrolna przetrwa zmiany słownictwa, natomiast taksonomia z nimi walczy. Zanim zaufasz różnicy pomiędzy wynikami dwóch agentów, sprawdź, które warstwy każdy z nich obejmuje.
- Wydaje się, że efekty wykorzystania narzędzi słabną w miarę udoskonalania się modeli. Harness-Bench pokazuje, że silniejsze backendy modeli osiągają wyższe średnie wyniki oraz wykazują mniejszą zmienność pomiędzy różnymi narzędziami. Część tych elementów może jedynie maskować słabość, która stopniowo znika. Skup się przy inwestowaniu w takie narzędzia na kontrolowaniu kosztów, co przynosi trwałe efekty, a nie na dokładności, którą nowsze wersje modeli mogą zapewnić bez dodatkowych kosztów.
Skrypty towarzyszące
Do tej koncepcji dołączone są dziesięć krótkich skryptów. Każda warstwa jest testowana z odpowiednim zabezpieczeniem, a ten sam agent – bez niego. Skrypty działają offline, bez potrzeby klucza API, ponieważ zastępują one model i wykonywają określoną serię wywołań narzędzi. Zobaczenie różnicy w wynikach jest lepsze niż poleganie wyłącznie na zaufaniu.
git clone https://github.com/paoloap-py/agent-harness-guide
cd agent-harness-guide
python3 run_all.py # all five layers, guard off then on, side by side
python3 test_harness.py # asserts every difference above, 10 checks
README przedstawia te pięć warstw jako listę kontrolną audytu z jednym powtarzającym się pytaniem: czy kod to wymusza, czy zdanie w instrukcji? Każda pozycja, której nie można zaznaczyć poprzez wskazanie ścieżki pliku, to zasada, której istnienia możesz jedynie mieć nadzieję.
Gdzie to ma zastosowanie
Poprawna zasada umieszczona w niewłaściwym miejscu prawie nie ma znaczenia. W opisanym powyżej scenariuszu doprowadziła to do piętnastu naruszeń, z których jedenaście miało miejsce w ciągu jednego popołudnia, oraz do dnia, którego nikt nie chce odzyskać. To przeniesienie zasady sprawiło, że stała się skuteczna, przy czym ani jedno słowo z niej się nie zmieniło.
To jest sedno sprawy. Model to coś, co kupujesz. Wszystko wokół niego to coś, co budujesz, a to właśnie to połowiczne podejście decyduje o koszcie agenta oraz o tym, jak często wykonuje czynności, których nigdy nie zatwierdziłeś. Oba aspekty należą do inżynierii, ale tylko drugi możesz kształtować według swoich potrzeb.
FAQ
Czym dokładnie jest „harness” dla agenta? Wszystko to, co otacza model: pętla narzędziowa, sprawdzenia przed wykonywaniem, środowisko sandbox, przechowywanie stanu między sesjami, osoba sprawdzająca oraz proces decydujący o treści każdej rundy. Pętla składa się z sześciu linijek, a z obsługą błędów – z dwudziestu, a wszystko inne należy do „harnessa”.
Czy „harness” jest ważniejszy od modelu? Pod względem kosztów – tak, ponieważ zużycie tokenów na rozwiązane zadanie może się różnić aż 40-krotnie. Jeśli chodzi o to, czy zadania zostaną rozwiązane – nie. Zmiany w stopie sukcesu między różnymi „harnessami” wynoszą od 0 do 8 punktów, przy czym występują interwały przekraczające wartość zero, a autorzy Terminal-Bench doszli do wniosku, że wybór modelu zazwyczaj ma większe znaczenie dla wydajności.
Gdzie uprząż kosztuje najwięcej? W kontekście. Każdy token pokazywany modelowi na każdym kroku jest opłacany za każdy taki krok. Dlatego warstwa 5 jest najdroższa i to wyjaśnia, dlaczego przekazanie zadań poszczególnym agentom zmienia koszt, nie zmieniając przy tym odpowiedzi.
Czy zasady upoważnień liczą się jako element bezpieczeństwa?
Nie. Sprawdzenie uprzążą obejmuje jedynie wywołanie, które agent faktycznie wykonał, podczas gdy polecenie w shellu, symlink lub ścieżka .. mogą dotrzeć do tego samego pliku bez żadnej kontroli. Prawdziwe ograniczenia pochodzą od systemu operacyjnego: proces powinien być uruchamiany bez żadnego dostępu, a następnie dodawane powinny być tylko te uprawnienia, których potrzebuje dane zadanie.
Czy stworzyć własną uprząż, czy przyjąć gotową? Lepiej przyjąć gotową i pozostać przy niej. Przejście na inną uprząż usuwa zgromadzoną w plikach konfiguracyjnych wiedzę, a każda zasada dodana po prawdziwym błędzie musi być ponownie zdobywana.
Literatura pokrewna
- Agenty doskonalące się dzięki umiejętnościom: ponowne wykorzystanie, selekcja, naprawa i weryfikacja — Czteroczęściowy model agentów, które poprawiają własne umiejętności: przechowywanie działającego kodu, udoskonalanie opisów, proponowanie sprawdzonych poprawek oraz weryfikacja wyników przed przekazaniem.
- Harness do użycia produkcyjnego dla Claude Code: sześć warstw od Slack do połączonego kodu — Jak sześciowarstwowy harness przekształca zgłoszenia z Slack w połączony kod: przyjmowanie zdarzeń, pętle agentów z kontrolą dostępu, trwały stan, samonaprawa, możliwości obserwacji oraz kontrola przez operatora.