Degradacja pamięci agentów AI: dlaczego wieloturowe LLM ulegają załamaniu
Dziewięćdziesiąt minut po rozpoczęciu budowy mojego systemu deliberacji agent przestał odwoływać się do architektury, którą omawiał trzydzieści minut wcześniej. Logi sesji wykazały, że Claude skompresował graf zależności modułów, aby zrobić miejsce na nowe wyniki narzędzi. Agent kontynuował pisanie kodu, ale kod ten nie odzwierciedlał już kontraktów międzymodułowych ustalonych w pierwszej godzinie. Testy jednostkowe przechodziły. Integracja kończyła się błędem. Agent zapomniał własny projekt.
Ta awaria kosztowała mnie cały dzień debugowania. Badania naukowe wyjaśniają teraz, dlaczego do niej doszło.
TL;DR
Microsoft Research i Salesforce przetestowali 15 LLM w ponad 200 000 symulowanych konwersacji i odnotowali średni spadek wydajności o 39% przy przejściu z interakcji jednoturowej na wieloturową.1 Degradacja rozpoczyna się już po dwóch turach. Trzy niezależne mechanizmy napędzają załamanie: kompresja kontekstu odrzuca kluczowy stan, spójność rozumowania fragmentuje się w miarę kurczenia się budżetu tokenów, a koordynacja między agentami rozpada się bez wspólnego źródła prawdy. Dłuższe okna kontekstu nie rozwiązują żadnego z tych problemów. Wzorzec pętli Ralph (świeży kontekst na iterację z utrwalaniem stanu w systemie plików) omija straty kompresji, ale wprowadza własne koszty. Poniżej: badania, trzy mechanizmy, metody detekcji możliwe do wdrożenia już dziś oraz protokół odporności wieloturowej.
Klif 90. minuty
Mój wpis o kontekście jako architekturze dokumentował siedmiowarstwowy system kontekstu obejmujący 650 plików. Budowa tego systemu wymagała rozciągniętych sesji kodowania, w których agent musiał utrzymywać złożony stan architektoniczny: granice modułów, łańcuchy zależności, kolejność wykonywania hooków i kontrakty międzyplikowe.
Zmierzyłem jakość sesji w 30 iteracjach pętli Ralph w styczniu i lutym 2026 roku. Dane wykazały spójny wzorzec:
Minutes 0-30: Precise multi-file edits, correct cross-references
Minutes 30-60: Occasional missed imports, still recoverable
Minutes 60-90: Single-file tunnel vision, loses architectural context
Minutes 90+: Repetitive attempts, contradicts earlier decisions
Klif jakości pojawiał się niezależnie od rodzaju zadania. Długie sesje refaktoryzacji, budowania zestawów testów i dokumentacji — wszystkie degradowały się na tej samej krzywej. Różniła się jedynie dotkliwość: zadania wymagające większego stanu międzyplikowego uderzały w klif mocniej niż izolowana praca nad pojedynczym plikiem.
Przypisałem ten wzorzec presji okna kontekstu i zbudowałem pętlę Ralph jako obejście. Nowa instancja Claude na każdą iterację; stan wstrzykiwany z systemu plików; żadnego polegania na pamięci konwersacyjnej ponad jedną iterację. Wzorzec działa. Jednak badanie MSR/Salesforce opublikowane w maju 2025 ujawniło, że problem jest bardziej strukturalny, niż sugerowałby sam rozmiar okna kontekstu.
Trzy mechanizmy załamania wieloturowego
Laban i in. rozłożyli degradację wieloturową na niezależne mechanizmy — rozróżnienie to ma znaczenie, ponieważ każdy wymaga strukturalnie odmiennej interwencji.1
Mechanizm 1: kompresja kontekstu
Każda konwersacja z AI operuje w ramach skończonego budżetu tokenów. W miarę rozrastania się konwersacji system kompresuje wcześniejsze tury, by zrobić miejsce na nową treść. Kompresja jest stratna. Decyzje architektoniczne udokumentowane w turze 3 mogą nie przetrwać do tury 15.
Złapałem to bezpośrednio podczas budowy systemu deliberacji. Agent ustalił graf zależności modułów w pierwszych 20 minutach: deliberation_engine.py zależy od consensus_calculator.py, który zależy od vote_aggregator.py. W 75. minucie agent skompresował łańcuch zależności i napisał cykliczny import. Kod był poprawny składniowo. Import cykliczny wywołał błąd w czasie wykonania.
Detekcja: Warto śledzić stosunek odwołań międzyplikowych w wynikach agenta w czasie. Gdy agent przestaje odwoływać się do plików omawianych wcześniej, kompresja prawdopodobnie odrzuciła odpowiedni kontekst.
# Count unique file references per 30-min window in a session log
# Declining count signals compression loss
git log --since="2 hours ago" --pretty=format:"%s" | \
grep -oP '[a-z_]+\.(py|js|ts)' | sort -u | wc -l
Mechanizm 2: utrata spójności rozumowania
Badanie MSR/Salesforce wykazało, że degradacja wieloturowa rozkłada się na dwa składniki: niewielką utratę zdolności i znaczący wzrost niestabilności.1 Zdolność mierzy, czy model w ogóle potrafi wyprodukować poprawną odpowiedź. Niezawodność mierzy, czy robi to konsekwentnie.
W trybie jednoturowym modele osiągały około 90% średniej wydajności w sześciu zadaniach generatywnych. W trybie wieloturowym wydajność spadała do około 65% — bezwzględny spadek o 25 punktów. Kluczowe odkrycie: „Gdy LLM zboczą na złą ścieżkę w konwersacji wieloturowej, gubią się i nie wracają na właściwy tor”.1
Utrata spójności rozumowania przejawia się tym, że agent zaprzecza własnym wcześniejszym decyzjom. Nie dlatego, że system skompresował kontekst (mechanizm 1), lecz dlatego, że łańcuch rozumowania modelu fragmentuje się między turami. Rozumowanie w każdej turze jest lokalnie poprawne, ale globalnie niespójne.
Praca Du i in. nad kognitywnym routingiem decyzji adresuje bezpośrednio ten mechanizm.2 Inspirowani teorią podwójnego procesu Kahnemana (szybkie intuicyjne reakcje kontra powolne, świadome rozumowanie), ich system dostosowuje głębokość rozumowania do wymagań zadania. Kluczowy wniosek: nie każda tura agenta wymaga tej samej głębokości rozumowania, a jednolita głębokość marnuje budżet na trywialne kroki, niedoinwestowując kluczowe decyzje.
Detekcja: Należy szukać sprzeczności między wczesnymi a późnymi wynikami sesji. Jeśli agent proponuje podejście A w 15. minucie, a podejście B w 60. minucie bez potwierdzenia zmiany — spójność uległa degradacji.
Mechanizm 3: awaria koordynacji
Systemy wieloagentowe potęgują degradację wieloturową o awarie koordynacji. Gdy dwa lub więcej agentów współpracuje nad zadaniem, kontekst każdego agenta degraduje się niezależnie. Agent, który zapomniał o wspólnym ograniczeniu, nie jest w stanie koordynować się wokół niego.
Bhardwaj i in. w Agent Context Protocols adresują to zagadnienie, ustanawiając ustrukturyzowane kanały komunikacji między agentami.3 Ich framework osiągnął 28,3% dokładności na AssistantBench dzięki zdefiniowaniu jawnych protokołów wymiany kontekstu, propagacji błędów i synchronizacji stanu. Unified Agent Communication Protocol Krishnana rozszerza to podejście o granice bezpieczeństwa zero-trust między agentami.4
Napotkałem awarię koordynacji podczas 10-agentowej deliberacji, w której trzech recenzentów oceniało tę samą zmianę w kodzie. W czwartej rundzie recenzji agenci rozbieżnie postrzegali „bieżącą wersję” kodu. Kontekst każdego agenta zawierał inny snapshot. Ich recenzje sobie zaprzeczały — nie dlatego, że się nie zgadzali, lecz dlatego, że recenzowali różny kod.
Detekcja: W przepływach wieloagentowych warto porównywać założenia dotyczące stanu, które posiada każdy agent. Jeśli agenci odwołują się do różnych wersji tego samego artefaktu, koordynacja zawiodła.
Dlaczego dłuższe okna kontekstu tego nie naprawiają
Intuicyjna reakcja na degradację wieloturową brzmi „dajmy modelowi więcej tokenów”. Badanie MSR/Salesforce obala tę intuicję za pomocą pomysłowego eksperymentu.
Przetestowali warunek „Concat”: prezentacja pełnej wieloturowej konwersacji jako jednego sklejonego promptu. Warunek Concat osiągnął 95,1% wydajności trybu jednoturowego.1 Długość kontekstu była identyczna jak w warunku wieloturowym. Zawartość informacyjna była identyczna. Jedyną różnicą była struktura interakcji: jedna tura zamiast wielu.
Degradacja o 39% nie jest problemem długości kontekstu. Podwojenie okna kontekstu z 200K do 400K tokenów nie wyeliminowałoby degradacji, ponieważ jej źródłem są same granice tur, a nie brak miejsca.
Wyniki Concat pokrywają się z moimi danymi produkcyjnymi. Claude operuje z mniej więcej 200 000 tokenów kontekstu. Moje pomiary zarządzania oknem kontekstu wykazały, że najdłuższe jednosesyjne przebiegi (3+ godziny, intensywne korzystanie z narzędzi) zużywają około 180 000 tokenów przed uruchomieniem kompakcji. Jednak jakość degraduje się na długo przed zapełnieniem okna. Klif 90. minuty pojawia się przy około 60–70% wykorzystania kontekstu, nie na granicy. Powstały w ten sposób dług kognitywny kumuluje się, ponieważ agent produkuje kod szybciej, niż programista jest w stanie go zweryfikować. To ten sam problem kontekstu złożonego w innej skali: każda tura dodaje informację, która oddziałuje nieliniowo z tym, co było wcześniej.
Kognitywny routing decyzji Du i in. przeformułowuje problem: kluczowe nie jest to, ile tokenów model jest w stanie utrzymać, ale jak efektywnie alokuje zasoby rozumowania w ramach tych tokenów.2 Ich system osiągnął 34% redukcję kosztów obliczeniowych przy 23% wzroście spójności — dzięki kierowaniu prostych decyzji przez szybkie rozumowanie, a złożonych przez rozumowanie świadome.
Rozwiązanie ze świeżym kontekstem (i jego koszty)
Pętla Ralph rozwiązuje mechanizm 1 (kompresja) i częściowo mechanizm 2 (spójność), nie pozwalając konwersacji trwać wystarczająco długo, by którykolwiek się ujawnił. Każda iteracja uruchamia świeżą instancję Claude z pełnym 200K-tokenowym kontekstem. Stan utrwala się w systemie plików, nie w pamięci konwersacyjnej.
# Simplified Ralph loop iteration (from jiro-artisan.sh)
while [ "$stories_remaining" -gt 0 ]; do
# Orient: inject current state from filesystem
state=$(cat jiro.state.json)
progress=$(cat jiro.progress.json)
git_state=$(git diff --stat HEAD)
# Spawn fresh context with injected state
claude --print \
"State: $state" \
"Progress: $progress" \
"Git: $git_state" \
"Task: implement next story from prd.json"
# Update filesystem state from agent output
update_state_from_output
done
Każda iteracja otrzymuje pełny budżet kontekstu. Żadnych artefaktów kompresji z poprzednich tur. Żadnych fragmentów spójności z wcześniejszych łańcuchów rozumowania. System plików służy jako pamięć zewnętrzna agenta: jiro.state.json śledzi bieżącą historię, jiro.progress.json rejestruje ukończoną pracę między iteracjami, a git diff dostarcza źródło prawdy o tym, co faktycznie się zmieniło.
Recursive Language Models Zhanga, Kraski i Khattaba przyjmują komplementarne podejście: zamiast uruchamiać świeże instancje, model przenosi kontekst do środowiska Python REPL i rozumuje nad kontekstem w kodzie, a nie w przestrzeni tokenów.5 RLM-Qwen3-8B przewyższył swoją bazową wersję o 28,3% na zadaniach wymagających długiego kontekstu — traktując długie prompty jako zewnętrzne struktury danych, a nie pamięć wewnętrzną. Podczas gdy pętla Ralph eksternalizuje stan do plików, RLM eksternalizują stan do kodu. Oba wzorce rozwiązują ten sam problem kompresji za pomocą różnych mechanizmów.
System Wink Nandy i in. adresuje sytuację, gdy degradacja już trwa.6 Analizując ponad 10 000 rzeczywistych trajektorii agentów, stwierdzili, że niepożądane zachowania (dryf specyfikacji, powtarzające się pętle, błędy wywołań narzędzi) występują w około 30% wszystkich sesji. Wink obserwuje trajektorię agenta i dostarcza ukierunkowaną korektę kursu, rozwiązując 90% przypadków wymagających jednorazowej interwencji. Detekcja odbywa się w czasie rzeczywistym: Wink identyfikuje wzorce degradacji w momencie ich pojawienia się, zamiast czekać, aż awaria rozpropaguje się przez bazę kodu.
Koszty
Iteracja ze świeżym kontekstem nie jest darmowa. Trzy koszty:
1. Narzut orientacji. Każda iteracja wydaje tokeny na ponowne czytanie stanu, który poprzednia iteracja już rozumiała. Moje pomiary wskazują, że 15–20% budżetu tokenów każdej iteracji pochłania krok orientacji: czytanie plików stanu, skanowanie najnowszej historii git, odbudowa wystarczającego kontekstu do kontynuacji. Iteracja o budżecie 200K tokenów startuje z około 160–170K tokenów użytecznej pojemności.
2. Utrata wiedzy ukrytej. Kontekst konwersacyjny niesie wiedzę ukrytą, której stan w systemie plików nie jest w stanie uchwycić: uzasadnienie decyzji projektowej, rozważone i odrzucone alternatywy, niuanse tego, dlaczego podejście A wybrano nad podejściem B. Krok orientacji wstrzykuje fakty (co się zmieniło, co dalej). Rozumowanie (dlaczego) paruje między iteracjami.
3. Koszt koordynacji. Jeśli wiele pętli Ralph działa równolegle (implementacja równoległych historii), każda pętla utrzymuje niezależny stan. Koordynacja między pętlami wymaga jawnej logiki scalania i rozwiązywania konfliktów, którą pojedyncza długa sesja obsługuje niejawnie.
Kalkulacja kosztów i korzyści jest jednoznaczna: dla sesji poniżej 60 minut pojedyncza konwersacja jest wydajniejsza. Powyżej 90 minut wzorzec świeżego kontekstu daje wyższą jakość mimo narzutu orientacji. Punkt przejścia zależy od złożoności zadania: wysoki stan międzyplikowy przesuwa go wcześniej; izolowana praca nad jednym plikiem — później.
Wykrywanie degradacji zanim uderzy
Nie trzeba czekać na awarię produkcyjną, by wykryć degradację wieloturową. Trzy metody — od najprostszej do najbardziej dokładnej:
Metoda 1: monitorowanie presji kontekstu
Śledzenie wykorzystania kontekstu w czasie rzeczywistym. Mój hook context-pressure.sh uruchamia się po każdym wywołaniu narzędzia i ostrzega, gdy wykorzystanie przekracza 60%:
# Simplified context pressure check
context_used=$(wc -c < "$CONVERSATION_LOG" | awk '{print int($1/4)}')
context_max=200000
utilization=$(( context_used * 100 / context_max ))
if [ "$utilization" -gt 60 ]; then
echo "[WARN] Context at ${utilization}% — quality degradation likely"
fi
if [ "$utilization" -gt 80 ]; then
echo "[CRITICAL] Context at ${utilization}% — start new session"
fi
Metoda 2: śledzenie odwołań krzyżowych
Monitorowanie, ile odrębnych plików agent wymienia na wyjściu. Malejący trend sygnalizuje utratę kompresji:
# Track file reference diversity in recent commits
for commit in $(git log --oneline -5 --format="%H"); do
files=$(git diff-tree --no-commit-id --name-only -r "$commit" | wc -l)
echo "$commit: $files files touched"
done
Metoda 3: detekcja sprzeczności
Porównywanie deklaracji architektonicznych agenta w czasie. Jeśli agent twierdzi „moduł A zależy od modułu B” w 20. minucie, a „moduł A nie ma zewnętrznych zależności” w 70. minucie — spójność uległa degradacji. Wersja zautomatyzowana: porównanie instrukcji EXPLAIN agenta (lub komentarzy projektowych) między wczesnymi a późnymi wynikami sesji.
Protokół odporności wieloturowej
Trzy poziomy, z których każdy adresuje inny mechanizm. Należy zacząć od poziomu 1 i dodawać kolejne warstwy w miarę potrzeb.
| Poziom | Adresowany mechanizm | Interwencja | Koszt wdrożenia |
|---|---|---|---|
| 1 | Kompresja | Zapis stanu do systemu plików co 30 minut | Niski: 5-minutowa konfiguracja |
| 2 | Spójność | Iteracje ze świeżym kontekstem po 60–90 minutach | Średni: wymaga serializacji stanu |
| 3 | Koordynacja | Jawna synchronizacja stanu między agentami | Wysoki: wymaga zaprojektowania protokołu |
Poziom 1: punkty kontrolne stanu
Co 30 minut warto serializować bieżące rozumienie architektoniczne agenta do pliku. Nie pełną konwersację, lecz stan strukturalny: jakie moduły istnieją, jak się łączą, jakie ograniczenia obowiązują.
# Pre-compaction checkpoint (runs before Claude compresses context)
mkdir -p .claude/checkpoints
cat > ".claude/checkpoints/$(date +%s).md" << 'CHECKPOINT'
## Architectural State
- Module graph: [current understanding]
- Active constraints: [list]
- Design decisions made this session: [list with reasoning]
CHECKPOINT
Jeśli zachowanie agenta degraduje się, lepiej przywrócić stan z punktu kontrolnego niż kontynuować ze zdegradowanym kontekstem.
Poziom 2: iteracje ze świeżym kontekstem
Dla sesji przekraczających 60 minut warto przejść na wzorzec pętli Ralph. Kluczem jest krok orientacji: wstrzyknięcie wystarczającej ilości stanu, aby nowy kontekst mógł kontynuować produktywnie bez ponownego czytania całej historii konwersacji.
Wymagany stan dla kroku orientacji:
1. Bieżące zadanie i kryteria akceptacji
2. Pliki zmodyfikowane w poprzedniej iteracji (z git diff)
3. Decyzje architektoniczne i ich uzasadnienie
4. Znane ograniczenia i tryby awarii
Poziom 3: protokoły koordynacji agentów
W przepływach wieloagentowych należy ustanowić wspólny dokument stanu, który wszystkie agenty czytają i aktualizują. Dokument służy jako źródło prawdy, zapobiegając rozbieżności, którą zaobserwowałem podczas recenzji deliberacyjnych.
{
"version": 7,
"last_updated": "2026-02-22T14:30:00Z",
"active_files": ["engine.py", "calculator.py", "aggregator.py"],
"constraints": [
"No circular imports between modules",
"All public functions require type annotations"
],
"decisions": [
{"decision": "Use RRF for vote aggregation", "reasoning": "Handles rank-only data", "turn": 3}
]
}
Każdy agent czyta ten dokument na początku swojej tury i aktualizuje go na końcu. Konflikty uruchamiają pauzę koordynacyjną zamiast cichej rozbieżności. Najlepsze agenty działają w ten sposób niewidocznie — jak opisano w The Invisible Agent, celem jest infrastruktura, która działa, nie wymagając uwagi programisty.
Kluczowe wnioski
- Degradacja wieloturowa jest strukturalna, nie jest problemem długości kontekstu. Badanie MSR/Salesforce wykazało 39% degradację nawet przy stałej długości kontekstu. Granice tur, a nie limity tokenów, napędzają załamanie.1
- Trzy niezależne mechanizmy wymagają trzech różnych interwencji. Utrata kompresji wymaga punktów kontrolnych stanu. Utrata spójności wymaga iteracji ze świeżym kontekstem. Awaria koordynacji wymaga protokołów współdzielonego stanu.
- Klif 90. minuty jest realny i mierzalny. Warto śledzić wykorzystanie kontekstu, różnorodność odwołań krzyżowych i sprzeczności architektoniczne, aby wykrywać degradację przed ujawnieniem się awarii produkcyjnych.
- Iteracja ze świeżym kontekstem działa, ale kosztuje 15–20% narzutu. Wzorzec pętli Ralph wymienia narzut orientacji na pełne budżety kontekstu na iterację. Bilans przemawia za świeżym kontekstem powyżej 60–90 minut.
- Adaptacyjna alokacja rozumowania przewyższa jednolitą głębokość. Kognitywny routing decyzji Du i in. osiągnął 34% redukcji kosztów przy 23% wzroście spójności dzięki dopasowaniu głębokości rozumowania do wymagań zadania.2
FAQ
Dlaczego LLM degradują się w konwersacjach wieloturowych?
LLM degradują się w konwersacjach wieloturowych wskutek trzech niezależnych mechanizmów. Kompresja kontekstu odrzuca wcześniejsze informacje, aby zmieścić nową treść w budżecie tokenów. Spójność rozumowania fragmentuje się, gdy łańcuch myśli modelu rozpościera się na wiele tur, generując wyniki lokalnie poprawne, lecz globalnie niespójne. Koordynacja między wieloma agentami zawodzi, gdy kontekst każdego agenta degraduje się niezależnie. Microsoft Research i Salesforce udokumentowali średni spadek wydajności o 39% na podstawie 15 LLM i ponad 200 000 konwersacji, przy czym degradacja rozpoczyna się już po dwóch turach.
Czy dłuższe okna kontekstu naprawiają degradację wieloturową?
Dłuższe okna kontekstu nie naprawiają degradacji wieloturowej. Badanie MSR/Salesforce przetestowało warunek „Concat", w którym pełna konwersacja została zaprezentowana jako pojedynczy prompt, osiągając 95,1% wydajności trybu jednoturowego. Ta sama treść rozłożona na wiele tur spadała do około 65%. Źródłem degradacji są same granice tur, a nie ograniczenia długości kontekstu. Podwojenie okna kontekstu nie wyeliminowałoby 39% luki wydajnościowej.
Czym jest wzorzec iteracji ze świeżym kontekstem dla agentów AI?
Iteracja ze świeżym kontekstem uruchamia nową instancję AI na każdy cykl pracy zamiast kontynuować pojedynczą długą konwersację. Stan utrwala się w zewnętrznej pamięci masowej (system plików, baza danych), a nie w pamięci konwersacyjnej. Każda iteracja odczytuje bieżący stan, wykonuje pracę i zapisuje zaktualizowany stan z powrotem. Wzorzec eliminuje artefakty kompresji i fragmentację spójności kosztem 15–20% narzutu na krok „orientacji", w którym nowa instancja odczytuje i przetwarza zewnętrzny stan. Dane produkcyjne pokazują, że wzorzec przewyższa podejście jednosesyjne w zadaniach trwających ponad 60–90 minut.
Jak wykryć degradację wieloturową, zanim spowoduje awarie?
Trzy metody detekcji sprawdzają się w praktyce. Monitorowanie presji kontekstu śledzi wykorzystanie tokenów i ostrzega, gdy przekracza ono 60% (prawdopodobna degradacja jakości) lub 80% (pora rozpocząć nową sesję). Śledzenie odwołań krzyżowych monitoruje, ile odrębnych plików agent wymienia na wyjściu; malejący trend sygnalizuje utratę kompresji. Detekcja sprzeczności porównuje deklaracje architektoniczne agenta w czasie; jeśli rozumienie zależności modułów przez agenta zmienia się między wczesnymi a późnymi wynikami sesji bez jawnej decyzji — spójność uległa degradacji.
Po ilu turach wydajność LLM zaczyna się pogarszać?
Degradacja wydajności rozpoczyna się już po dwóch turach, zgodnie z badaniem MSR/Salesforce obejmującym 15 LLM w ponad 200 000 konwersacji. Dotkliwość wzrasta wraz z długością konwersacji: praktyczne pomiary wykazują spójny klif jakości w okolicach 60–90 minut ciągłej interakcji z agentem. Zadania wymagające międzyplikowego stanu architektonicznego degradują się szybciej niż izolowana praca nad pojedynczym plikiem. Kluczowe odkrycie: gdy LLM „zboczą na złą ścieżkę" w konwersacji wieloturowej, nie korygują się samoistnie — błąd kumuluje się przez kolejne tury.
Źródła
-
Laban, Philippe, et al., “LLMs Get Lost In Multi-Turn Conversation,” arXiv:2505.06120, May 2025. arxiv.org. Microsoft Research and Salesforce Research. Tested 15 LLMs across 8 model families on 200,000+ simulated conversations. ↩↩↩↩↩↩
-
Du, Y., et al., “Cognitive Decision Routing in Large Language Models: When to Think Fast, When to Think Slow,” arXiv:2508.16636, August 2025. arxiv.org. Achieved 34% reduction in computational costs with 23% improvement in consistency. ↩↩↩
-
Bhardwaj, et al., “Agent Context Protocols Enhance Collective Inference,” arXiv:2505.14569, May 2025. arxiv.org. Introduces structured communication protocols for multi-agent coordination, achieving 28.3% accuracy on AssistantBench. ↩
-
Krishnan, “Beyond Context Sharing: A Unified Agent Communication Protocol,” arXiv:2602.15055, February 2026. arxiv.org. Proposes standardized agent-to-agent orchestration with zero-trust security boundaries. ↩
-
Zhang, Alex L., Tim Kraska, and Omar Khattab, “Recursive Language Models,” arXiv:2512.24601, December 2025. arxiv.org. MIT CSAIL. RLM-Qwen3-8B outperforms baseline by 28.3% on long-context tasks by offloading context to a Python REPL environment. ↩
-
Nanda, Rahul, et al., “Wink: Recovering from Misbehaviors in Coding Agents,” arXiv:2602.17037, February 2026. arxiv.org. Misbehaviors occur in approximately 30% of all agent trajectories; Wink resolves 90% of single-intervention cases. ↩
-
Author’s session quality measurements across 30 Ralph loop iterations, January-February 2026. Data collected from
jiro.progress.jsonsession logs andgit diff --statoutput per iteration. Orient overhead measured by token count of state injection vs. total iteration budget. ↩ -
Author’s context-is-architecture system. Seven-layer hierarchy across 650 files documented in Context Engineering Is Architecture. ↩
-
Author’s multi-agent deliberation system. 10-agent consensus with 3-reviewer autonomous code review documented in The Deliberation System. ↩