The wide sweep. 5 agent-reach lanes across every live backend: (1) X/Twitter topic sweep, (2) Reddit agent-builder subs, (3) YouTube conference talks (real transcripts), (4) the CHINESE ecosystem — Bilibili/Xiaohongshu/V2EX (never mapped before), (5) GitHub + newsletters. ~33 net-new items, deduped against loops2/loops3/hn_spree/top_voices. The Chinese lane and the YouTube talks were the highest-novelty; the strongest single datapoint is Pachaar's harness-optimization benchmark.

TOP ACTIONS (ranked — cross-platform convergences first)

1. Fold four genuinely-new framings into the loop-engineering skill (durable doctrine upgrade).

• The control-handoff axis (Chinese lane, ≥2 XHS creators teaching a "Claude Code team" framework): classify loops by who holds control — Round Loop (human checks each step) / Goal Loop (human sets stop condition) / Time Loop (human sets trigger) / Active Loop (full handoff), thesis "only verifiable tasks are worth automating." Orthogonal to our trigger-mechanism axis; maps onto the autonomy ladder. Add to LOOPS.md.
• "Garbage collection day" (Lopopolo/OpenAI, who coined "harness engineering"): the weekly ritual of converting one-off human corrections into permanent lint rules / persona-scoped review agents. This IS what L11 hill-climb + L9 skill-miner do — adopt the name and the cadence.
• Three missing catalog patterns (Chinese 20-pattern taxonomy): Debate Cycle, Tree-Search-with-pruning, Multi-Review Integration — patterns our L1–L11 roster doesn't hold distinctly.
• The transferability rule (Pachaar, Twitter — the headline): code/tool/config harness fixes TRANSFER across sibling models (+14pts); prompt-playbook fixes do NOT and can hurt another family. → L11 should PREFER proposing code/tool/config changes over prompt-only ones, because they generalize across the fleet's mixed models.

2. Refine L11 hill-climb with two model-generalization findings.

• Fixes are model-specific (Robert Lange/Sakana): different models discover different harness fixes for their own weaknesses; a fix mined on one model's traces may not help another. → L11 must record WHICH model's traces motivated each proposal, and lean toward transferable (code/tool) fixes (per Pachaar) rather than model-family-specific prompt tweaks.
• Scope-widening = a permissions change (Reddit r/AI_Agents "promotion packet"): any proposed change that widens tool scope or approval behavior is gated stricter regardless of benchmark score. Sharpens the L11 change-contract exactly where P2 (the deny-hook) already gave us pause.

3. Add per-subagent budget caps to the fan-out doctrine (concrete, actionable). Claude Code's up-to-5-level nesting means a TOP-LEVEL cost cap does NOT bound individual nested subagents — a practitioner ran 29 agents and burned $300/night with memory + splitting + stop-conditions all in place, fixed only by a per-subagent budgetMaxCostUsd in task.runtime.json (Twitter, sairahul1 reply). Add to CLAUDE.md fan-out. Corroborates "the cheapest sub-agent is the one you never spawned; fan-out is an output-token problem" (Reddit).

4. The loop health board (already building) IS the "sensors" layer. Thoughtworks (YouTube) frames it exactly: feedforward/feedback × inferential/computational sensors, with the sharp question "with good sensors, how many guides can you delete?" — the board is the sensor fabric that lets us thin the prose guides.

5. Two evaluate-later items + one risk to watch.

• fiber5 (V2EX) — an open-sourced Claude Skill to make other agents imitate Fable 5's behavior, built because "Fable 5 is about to expire." Cloneable; on-point for the credit-metering doctrine.
• Hermes "Harness Loop" — memory as plain text, ZERO embeddings ("the moat is memory, not models") — a direct counterpoint to gbrain's embedding-heavy design, already flagged as possibly overkill at ~612 files.
• RISK (unverified): Reddit reports Anthropic suspended OpenClaw's creator's Claude account for the "loop/retry/chain-tools/stay-active" pattern — which is what this user's own OpenClaw gateway does daily on the Max sub. Combined with the ANTHROPIC_BASE_URL fingerprinting finding, a ToS-risk pattern worth monitoring, not a settled event.

Authoritative validations (from the source): Anthropic's own long-running-agent workshop (YouTube) uses a GAN generator/evaluator loop with a written "done" contract (≤27 criteria) negotiated BEFORE coding and a restart-from-scratch when the builder can't hill-climb — validates L3 review-until-clean + the L11 change-contract. Devin's 80% moment (Cognition): they orchestrate a DIFFERENT model for the verification stage — validates maker≠checker + model-pin. Cache-killer gotcha (Posit): changing system prompt OR tool availability per-turn nukes prompt-cache — relevant to this session's 90+ deferred MCP tools (idle-MCP tax). "Prompt is dead, Loop is king" is now a same-week cross-platform Chinese trend, independent of the Western sources.

Lane 1 — X/Twitter topic sweep

LANE 1 — Agent Loops / Loop Engineering, TOPIC sweep (X/Twitter, last ~90 days, sweep 2026-07-07)

Scope: topic-level mining of "agent loop / loop engineering / agentic loop / self-improving agent / hill-climb agent / verification loop / agent harness / while-loop agent / orchestration loop / agent runtime loop" — a TOPIC sweep, not a named-voices pass (already done in RESEARCH_top_voices.md, _2.md, RESEARCH_loops2.md, RESEARCH_loops3.md, RESEARCH_hn_spree.md — all read and deduped against before searching). All 6 items below are net-new (checked against those five files).

Tooling note (read before trusting completeness): opencli twitter search hit a hard session-quota 429 (HTTP 429: SearchTimeline fetch failed... retry after cooldown (typically 15-30 min)) on every attempt across ~10 minutes of retries with varied queries/products — this was a genuine retry effort, not a null-on-first-try. The opencli twitter thread <id> endpoint stayed available throughout (does not share the same rate limit bucket), so the workaround used was: WebSearch with site:x.com/ site:twitter.com to surface topic-cluster candidates, then opencli twitter thread <id> to pull full text, engagement numbers, and reply context for each candidate. This is a real but narrower net than a live X search would have given — treat this as a partial-coverage sweep, not exhaustive.

1. Robert Lange (Sakana AI) — "Self-Harness" vs. Darwin Gödel Machine: the three concrete deltas, from a researcher-to-researcher exchange with Jeff Clune

Why high-signal: Robert Lange is Staff Research Scientist / founding member at Sakana AI (The AI Scientist, ShinkaEvolve). Jeff Clune (DGM co-author, UBC professor, CIFAR AI Chair) directly asked "seems pretty similar to DGM? What do you think the key new elements are?" — Lange's answer is the sharpest, most precise differentiation of self-harnessing-loop research found in this sweep, and it's primary-source, not secondhand paraphrase (the "Self-Harness" system referenced is the SAME line of research already banked in RESEARCH_loops2.md Lane 2 item #2 via Lilian Weng's survey — this is net-new detail on top of that, from the researcher himself, not a repeat).

Concrete takeaway: Three deltas vs. Darwin Gödel Machine (DGM), each with a build implication:

1. Open model validation — different models discover different harness modifications. Lange's original thread: "MiniMax M2.5, Qwen3.5-35B-A3B, and GLM-5 learn distinct harness modifications tailored to their specific weaknesses." Implication for a routing-matrix-driven fleet: a harness fix mined from Opus's failure traces is not guaranteed to be the right fix for Sonnet's or Fable's failure traces — don't assume one hill-climb proposal generalizes across the model roster without per-model validation.
2. No alignment necessity in the coding domain — Lange: "given that coding is general problem solving, this doesn't appear to be a big deal, and hyperagents also demonstrate this." i.e. the self-harnessing loop doesn't need a separate alignment-preservation mechanism when the domain is code/tool-use (as opposed to open-ended agentic behavior).
3. Flat iterative search vs. Darwinian archive — Lange: "This appears possible now, with open models cutting costs. But similar to the OG DGM paper, no one knows what the actual scaled-up ceiling is." Implication: a simpler "keep the best, iterate" loop (which is what the already-spec'd L11 build does — one accepted proposal per round, not an archive of parallel lineages) is a defensible simplification of DGM's archive-of-agents approach, not a naive shortcut — Lange, a domain expert, treats it as a live open question rather than a known-inferior choice.

Source: x.com/RobertTLange/status/2070568776970506614 (Jun 26, 2026, 107 likes / 23 retweets) — original: "Self-Harness lets LLM agents autonomously improve their own harness that mediates their interaction with environments without external human/model guidance... 2️⃣ Targeted, Not Generic, Adaptations: MiniMax M2.5, Qwen3.5-35B-A3B, and GLM-5 learn distinct harness modifications tailored to their specific weaknesses." Reply to Jeff Clune (@jeffclune, 5 likes): x.com/RobertTLange/status/2070773274384945214 (Jun 26, 2026) — "the biggest differences compared to DGM appear to be the following: 1. Open model validation and the result that different models discover different harnesses. 2. No alignment necessity (coding domain)... 3. Flat iterative search vs. Darwinian archive."

2. Akshay Pachaar, amplifying a Hugging Face harness-optimization writeup — same model/judge/tasks, five harnesses score 3.5% to 80.1%; the biggest single fix was a file-save path, not reasoning

Why high-signal: 1,309 likes / 200 retweets — the highest-engagement single item in this sweep. Sourced from and links directly to a Hugging Face Space writeup (t.co link resolved to huggingface.co/spaces/joelniklaus/harness-optimization), not a bare take. Gives the sharpest available quantification of "harness dominates over model capability" found across this sweep or the dedup'd docs — loops2's HarnessFix numbers (GAIA 43.3%→61.7% etc.) are in the same family but this is a starker, single-model isolation: frozen weights, same judge, same tasks, only the harness code changed.

Concrete takeaway: A frozen open model scored 0% on a hard legal-agent benchmark; an automated loop that rewrote only the harness code (proposer adds one mechanism per iteration, an outer loop keeps it only if it clearly beats the current best — the same accept-if-strictly-better pattern already in the L11 spec) brought it to matching Sonnet 4.6 on the headline metric, at ~7x lower cost per task, with zero weight changes. Root cause of the 0%: the model was doing the legal analysis correctly but saving the output under the wrong filename/location — "The 0% was never measuring legal reasoning. It was measuring the harness." Two findings with direct build implications: (a) code/tool-plumbing fixes transferred across models in the same family (+14 points on a smaller sibling model), but prompt-playbook fixes did NOT transfer — and even hurt a different model family on tasks it could already finish. For the L11 build's fixed operator catalog, this argues for treating "add a deterministic output-location check" (a Tooling-layer fix) as more portable/reusable across the routing-matrix roster than a prompt-wording tweak, which should be re-validated per-model rather than assumed to generalize. (b) Same model, same judge, same tasks, five different harnesses scored 3.5% to 80.1% — the single most extreme harness-variance number found in this sweep, worth citing whenever justifying "diagnose the harness before escalating the model." (c) Gains flatten eventually — the author's own caveat: past a point, remaining misses are real capability gaps, not harness bugs — matching the Self-Refine plateau finding already banked in loops2.

Source: x.com/akshay_pachaar/status/2072961737008336937 (Jul 3, 2026, 1,309 likes / 200 retweets). "Don't train the model, evolve the harness... By the time the loop finished, the system had essentially matched Sonnet 4.6 on the benchmark's headline metric, at roughly 7x lower cost per task. Zero weights changed... Code fixes transferred across models, prompt playbooks did not... Same model, same judge, same tasks, and five different harnesses scored anywhere between 3.5% and 80.1%." Primary source: huggingface.co/spaces/joelniklaus/harness-optimization

3. Google's Gemini CLI team ships "Scion" — first-party multi-agent orchestration with per-agent container + git worktree + credential isolation, spanning Claude Code/Gemini CLI/Codex

Why high-signal: First-party from the Gemini CLI team (not a third-party wrapper), demoed at Cloud Next, 466 likes / 68 retweets on the announcement — a real shipped artifact, and notable specifically because it's a Google product explicitly built to orchestrate competitor harnesses (Claude Code, Codex) alongside Gemini CLI, not just its own.

Concrete takeaway: Scion orchestrates multiple coding-agent CLIs "as isolated, concurrent processes," where "each agent gets its own container, git worktree, and credentials — so they can work on different parts of your project without stepping on each other." This is a direct, first-party validation of the already-banked forge-orchestrator pattern (loops3 Lane B #5) but adds a dimension forge-orchestrator's README doesn't emphasize as strongly: per-agent credential isolation, not just file-lock isolation. For this system's fan-out doctrine (worktree-per-feature already used in improve/autoplan-style flows), the actionable delta is to check whether parallel subagent worktrees also get scoped/distinct credentials (API keys, tokens) rather than sharing the parent session's full credential set — a blast-radius reduction Scion treats as load-bearing, not incidental.

Source: x.com/geminicli/status/2051725136974246266 (May 5, 2026, 466 likes / 68 retweets). "Scion is a new multi-agent orchestration tool that orchestrates agents (Claude Code, Gemini CLI, Codex, and others) as isolated, concurrent processes. Each agent gets its own container, git worktree, and credentials — so they can work on different parts of your project without stepping on each other." Companion announcement (242 likes): x.com/geminicli/status/2051725135195861233, session recording

4. Composio "Agent Orchestrator" — open-sourced coordination layer for 30 parallel coding agents, with a distinct "stuck vs. needs-human" escalation gate; independently corroborated by a third-party guardrails repo

Why high-signal: 623 likes on the announcement thread; independently corroborated as real (not vaporware/hype) via two third-party GitHub repos found by direct search — Inntris/agent-orchestrator-guardrails ("Action-level governance demo for Composio Agent Orchestrator: Inntris Verified blocks risky PRs [migrations/CI/deps/secrets] and logs an audit ID") and chetwerikoff/orchestrator-pack ("Upgrade-safe reusable extension pack for Composio Agent Orchestrator") — i.e. a small ecosystem is already building guardrail extensions on top of it, which is stronger evidence of a real, adopted tool than the announcement tweet alone.

Concrete takeaway: The stated failure mode it targets is exactly the "fleet at scale" pain this user's loop roster is approaching — "Running one AI agent in your terminal is easy. Running 30 of them across different issues, branches, and PRs at the same time is a coordination nightmare... manually creating branches, babysitting agents, checking if they're stuck, reading CI logs, forwarding review comments, tracking which PRs are ready to merge." Mechanics: spawns parallel Claude Code/Codex/Aider agents per issue, each with isolated git worktree + branch + PR; CI failures get piped straight back to the originating agent automatically; the orchestrator only notifies the human when an agent is stuck or needs judgment (not on every status change) — a concrete instantiation of the "escalation" field already flagged as missing from this system's Definition-of-Ready gate (per the banked Addy Osmani / top_voices item). The third-party guardrails repo is worth a closer look independently: it implements action-level blocking (migrations/CI/deps/secrets touch = auto-block + audit ID) as a bolt-on layer, which is close to the "hard gates the loop cannot cross" pattern already in the L11 spec, but implemented as a generic Composio plugin rather than something built from scratch.

Source: x.com/eng_khairallah1/status/2036156107412869236 (undated in this pull, thread active as of this sweep; 623 likes). "Composio just open-sourced the coordination layer that turns AI coding agents from a toy into a production system... Spawns parallel Claude Code, Codex, or Aider agents on any issue → Every agent gets its own isolated git worktree, its own branch, its own PR → CI fails? The orchestrator sends the logs back to the agent. → Agent stuck or needs human judgment? Only then it notifies you → Real-time dashboard at localhost:3000... 8 plugin slots." Corroboration: github.com/Inntris/agent-orchestrator-guardrails, github.com/chetwerikoff/orchestrator-pack (both found live via gh search repos).

5. Rahul (@sairahul1) viral "three loop mistakes" thread + a buried practitioner reply naming the exact fix for uncapped nested-subagent cost blowouts

Why high-signal: 3,829 likes / 557 retweets — by far the most-amplified single tweet found in this entire topic sweep, paraphrasing an Anthropic engineer's "you build a system that prompts itself" framing into three named failure modes. The tweet itself largely restates ground this user's own loop-engineering doctrine already covers (memory file / sub-agent split / stop condition), so it's flagged as reinforcement, not the primary find — the actionable net-new item is buried in the replies: a Japanese practitioner account (@ai_builders_lab, self-described as running 29 AI agents for a fully-automated product pipeline earning ~¥850k/month) reports burning $300 in a single night because none of the three named fixes protect against per-subagent cost blowouts once deep nesting is involved.

Concrete takeaway: With Claude Code's 5-level agent nesting now available, a memory file + sub-agent split + a top-level stop condition are all necessary but NOT sufficient — none of them cap what an individual nested subagent can spend before it reports back. Their fix: add a budgetMaxCostUsd field to task.runtime.json, i.e. a hard per-subagent dollar ceiling enforced at spawn time, not just a top-level session/turn cap. Verbatim (translated): "No budget ceiling per sub-agent. Even with all three [fixes] in place, we still burned $300 in one night — until we put budgetMaxCostUsd into task.runtime.json. Now that Claude Code has unlocked 5-level nesting, cost design has to be built in from turn one." This is a concrete, narrower refinement of the already-banked "per-agent token circuit breaker" guardrail (loops3 Lane B #7) — the delta is that the cap needs to be enforced per nesting level, not just per top-level agent, once multi-level subagent fan-out is in play (directly relevant given this system's own subagent-pinning doctrine already worries about fan-out ceilings).

Source: x.com/sairahul1/status/2068627267488710930 (Jun 21, 2026, 3,829 likes / 557 retweets). "Anthropic engineer: 'You're not supposed to prompt Claude. You're supposed to build a system that prompts itself.' Loops. Most builders are doing this wrong: No memory file... No sub-agent split... No stop condition, so loops run forever and bill you in your sleep." Reply: x.com/ai_builders_lab/status/2071383372988080600 (Jun 29, 2026) — "サブエージェントごとに予算上限がない。 この3つ揃えても1晩$300溶けた。task.runtime.jsonにbudgetMaxCostUsdを入れるまで。Claude Codeで5階層ネストが解禁された今、 コスト設計は1ターン目から必須になった。" ("No budget ceiling per sub-agent. Even with all three in place, we still burned $300 in one night — until we added budgetMaxCostUsd to task.runtime.json. Now that Claude Code has unlocked 5-level nesting, cost design must be built in from turn one.")

Honest nulls

• "while loop agent" / "agent runtime loop" as literal search phrases: too generic/noisy to surface distinct signal via WebSearch fallback — folded into the "orchestration loop" and "agent harness" clusters above instead, no separate item.
• Live X search (opencli twitter search) stayed 429'd for the full ~10-minute retry window spent on it before switching to the WebSearch→thread-pull workaround; a fresher, broader pass with working search access would likely surface more than the 6 items here — this sweep should be treated as a representative sample of the last-90-days conversation, not an exhaustive one.
• Hikari Senju / Omneky "agentic loops" post (https://x.com/hisenju/status/2074281366787949017, Jul 6, 2026) was checked and dropped — 2 likes, vendor growth-marketing framing ("self-improving data-driven loops... try for free"), no concrete technique disclosed.
• Satya Nadella's "AI hill-climbing machine" framing (via @bearlyai, paraphrasing a Nadella talk) was checked and dropped — enterprise-strategy-level ("every company needs its own hill-climbing machine trained on its own IP"), not a Claude-Code-actionable technique.

Provenance

Sweep 2026-07-07/08, lane 1 of a wide parallel loop-research sweep, single Sonnet pass. Read and deduped against docs/RESEARCH_loops2.md, RESEARCH_loops3.md, RESEARCH_top_voices.md, RESEARCH_top_voices_2.md, RESEARCH_hn_spree.md before searching. Primary tool opencli twitter search (OpenCLI backend) hit a session-quota HTTP 429 on every attempt across query clusters ("agent loop", "loop engineering", "agentic loop", "self-improving agent", "hill climbing agent", "verification loop", "agent harness", "while loop agent", "orchestration loop", "agent runtime loop") over ~10 minutes of spaced retries (varied query text, --product live, env-var timeout override) — genuine retries, not a first-try null. Workaround: WebSearch (site:x.com/site:twitter.com) to find topic-cluster candidate tweets, then opencli twitter thread <id> (unaffected by the search rate limit) to pull full text/engagement/replies for each candidate. gh search repos used to corroborate the Composio Agent Orchestrator claim independently. curl -sIL to resolve t.co short links to canonical source URLs (Hugging Face Space). Raw YAML caches in this directory: t_hisenju.yaml, t_sairahul.yaml, t_lange.yaml, t_scion.yaml, t_composio.yaml, t_akshay.yaml.

Lane 2 — Reddit agent subs

Loop Research Sweep — Lane 2: Reddit (agent-builder subs, last ~90 days)

Scope: r/AI_Agents, r/AgentsOfAI, r/LocalLLaMA, r/LangChain, r/AutoGenAI searched directly (OpenCLI opencli reddit search/subreddit/read, no rate-limit issues hit). Deduped against RESEARCH_loops2.md, RESEARCH_loops3.md, RESEARCH_hn_spree.md — the HN spree's Lane C already covered r/ClaudeAI (3 items: @import-doesn't-force-reads, UltraCode 10-15 subagent burn, token-burn checklist); this sweep deliberately skips r/ClaudeAI and surfaces net-new subs/threads (mostly r/AI_Agents + r/AgentsOfAI, which neither prior doc touched). r/LangChain, r/AutoGenAI, r/MachineLearning, r/ChatGPTCoding, r/LocalLLaMA were searched but yielded nothing on-topic and net-new beyond what's below (see Honest nulls).

1. "What should govern a self-improving AI-agent loop?" — the promotion-packet pattern + "score went up ≠ ships" reframe

Why high-signal: low score (2) but a genuinely deep discussion thread (20 comments, high signal-to-noise) that independently converges on almost the exact governance gap RESEARCH_loops2.md's Lane 3 already flagged (held-out gate, worst-case regression, human terminal gate) — but adds one mechanic that ledger doesn't have: explicitly separating "the metric improved" from "this is allowed to become part of the system" as two different decisions with different review bars, and reframing certain classes of "improvement" as permissions changes, not quality changes.

Concrete takeaway: top comment (LaceLustBopp) proposes every self-improvement proposal carry a promotion packet — what changed, which metric improved, which metric got worse, what new external side effects it can trigger, what policy version it was evaluated against, how to roll back — and argues that if an update "expands tool scope, changes approval behavior, or increases the chance of writing to [sensitive] state," that's a permissions change, not a model-quality improvement, and should be blocked from auto-promotion even if the benchmark says it's better. Also floats shadow runs: let the improved loop run read-only against recent real cases, diff its proposed actions against the current loop's, and only persist when the differences are explainable and inside an allowed envelope. Directly extends L11's change-contract schema in RESEARCH_loops2.md — add a "permission-scope delta" field to the change-contract and gate any nonzero delta at human-review regardless of confidence score.

Source: reddit.com/r/AI_Agents/comments/1u5a96c/what_should_govern_a — r/AI_Agents, 2026-06-09, score 2 / 20 comments. Quote (LaceLustBopp): "I'd separate 'the score went up' from 'this change is allowed to become part of the system.' Those are different decisions... If an update makes the agent faster but also expands tool scope, changes approval behavior, or increases the chance of writing to customer/accounting/payment state, that should not be treated as a normal model-quality improvement. It is a permissions change."

2. kyoko (kayba-ai) — a shipped, open-source local control system for autoresearch-style self-improvement loops, close to a working L11

Why high-signal: this is not a paper or a take, it's a real open-source repo (github.com/kayba-ai/kyoko) built by someone independently converging on almost the exact pipeline in RESEARCH_loops2's L11 build spec — capture traces → find recurring failures → turn them into evidence-backed issues → let a coding-agent CLI draft a fix → gate on checks/evals → apply only through a gate. Worth reading as a structural reference even without adopting it.

Concrete takeaway: everything is local by default (SQLite DB, dashboard, traces, issues, proposals, evals) and reuses whatever coding-agent CLI you already have (Codex/Claude Code) for the analysis and fix-drafting step — no separate hosted service or extra model API key. Six-step workflow: capture runs → find failures that repeat across runs → turn into reviewable issues with evidence → draft fix → rerun the failing trace + deterministic checks + eval comparison → apply only if it passes the gate, else park for review. A commenter's reply names the sharpest open problem, worth carrying into the L11 build: "how do you handle the case where a fix passes the eval but introduces drift in a part of the codebase the eval didn't cover" — i.e. even a passing held-out gate has blind spots if the held-out set doesn't cover the affected surface; another commenter's fix is tagging skills with semantic-version contracts so a v2 skill change can't silently break v1 consumers.

Source: reddit.com/r/AI_Agents/comments/1u1fwru/i_built_a_local_cont — r/AI_Agents, 2026-06-08, score 13 / 5 comments. Repo: github.com/kayba-ai/kyoko. Quote (OP): "Self-improvement loops are cool in theory but very difficult to transfer to production environments unless you build the infrastructure around them." Quote (ShiftTechnical): "The gate logic is where most self-improvement loops fall apart in practice... How are you scoping what counts as a regression boundary?"

3. EvoSkill (Sentient AGI) — held-out-gated, git-tracked skill evolution, published numbers, independent confirmation of the skillopt pattern

Why high-signal: a real arXiv paper (2603.02766) with a shipped repo (github.com/sentient-agi/EvoSkill), not a blog post — a second, independent implementation of exactly the pattern RESEARCH_loops2's Lane 3 #1 already banked from gbrain's skillopt (held-out gate, accept-only-if-improves, git-tracked history), this time with real published benchmark deltas rather than a design doc.

Concrete takeaway: a failed run suggests a skill/prompt edit; that edit must improve held-out examples before it is kept; kept versions are tracked in git so they're diffable, reviewable, revertible. Explicit inspect-and-reject step: "if a generated skill looks too broad, too specific, or like it is gaming the eval, we do not have to keep it" — same reward-hack-quarantine instinct as HarnessFix/Self-Harness from RESEARCH_loops2, independently arrived at. Author explicitly frames this as "eval-driven cleanup of repeated agent mistakes, not model training or autonomous self-improvement" — a useful naming distinction for scoping what L11 should claim to do. Measured gains: OfficeQA 60.6%→67.9%, SealQA 26.6%→38.7%, 5.3pp zero-shot gain on BrowseComp from a skill evolved on SealQA (cross-task transfer, echoing HarnessFix's cross-model transfer finding).

Source: reddit.com/r/AI_Agents/comments/1ua6hpq/evoskill_evaldriven_ — r/AI_Agents, 2026-06-11 (est.), score 3 / 2 comments. Paper: arxiv.org/abs/2603.02766. Repo: github.com/sentient-agi/EvoSkill. Quote (OP): "A failed run can suggest a skill or prompt edit, but that edit still has to improve held-out examples before it is kept. The kept version is tracked in git, so it can be read, compared, reviewed, or rolled back."

4. Anthropic suspended the OpenClaw creator's Claude account for loop/retry/chain-tool usage patterns — direct operational risk for this system's own OpenClaw setup

Why high-signal: this is not abstract — the user runs OpenClaw's gateway daily via the anthropic:claude-cli Max-sub OAuth bridge (per MEMORY.md), and this thread documents exactly the usage-pattern class that got Peter Steinberger (OpenClaw's creator) auto-flagged and temporarily banned: "They loop, retry, chain tools, and stay active far longer than a typical user conversation" — precisely OpenClaw's heartbeat-driven agent loop shape. Confirmed via TechCrunch (techcrunch.com/2026/04/10/anthropic-temporarily-banned-openclaws-creator-from-accessing-claude/), not just a rumor.

Concrete takeaway: two separate but related risks for this user's setup: (1) Anthropic has already announced standard Claude subscriptions no longer cover usage through external "claw" harnesses like OpenClaw, forcing that workload onto metered API billing (the "claw tax") — worth checking whether the local anthropic:claude-cli bridge is still billing against the Max subscription or has silently been pushed onto metered API pricing; (2) a commenter reports Anthropic is actively shipping countermeasures against OpenCode specifically ("They made three changes just this last weekend to try and block OpenCode again") — i.e. this is an evolving, adversarial cat-and-mouse pattern, not a one-time policy, and OpenClaw-adjacent tooling should be assumed to face periodic breakage/reflagging risk going forward, not treated as settled. Practical mitigation named in-thread: keep a fallback model/provider wired in for anything load-bearing so a ToS/policy change on one provider doesn't take down the whole setup (echoes the existing GLM-overflow-lane doctrine, but frames it as ToS-risk mitigation, not just cost).

Source: reddit.com/r/AI_Agents/comments/1sjqxat/anthropic_suspended_ — r/AI_Agents, 2026-04-12, score 208 / 49 comments. Quote (OP): "Agent frameworks like OpenClaw can generate usage patterns that look very different from standard chat subscriptions. They loop, retry, chain tools, and stay active far longer than a typical user conversation. Anthropic's stated reason for the policy change is that subscriptions were never designed for this kind of load." Quote (TheCritFisher): "Anthropic has been trying to ban OpenCode users too... They made three changes just this last weekend to try and block OpenCode again."

5. Fable 5 fan-out cost thread — "the cheapest sub-agent is the one you never spawned"; caching only helps input, fan-out is an output-token problem

Why high-signal: directly touches the model-routing matrix (this system already scores fable-5 cost=1/intelligence=9/taste=9, credit-metered, walk-away-only). The thread and top comments give concrete operational numbers and a mechanic the routing doctrine doesn't currently encode: fan-out cost is dominated by output tokens (plans, sub-agent instructions, self-checks, retries — all newly generated every time), which prompt caching (a 90% input discount) does nothing for.

Concrete takeaway: OP reports burning ~2% of a Max 20x usage window per minute during a heavy Fable-5 session, vs. never approaching limits on Opus 4.8 for equivalent workloads — i.e. per-task cost is well above the sticker 2x price delta once fan-out is counted. Best comment (sanreds): "caching helps input, not output. fan-out is an output problem. Plans, sub-agent instructions, self-checks, retries. All new tokens every time, that's exactly where the $50/M lands." Direct reply (Mariia_Sosnina): "the cheapest sub-agent is the one you never spawned. Narrowing scope cut our spawn count way more than routing did" — i.e. before optimizing which model a sub-agent runs on, optimize whether that sub-agent needs to spawn at all. A separate commenter (rentprompts) describes a "blast radius" pre-check: before any sub-agent delegation, estimate a token ceiling and pre-validate against a task budget, only escalating to the frontier tier when a step is explicitly flagged high-complexity with budget approval — a concrete implementable pattern for the fan-out ceiling this system already caps at maxConcurrent: 8 but doesn't currently pre-budget per-spawn.

Source: reddit.com/r/AI_Agents/comments/1u1cyx1/fable_5_just_made_co — r/AI_Agents, 2026-06-09, score 177 / 68 comments. Quote (OP): "On the Max 20x plan I was burning roughly 2% of my usage window per minute during a heavy session. Same workloads on Opus 4.8 never came close to limits."

6. "The loop engineering trend is a financial nightmare" — practitioner cost-blowup war stories, converges with Lane C's Ashby's Law framing from a different angle

Why high-signal: r/AgentsOfAI, the single highest-engagement loop-specific thread found this sweep (171 score / 123 comments — a sub RESEARCH_hn_spree.md never touched). Mostly noise/jokes, but two comments are worth banking as real-world data points against unbounded loops, one of them independently re-deriving the control-theory framing already in RESEARCH_loops3 Lane C without having read it.

Concrete takeaway: (1) a named real cost-blowup: "Spent a week letting an agent loop on a refactor and came back to 400 test files and a $3k bill. The real skill isn't engineering loops, it's knowing when to pull the plug" (sylovar476) — a concrete, sourced instance of the exact failure mode this system's /goal//loop hard-cap doctrine already exists to prevent, worth citing as justification when that doctrine is questioned. (2) a top comment independently names the missing theory: "Idiots that never set foot in an engineering class and have no idea about control theory, and unbounded feedback loops" (curious_corn, 8 upvotes) — this is a practitioner arriving at the same Ashby's-Law/PID framing RESEARCH_loops3 Lane C banked from academic sources, via pure "I've seen this go wrong" intuition — corroborating evidence that the control-theory framing isn't just academic overreach, it's what experienced engineers actually reach for when they watch a loop burn money.

Source: reddit.com/r/AgentsOfAI/comments/1ui4a8k/the_loop_engineerin — r/AgentsOfAI, 2026-06-15 (est.), score 171 / 123 comments.

7. Real-browser QA-gate-before-merge pattern for multi-agent PR fan-out — a practitioner recipe for "CI passing ≠ it actually works"

Why high-signal: directly extends this system's own verify skill discipline ("drive the affected flow, not just tests") with a concrete multi-agent-scale implementation, and independently confirms IronBee's grounded-verify-loop finding from RESEARCH_loops3 Lane D #5 from a different angle (practitioner pain, not a vendor benchmark) — CI-green + clean-diff was insufficient signal to safely merge fanned-out agent PRs.

Concrete takeaway: OP's failure loop before the fix: 3-5 agents fan out, each opens a PR, CI passes, diffs look reasonable, human can't click through every preview by morning, merges on diff+CI signal alone, something breaks in prod because the agent did what was asked literally but the feature doesn't actually work end-to-end. Fix built: a second agent drives the PR's real preview deploy in an actual browser (Browserbase), clicks through the feature, and fails the PR if it doesn't work — if it fails, the report goes back to the build agent for up to 3 iterations before a human ever looks at it; the human then only reviews QA reports on PRs that already passed, not raw diffs. Directly portable pattern for any future fan-out this system runs that produces UI-facing changes: gate merge on a grounded browser-driven QA pass, not CI+diff-review alone. A second commenter's "tradeoffs report" pattern (cooperativ-labs/Overlord) is a smaller, complementary idea: have each agent explicitly report the tradeoffs it made per file, digested into a "feed post" a human skims — surfaces architectural decisions that pure diff review misses.

Source: reddit.com/r/AI_Agents/comments/1tx24s8/i_keep_abandoning_mu — r/AI_Agents, 2026-06-01 (est.), score 16 / 39 comments. Quote (OP): "CI passing doesn't tell you whether clicking the button does anything... Without it I'd run 5 agents and be too scared to merge any of their PRs. With it I just review the QA reports and merge the ones that passed."

Honest nulls

• r/LangChain, r/AutoGenAI: searched directly (--subreddit LangChain/AutoGenAI, queries "loop", "orchestration"). Results skewed toward RAG-pipeline tutorials, framework-comparison posts, and "how do I learn agents" content — nothing net-new on loop-engineering/self-improvement/verification specifically that cleared the bar over items 1-7 above. AutoGenAI in particular is low-traffic (top post in-window scored 27).
• r/MachineLearning, r/ChatGPTCoding: searched but returned no in-window (last ~90 days), on-topic results for the query clusters used — either low subreddit activity on this specific angle or the search backend's ranking didn't surface anything above noise. Not confirmed exhaustively; flagging as a gap rather than a confirmed null.
• r/LocalLLaMA: rich activity (GLM-5.2, model releases, benchmarks) but almost entirely about model capability/pricing, not loop-engineering mechanics — one tangentially relevant item ("I benchmarked 13 models at 65K-128K context... agentic workloads," score 315) was reviewed but didn't contain a loop-specific mechanic distinct from what's already banked, so excluded.
• No 429s/rate-limiting hit — OpenCLI's Reddit backend (browser-session, via opencli reddit search/read) worked cleanly across ~20 search calls and 8 full thread reads in this session, no retries needed.
• "agent stuck in loop", "loop until done", "reflection loop", "agent harness", "cron agent" as bare (non-subreddit-scoped) query clusters returned almost entirely off-topic subs (r/Superstonk, r/UFOs, r/hermesagent minutiae) — these terms are too generic for Reddit's search ranking without a subreddit filter; scoped subreddit+keyword combos (item source for 1-7 above) were far higher yield.

Lane 3 — YouTube talks

Loop Research Sweep — Lane 3 (YouTube, last ~90 days)

Dedup pass against RESEARCH_loops2.md, RESEARCH_loops3.md, RESEARCH_video_insights.md, RESEARCH_top_voices.md / _2.md, RESEARCH_toolbelt.md, RESEARCH_hn_spree.md confirmed only 5 prior YouTube IDs banked (DzbqeO_diOQ, 9fubhllmsBU, WAFUMBLOjHo, tqUDjc1HzO4, rv_VS189aVI). All 5 items below are net-new video IDs. Method: yt-dlp search discovery (ytsearch: queries) + yt-dlp --write-auto-sub to pull real closed-caption transcripts (not just titles/descriptions), cleaned to plain text and read in full.

1. Anthropic Workshop: Build Agents That Run for Hours — Ash Prabaker & Andrew Wilson (AI Engineer conf)

Why high-signal: This is the primary source for Anthropic's own long-running-agent harness pattern, presented by the two applied-AI engineers who wrote it, with full Q&A. 1h16m, dense, no fluff — walks through the actual harness architecture Anthropic uses to run demo-app builds for 3-6+ hours.

Concrete takeaway: The core pattern is a generator/evaluator adversarial loop (explicitly borrowed from GANs), not self-review. Self-evaluation is a trap because "tuning a standalone critic to be harsh is actually very tractable, but tuning a builder to be somewhat self-critical is not" — same asymmetry as a human being a better critic of art than a painter of it. The evaluator gets its own context window, its own system prompt, and actually drives Playwright to click around and test the live app rather than reading diffs. Before any code is written, the generator and evaluator negotiate a written contract (files on disk, back-and-forth markdown) of what "done" means for a given feature — one build used 27 separate contract criteria. Critically, when the generator gets stuck failing the same rubric criterion repeatedly, the harness throws the whole implementation away and restarts from scratch rather than patching — something a single-loop (Ralph-style) agent never does, because it gets attached to its own prior work. As models got smarter (Opus 4.5 → 4.6) they simplified the harness itself — dropped fresh-context-per-feature in favor of one long session + server-side compaction, because "the lesson isn't necessarily our harness was wrong, but rather it was right for 4.5, the frontier moved." Debugging method was reading full traces by hand, not running more experiments.

Directly exploitable at this system: Mission Control's L1-L11 roster could formalize a contract-negotiation handshake step between a builder tier and a reviewer tier before work starts (matches the "Definition of Ready gate" already in CLAUDE.md doctrine, but this talk gives a concrete mechanism: two agents writing/reading a markdown contract file until both agree, rather than one agent handed a spec). Also directly validates the "adversarial evaluator, not self-check" principle already implicit in /code-review and /verify — this talk gives the theoretical grounding for why (critic/generator skill asymmetry) and a "restart from scratch" fallback worth wiring into loop-engineering stop conditions.

Source:

— AI Engineer — 2026-05-18 (1:15:40) Quote: "yes, the evaluator is still, uh, a large language model, and yes, it's still going to be biased towards, uh, liking large language model style outputs, but tuning a standalone critic, um, to be harsh is actually very tractable, but tuning a builder to be somewhat self-critical, um, is is not." Quote (five-point closer): "self-evaluation, very much a trap. Just use an adversarial evaluator. Um, compaction doesn't necessarily, uh, does not equal kind of coherence, right? Lossy summaries really drift."

2. Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo (OpenAI), AI Engineer conf + Latent Space follow-up interview

Why high-signal: The talk that coined "harness engineering" as a term (referenced independently by both the Anthropic talk and the Thoughtworks talk below — this is the hub node of the whole topic cluster right now). Ryan runs a team at OpenAI that has literally banned engineers from touching their editors — Codex is the only entry point to the codebase. 46 minutes talk + separate ~50min Latent Space Q&A embedded in the same video.

Concrete takeaway: The operating principle is "code is free, so the scarce resources are human time, human/model attention, and context window." The most reusable mechanic: "garbage collection day" — every Friday, every engineer's entire job is to take every piece of "slop" a human caught in review that week and convert it into something that categorically prevents recurrence: a custom lint rule, a structural test ("no file over 350 lines," "no duplicate Zod schemas across files"), or a persona-scoped review agent (front-end architect, reliability engineer, scalability engineer) that runs automatically on every push. This converts one-time synchronous human correction into a permanent, reusable guardrail — "leverage stacks." He also treats plans as risky: he doesn't read plan-mode output before approving because "if you do use a plan and you approve it without reading it at all, you're actually encoding a bunch of instructions that you don't necessarily want followed" — his fix is to push the plan itself as a separate PR that a human actually reads line-by-line before the build kicks off.

Directly exploitable: this is close to a spec for the missing piece in the routing doctrine — a recurring cadence (weekly, or after N corrections) that converts repeated human interventions on this system (e.g., "stop doing X" corrections mid-session) into durable hooks/CLAUDE.md rules/lint-equivalents instead of re-explaining the same correction to the next fresh agent. Also a sharp warning for Opus-as-orchestrator: plan output that's rubber-stamped without being read is "encoding instructions you don't want followed" — argues for the plan itself going through a lightweight human-read gate, distinct from the execution gate.

Source:

— AI Engineer / AI Native Dev — 2026-04-17 (46:20) Quote: "Every time I have to type continue to the agent is like a failure of the harness to provide enough context around what it means to continue to completion." Quote: "our entire job was to take every bit of slop we had observed over the course of the week that was making a PR difficult to merge and figure out ways to categorically eliminate it from ever happening in the first place."

3. Harness engineering beyond skills: Using sensors to keep your coding agent in check — Birgitta Böckeler & Chris Ford (Thoughtworks)

Why high-signal: A structured taxonomy talk (not a demo) that gives vocabulary the other two talks lack. Böckeler is the Thoughtworks author whose "harness engineering" article both Ryan Lopopolo's talk and this one reference — this is the deep-dive follow-up to that article, run as a two-person live experiment rather than a keynote.

Concrete takeaway: Splits harness inputs into a 2x2: feedforward vs. feedback, each split into inferential (LLM-judged) vs. computational (deterministic). Feedforward = guides (agents.md, rules, skills — "the battle of the markdown files") anticipating what might go wrong. Feedback = sensors (linters, type checkers, mutation testing, dependency-cruiser, review agents) that catch what actually went wrong after generation. The generative insight: "harness engineering is kind of a special... subform of context engineering" and the open research question worth stealing verbatim — "when you have good sensors, how many guides can you actually just delete?" — i.e. a deterministic check that fires 40% of the time may out-perform a natural-language instruction the model only follows 60% of the time, at lower token cost. Concrete finding from her own experiment (same feature, same model, with/without sensors): without sensors, test coverage dropped and lint errors rose; with sensors, folder/module structure stayed consistent because dependency-cruiser enforced it, while the un-sensored run had the agent silently choose its own folder conventions. Also flags a specific gaming failure mode — 100% statement coverage but zero real unit tests (only reached via an unrelated acceptance test), caught only by mutation testing, not coverage.

Directly exploitable: this gives Mission Control a vocabulary to audit its own routing matrix — the CLAUDE.md doctrine is currently almost entirely "guides" (feedforward, inferential: prose instructions). The talk argues the trust/attention payoff is in computational feedback sensors layered in front of or alongside guides — e.g. a hook that fails a PreToolUse check deterministically (subagent cap enforcement is explicitly flagged elsewhere in this system's doctrine as needing to move from "prompt instructions" to "hook enforcement" — this talk is independent confirmation of exactly that instinct from a different practitioner).

Source:

— Thoughtworks — 2026-04-24 (56:27) Quote: "harness engineering is kind of a special... subform of context engineering I would say." Quote: "So there's also this question of like how do you even know that your skills make things better or worse... I also have a suspicion that lots of teams right now they just throw like a lot of text at the agent but they don't even know which of that is helpful or not... it's kind of superstitious somehow."

4. Effective Agents: A Builder's Guide to Working with AI — George Stagg (Posit), "AI in Production 2026" (Jumping Rivers)

Why high-signal: The most recent video in this sweep (published the day before this research ran) and the most mechanically concrete — it's a rebuild post-mortem for Posit Assistant (the RStudio/Positron AI pane), with live-demoed failure modes rather than slideware claims.

Concrete takeaway: Three durable, narrowly technical findings. (1) Models will confidently describe tool output they never received. He rigged a demo where the "image" returned from a plotting tool was literally the string "image," not image data — Claude described the plot in accurate, plausible detail anyway, because for a famous dataset (mtcars) it "saw what it expected to see" rather than what was actually sent. Cites a research finding that most frontier models get this wrong when a well-known dataset's plot is deliberately flipped. Practical rule: never ask the model why it did something — introspection is unreliable and conversation history can be forged (since the full history is resent every turn); instead inspect raw wire traffic with a MITM proxy (Proxyman/Charles) when app-level logging isn't enough. (2) Prompt caching is fragile to two specific mistakes: changing the system prompt per-turn, or changing which tools are available per-turn, both fully invalidate the cache (his team was accidentally paying 100% price after previously hitting 80-90% cache rates, from a template system that varied the system prompt by console language). Workaround: inject context via XML tags in the user message instead of touching the system prompt. (3) Never pipe large raw tool output (e.g. log files) directly into context — write it to disk and hand the model the path instead, because models are specifically trained to grep/search/read large files via tools, not to receive them inline.

Directly exploitable: (1) is a concrete verification-loop lesson — an evaluator/QA sub-agent claiming to have "checked the browser/screenshot/output" should be spot-audited against raw traces, not trusted on its own report, echoing the Anthropic talk's "read the whole trace" discipline. (2) and (3) are literal cache-hit-rate and context-bloat bugs worth auditing in this system's own sub-agent/hook wiring — e.g. any hook or skill that swaps system-prompt content or toggles tool availability per turn is silently killing prompt-cache economics.

Source:

— Jumping Rivers ("AI in Production 2026") — 2026-07-06 (26:27) Quote: "Claude is a liar. He will barefaced lie to you again and again... don't just ask the LLM why it did something... check the raw data underneath." Quote: "if you are thinking of using caching, some top tips, try not to change the system prompt... you'll find that changing the system prompt completely invalidates the caching."

5. Devin's 80% Moment: Background Agents, 7x PRs, & End of Hand-Held Coding — Walden Yan (Cognition CPO) & Cole Murray (open-inspect), Latent Space

Why high-signal: Production-scale numbers from the team running Devin at Cognition's own internal scale, not a demo — a hard data point on how far background-agent adoption has actually gone inside one real engineering org, plus a specific architectural claim about multi-model orchestration for testing.

Concrete takeaway: Devin's own commit share of all commits on Devin's repos went from 16% in January to 80% in March 2026 (2 months), while merged-PR volume grew 7x over roughly the same window against only ~10% engineering headcount growth — offered as the concrete threshold where "background agent" stopped being a toy and became the default path. On the technical side: for cross-stack changes (frontend + backend), Cognition found no single frontier model can reliably do the full spec→tested-PR loop end to end — they specifically orchestrate different frontier models together for the verification/testing stage rather than using one model throughout, distinct from using a weaker model to save cost. Also a clean architectural framing for sub-agent scaling decisions: "if the harness is in the box, you can spin up more boxes" — i.e., whether the agent harness process lives inside the sandboxed compute unit (easy to fan out — just start more sandboxes) or outside it (you now own an unmanaged "pet" process spanning worker planes) is the actual constraint on how cheaply you can parallelize sub-agents, not model capability.

Directly exploitable: independent confirmation of this system's routing-matrix instinct to route different stages of one loop to different models rather than picking one model for a whole task (Opus for planning/orchestration, Sonnet for execution is the existing doctrine) — Cognition applies the same split specifically to the verification stage, suggesting the review/QA stage of any Mission Control loop is itself a candidate for a distinct, possibly non-default model rather than inheriting whatever built the code.

Source:

— Latent Space — 2026-05-28 (1:09:32) Quote: "Devon commit percentages on all Devon repos uh was 16% in January and now 80% in March." Quote: "we actually — no one frontier model can actually do this full end to end task itself. We've seen cases where we actually had to orchestrate different frontier models together to kind of solve this problem together."

Honest nulls

• Searched explicitly for named practitioners referenced in the dedup docs (swyx, indydevdan, Peter Steinberger) with loop-specific queries — no new 90-day video surfaced beyond what's already banked in RESEARCH_video_insights.md (the cmux/IndyDevDan video) and RESEARCH_top_voices*.md. Steinberger's most relevant recent hit (Lex Fridman clip, Feb 2026) is outside the "conference talk / deep-dive" bar this lane was asked to prioritize and is closer to a podcast pull-quote than substance.
• Several "Loop Engineering" titled videos surfaced (Prompt Engineering channel, Nate Herk, Ray Amjad, Hyperautomation Labs, Tech with Homayoun) but on inspection these are explainer/reaction content repackaging the term rather than original practitioner substance — skipped per "skip thumbnails-and-hype" instruction.
• MLOps.community "2026: The Year of Agent Orchestration" (2026-03-31) and No Priors' Karpathy interview (2026-03-20) were both just outside the 90-day window (cutoff ~2026-04-08) and excluded on that basis, not on quality.

Lane 4 — Chinese ecosystem (Bilibili/XHS/V2EX)

Lane 4 — Chinese Agent-Dev Ecosystem (Bilibili / Xiaohongshu / V2EX), last ~90 days

Dedup check: grepped RESEARCH_loops2.md and RESEARCH_loops3.md for Chinese-platform / GLM / Qwen / DeepSeek / Manus / Kimi coverage — zero hits beyond passing mentions of GLM/DeepSeek as models in benchmark tables. This ecosystem is confirmed net-new; no overlap to dedupe against.

Tooling used: opencli (agent-reach's OpenCLI backend) — bilibili search/subtitle, xiaohongshu search/note, v2ex latest/topic. Bilibili subtitles were mostly unavailable (no captions, or gated behind login) — findings below lean on titles, engagement, and full XHS note text instead of transcripts.

1. Claude Code's internal 4-loop taxonomy is already circulating as practitioner content

Why high-signal: Two independent Chinese creators, same week, are teaching what they attribute to "the Claude Code team's" framework for classifying agent loops — not by automation level, but by where control is handed off: Round Loop (human checks, AI executes), Goal Loop (human gives the stop condition), Time Loop (human gives the system a trigger/schedule), Active Loop (human hands over the entire process). The stated thesis — "the point isn't more automation, it's that only verifiable tasks are worth automating" — is a sharper framing than anything explicit in our own loop-engineering catalog, which currently organizes by mechanism (cron/goal/self-discovery) rather than by how much control is surrendered.

Concrete takeaway: Re-tag the L1-L11 roster and ~/.claude/skills/loop-engineering/LOOPS.md catalog with a control-handoff axis (Round / Goal / Time / Active) orthogonal to the existing trigger-mechanism axis. Use it as a pre-flight question for any new /loop or /goal config: "which of these four am I actually building, and is the task verifiable enough to deserve that level?" — this doubles as a second lens on the CLAUDE.md rule "no cap, no run" (Time/Active loops without a hard cap are exactly the failure mode this taxonomy warns about).

Source: Xiaohongshu note by 小亦学ai ("Xiaoyi learns AI"), title "Claude Code团队说的4种智能体循环，怎么用" ("How to use the four agent loops the Claude Code team talks about"), published 2026-07-07, 0 likes / 27 collects / 0 comments. Cross-confirmed same day by a second creator, Aihot: "Claude 团队详解四种智能体循环类型" ("Claude team explains the four types of agent loop in detail"), 4 likes. Full translated note text: "Many people think agent loops are simply about letting AI do things automatically, but the Claude Code team really wants to talk about: what part of the control do you actually give to the agent? ... Round Loop: You check, AI executes; Goal Loop: You give the stopping condition to the AI; Time Loop: You give the trigger to the system; Active Loop: You give the entire process to the agent. The key point isn't that the more automated the better, but rather: only verifiable tasks are worth automating." (Note: opencli's note-fetch returned this pre-translated to English; original Chinese title captured verbatim above, but the body's original Chinese wording was not separately recoverable through this tool call.)

2. A 20-pattern Loop Engineering taxonomy, organized into 5 categories

Why high-signal: This is far more granular than any Western-sourced catalog we've mapped so far (loops2/loops3 top out around a handful of named patterns). It cleanly buckets 20 named loop patterns into five families: Quality Improvement (Generate-Review-Rewrite, Scoring-and-Retry, Multi-role Review, Adversarial Review, Multi-Review Integration), Memory Loop (Reflection Loop, Experience Accumulation, Failure Case Library, Best Practices store, Memory Compression), Planning Cycle (Plan-Execute-Replan, Dynamic Flow, Goal Decomposition, Progress Verification, Constraint Satisfaction), Exploration Cycle (Multi-Branch Exploration, Tree Search w/ pruning, Debate Cycle), and System Optimization (Prompt Self-Optimization, Workflow Self-Optimization monitoring latency/cost/quality). Several of these (Debate Cycle, Tree Search with pruning, Multi-Review Integration, Workflow Self-Optimization against cost+latency+quality jointly) are patterns our existing loop-engineering catalog does not name explicitly.

Concrete takeaway: Use this as a gap-check against ~/.claude/skills/loop-engineering/LOOPS.md — specifically add "Exploration Cycle" (tree-search-with-pruning, structured debate between two adversarial sub-agents) as a distinct pattern family, since the current roster mostly covers Quality/Memory/Planning-shaped loops. "Workflow Self-Optimization" (autonomously adjusting the architecture based on tracked delay/cost/quality, not just prompt content) is also a concrete next-tier idea for a meta-loop over the L1-L11 roster itself.

Source: Xiaohongshu note by AI产品经理Charles-途灵 ("AI Product Manager Charles-Tuling"), title "图解Loop Engineering20种模式，一篇看懂！" ("Illustrated Guide to 20 Loop Engineering Patterns: Understand Them All in One Article!"), published 2026-07-07, 66 likes / 127 collects / 7 comments — the highest-engagement loop-taxonomy note found in this sweep. Full pattern list captured in the note fetch (see xhs_note_20patterns.yaml in this ledger's directory).

3. Hermes Agent's "Harness Loop": memory as plain text + local DB, zero embeddings

Why high-signal: This is a hands-on system test (not marketing) of Nous Research's Hermes Agent (cited at 200k GitHub stars), framing the whole system explicitly as one loop: Message arrives → agent runs → tool is invoked → loop ends → memory is stored → skill is learned. The reviewer's headline claim is architecturally provocative and directly contrasts with the user's own gbrain setup: "the most surprising thing is that there's no embedding throughout — skills and user info are simply plain text files, chat history is stored in a local database... its moat is memory, not models." This is a Chinese practitioner independently arriving at a flat-file-over-embeddings position for agent memory, worth weighing against gbrain's embedding-heavy PGLite design (currently openai:text-embedding-3-large@1536, noted in memory as possibly "overkill at ~612 files" per Garry Tan's framing already on file).

Concrete takeaway: (a) Worth a lightweight comparison: for gbrain's actual working set size, does embedding search meaningfully beat grep/plain-text retrieval over skills+memory files? (b) The reviewer also flags two concrete bugs worth checking against — the agent "never proactively stores relatively simple skills" and "a cron bug" — cross-check against the user's own Hermes OAuth/billing troubleshooting notes already in memory (troubleshooting_hermes_claude_oauth.md) in case these are related or already known.

Source: Xiaohongshu note by Sean (肖恩君Sean), title "一口气学会HermesAI智能体Harness Loop系统" ("Learn the Hermes AI agent Harness Loop system in one go"), published 2026-07-05, 207 likes / 261 collects / 6 comments — second-highest engagement in this sweep. Full translated text: "I sent my AI a 'Good morning' message on WhatsApp, and it replied with 'pika pika' before getting to work. This is Hermes Agent... It's garnered 200,000 stars on GitHub in less than a year and even learns new skills on its own. This week I did a full system test... The entire system is a loop: Message arrives → agent runs → tool is invoked → loop ends → memory is stored → skills are learned. The most surprising thing is that there's no embedding throughout. Skills and user information are simply plain text files, and chat history is stored in a local database... Its moat is memory, not models. I also found two issues: it never actively stores relatively simple skills, plus a cron bug."

4. V2EX: a skill built specifically to "clone" Fable 5's behavior before its access window closes

Why high-signal: This is the exact situation the user's own routing doctrine is written around — Fable 5 credit-metered / on an access countdown ("延到 12 号了" — pushed back to the 12th) — and a V2EX user's response was to have Fable 5 author a portable Claude Skill that makes any other coding agent imitate Fable's own behavior, open-sourced as fiber5. This is a distinct technique from anything in loops2/loops3: distilling a soon-unavailable/expensive model's behavioral signature into a transferable skill file, rather than just routing away from it.

Concrete takeaway: Worth cloning github.com/ryougifujino/fiber5 and running a quick eval — does the extracted skill actually reproduce Fable's long-horizon-autonomy behavior on Sonnet/Opus, or is it closer to a stylistic veneer? If it holds up even partially, it's a cheap hedge against Fable's credit-metering (a "skill capsule" that survives the model's own deprecation/access window) and directly relevant to the "Fable 5 = walk-away autonomy only, always via pxpipe" routing line in CLAUDE.md.

Source: V2EX topic #1225710, node 分享创造 (Share & Create), posted by user ryougifujino, first page of V2EX's "latest" feed at capture time (2026-07-07), 0 replies. Original: "Fable 5 不是快到期了嘛（虽然又延到 12 号了），突发奇想不如让它写一个模仿它的 skill，大家可以试试。 github.com/ryougifujino/fiber5" → English: "Isn't Fable 5 about to expire? (though it's been pushed back to the 12th again) — had a sudden idea: why not have it write a skill that mimics itself. Everyone's welcome to try it." Note: V2EX's OpenCLI adapter has no native full-text search endpoint (only hot/latest/node/nodes/topic/user/member), so this was surfaced by scanning the front page of latest, not targeted keyword search — a real coverage gap for future sweeps of this platform.

5. "Loop Engineering" as the explicit successor to prompt engineering — a recurring framing across ≥5 independent Chinese creators in one week

Why high-signal: This isn't one blogger's take — it's the same framing, independently, across at least five separate Xiaohongshu accounts plus a dedicated two-part Bilibili series, all within 2026-06-28 to 2026-07-07: "Prompt is dead, Loop is king" / "Stop prompting — Agent Loop is the skill you should be learning" / "The 'Loop Engineering' top AI users are all using." The Bilibili series explicitly states the thesis: "AI Agent 的下一层能力，不是写提示词，而是设计循环" ("AI Agent's next-level capability isn't writing prompts, it's designing loops"). This suggests "loop engineering" as a named discipline (matching this project's own skill name) is having a real trend-moment in the Chinese dev community concurrently with the Western one this sweep series has been tracking — not a lagging echo.

Concrete takeaway: These are candidate accounts to monitor for future pattern-mining (唐国梁Tommy on Bilibili; 马丁没有早晨, 是泡泡子(AI版), 韩捶捶, 彦如玉 on Xiaohongshu) — several are clearly translating/adapting Western "agent loop" content for a Chinese audience in near-real-time (same-week turnaround), which makes them a fast secondary signal channel, not just a mirror.

Source: Bilibili channel 唐国梁Tommy — "AI Agent 的底层其实就是一个 while 循环？Agent Loop 核心机制完整讲解" (BV1SGTv6iEmZ, 1,941 views) and "Loop Engineering：从 Prompt 到 Agent 循环的范式迁移｜AI Agent 的下一层能力，不是写提示词，而是设计循环" (BV1rmT16pEfj, 964 views), both undated-but-current in search ranking (no captions available to confirm exact publish date). Cross-confirmed on Xiaohongshu: 彦如玉 "Prompt已死，Loop当立" ("Prompt is dead, Loop must rise", 2026-07-07, 16 likes); 韩捶捶 "别再只学Prompt了" ("Stop only learning Prompt", 2026-07-06); 马丁没有早晨 "别再提示了：Agent Loop才是你该学的新技能" ("Stop prompting: Agent Loop is the new skill you should learn", 2026-07-01, 6 likes) and "顶级AI用户都在用的「循环工程」" ("The 'Loop Engineering' top AI users are all using", 2026-07-06, 4 likes); 是泡泡子(AI版) "还在一句句指挥 Codex ？高手都在搭循环Loop" ("Still commanding Codex sentence by sentence? Experts are all building loops", 2026-06-28, 36 likes).

Honest nulls / platform notes

• GLM/智谱 + DeepSeek + agent-loop intersection: thin. Queries for "GLM 智能体 循环" surfaced only general GLM-5.2 reviews (usage reports, an "overexplaining/overthinking" complaint thread, a 6,690-comment sentiment analysis) — none specifically about loop/harness design with GLM as the driving model. No loop-specific GLM content found in top 10 for this query on either platform in the ~90-day window.
• Manus: Bilibili results for "Manus 工作流" were dominated by basic "how to sign up for Manus" tutorials, not workflow/loop design content. No high-signal Manus-specific loop content surfaced.
• Kimi / 通义 Qwen: not separately queried due to time budget — flagging as a gap for a future pass rather than reporting a false null.
• V2EX: confirmed no native search in the OpenCLI adapter (hot/latest/node/topic/user only); coverage here is a snapshot of the front page at capture time, not a targeted search — treat item 4 as representative of what's findable this way, not exhaustive.
• Bilibili subtitles: mostly unavailable — either no captions exist (EMPTY_RESULT) or gated behind a bilibili.com login (AUTH_REQUIRED) that this sweep didn't attempt (out of scope: no logins/installs). Findings rely on titles + engagement rather than transcript text.

Lane 5 — GitHub + newsletters

LOOPS, LANE 5 — GitHub trending + newsletters/blogs (2026-07-07, last ~90 days)

Scope: GitHub trending/new loop repos (verified via gh repo view/gh api) + high-signal newsletter/blog pieces on agent-loop architecture. Deduped against RESEARCH_loops2.md, RESEARCH_loops3.md, RESEARCH_toolbelt.md, RESEARCH_hn_spree.md — none of the 7 items below (nanobots, ralph-loop, claude-code-loop-patterns, forge-orchestrator, GEPA, HarnessFix, gbrain skillopt, etc.) recur here. gh search repos on fixed query strings mostly returns today's noise-flood of AI-slop-named repos (sort=updated surfaces anything touched today, not anything real) — filtered hard for real star counts, real READMEs, and live activity.

1. ratchet-loop — maker-never-grades-itself as a tiny, tested npm primitive

Why high-signal: it's the cleanest, smallest working implementation found anywhere in this whole loop-research campaign (across 3 volumes) of the single rule every safety-lane source converges on — "the thing that writes the code never decides whether it worked." Real CI, real npm package, deterministic test suite that proves the rule in code, not prose. Caveat: created literally today (2026-07-07), 0 stars — judge the mechanic, not the traction.

Concrete mechanic (implementable today):

• createLoop({ goal, generate, check, maxAttempts }).run() — generate (the "maker," any model) and check (the "judge," a real shell command / test runner) are separate function inputs; the library core imports zero LLM providers.
• Stop-hook rule: a self-reported "done" from the model never stops the loop. When the model claims success and check() fails, it emits claim_rejected and keeps going — the signature behavior is proven by a deterministic test with no model involved at all (fake maker claims done, fake check disagrees, suite asserts the loop continues).
• State written atomically to .ratchet/state.json after every attempt — kill mid-run, rerun, it resumes at the next attempt with full history and budget intact (no re-derivation from a transcript).
• Git-safe by construction: local commit only on a passing check; push is typed false with no push code path in the library at all — a structural (not policy) guarantee.
• Comparison table it ships in its own README nails the exact axis: Vercel AI SDK stops on finishReason, OpenAI Agents SDK stops on the model's own final output, a hand-rolled while stops on "whatever the body decides" — ratchet-loop is deliberately just the missing stop condition, not a full agent framework, and is designed to wrap around either SDK.

Exploit for this system: this is a literal, drop-in implementation of the "independently arbitrated exit condition" guardrail from RESEARCH_loops2's Lane 3 synthesis (item 6, termination poisoning) and the L11 spec's "never trust self-reported done." For any L-tier loop where the worker is Claude Code and the checker is a real command (tests, typecheck, build), this is a 5-minute wrapper rather than hand-rolling the maker/checker split and the resume-on-crash state file — worth a trial run around one write-capable loop (e.g. a future PR-fixer loop) before building that plumbing from scratch.

Source: github.com/antronaut-labs-dev/ratchet-loop — created 2026-07-07, pushed 2026-07-07, 0★, MIT, npm ratchet-loop, CI green. README fetched via gh api.

2. loop-harness (lSAAGl) — bash multi-loop orchestrator with a verifier-gate + dashboard, near-exact analog to L1-L11

Why high-signal: this is the closest working, shipped system found to what L1-L11 already is architecturally — a scheduler running multiple named loops, each in worktree isolation, each gated by a second skeptical agent before anything ships — but small enough (bash + jq + gh CLI, no framework) to actually read end to end and steal pieces from.

Concrete mechanic:

scheduler tick → due loop → git worktree → primary agent (claude -p + skill)
                                  ↓
                     staged output (commits / outbox files)
                                  ↓
                  verifier agent (claude -p, skeptical) — FAIL → log + retry next cycle
                                  ↓ PASS
                  ship: push + PR / post comments / Slack → state updated

• Staged outputs, not direct side effects: the primary agent cannot post or push directly — it stages commits, a PR_BODY.md, or "outbox" action files (issue-comment-<n>.md, pr-approve-<n>.md); only the orchestrator, after the verifier passes, actually ships.
• Verifier agent is explicitly "skeptical" (a persona instruction, not just a second neutral pass) and must literally print VERDICT: PASS before the orchestrator proceeds — directly matches Dan Luu's contrarian-persona finding (already banked in RESEARCH_hn_spree Lane D #1) but as a shipped mechanism rather than a research claim.
• Idempotence via state-file dedup of processed item IDs (CI run IDs, issue/PR numbers, package@version, commit SHAs) — reruns are always safe, a cheap primitive missing from most of the loop repos surveyed so far.
• Ships 5 starter loops (triage-ci every 10m, issue-groomer hourly, pr-reviewer every 3m, dependency-updater daily, doc-sync daily) each declared with cadence + allowed_tools scoping per loop, plus a live dashboard.sh status table (cadence, last run, success%, avg duration, failure count) across all loops — a working reference for the "Loop Health Board" Mission Control feature flagged as the #1 buildable action in RESEARCH_loops3.
• ./orchestrator.sh tick runs exactly one scheduler pass — drivable from cron/launchd instead of its own daemon, meaning the whole thing is adoptable piecemeal.

Exploit for this system: the per-loop allowed_tools scoping + staged-outbox-file pattern is a concrete answer to "how does a launchd-driven loop avoid ever having direct push/post capability" — cleaner than trusting the agent's own restraint. Worth reading orchestrator.sh directly before the next L-tier build that writes anything externally (PR, Slack message); the dashboard table format is also a ready-made schema for the Loop Health Board TODO.

Source: github.com/lSAAGl/loop-harness — created 2026-06-10, 7★, MIT-style, README + safety model fetched via gh api.

3. rudder (Undertone0809) — explicit, reviewable lesson-promotion as a product primitive

Why high-signal: 220★, active today, and it's the sharpest concrete counter-example found to the "just let the loop auto-write its own learnings" failure mode flagged in RESEARCH_loops3 (item 7, the ungated "Self-improving CLAUDE.md files" cautionary baseline) — rudder makes promotion of a lesson into a reusable skill a distinct, explicit, human-reviewable step rather than something that happens implicitly inside a chat transcript.

Concrete mechanic:

• Named work loop as the product's own spine: Goal -> Issue -> Agent run -> Review -> Feedback -> Learning -> Better future runs — every "Issue" traces back to an org "Goal," so nothing an agent works on is untethered from a reviewable reason for existing.
• Explicit statement of the guardrail this whole ledger keeps re-finding, in the maintainer's own words: "Rudder does not assume every lesson is automatically promoted into a new skill or workflow. The product direction is to make those promotion paths explicit, reviewable, and reusable instead of leaving them buried in chat transcripts or one-off prompts."
• Maps human-org coordination primitives 1:1 onto agent-team primitives (mission→org goal, employees→agents, org chart→agent reporting structure, manager check-ins→agent heartbeats, executive review→board approvals, budget discipline→spend tracking + hard stops) — a clean, reusable vocabulary for describing a fleet of loops as a "team" rather than N independent cron jobs, directly applicable to naming/organizing L1-L11 as a legible structure instead of a flat numbered list.
• Runtime/model-agnostic by design — coordinates agents without forcing one runtime, model, prompt format, or execution environment, i.e. it's a control-plane layer, not a competing agent framework.

Exploit for this system: the "promotion path must be explicit and reviewable, never implicit" line is a sharper phrasing of L11's own "never self-apply" rule, now specifically applied to the skill-promotion half of the problem (not just the CLAUDE.md-edit half) — worth citing directly in the L11 build spec's "reference implementations to mirror" list alongside gbrain skillopt. The org-goal→issue traceability requirement is also a good audit question to run against ~/loops/state: does every active loop's output trace back to a written reason it exists, or are any of L1-L11 running on inertia alone?

Source: github.com/Undertone0809/rudder — created 2026-03-30, pushed 2026-07-07, 220★, README fetched via gh api.

4. Raven / EverOS (EverMind-AI) — "memory-first" self-improving harness, Agent Templates as a portable unit

Why high-signal: 883★, most-starred net-new repo in this sweep, actively pushed today — worth logging as the highest-traction OSS bet currently running on "the harness around the agent is the product," a thesis this ledger's dedup base already treats as directionally right but hasn't seen a well-funded (12 messaging-gateway integrations, HuggingFace org, Discord community) implementation of.

Concrete mechanic:

• Three-way memory split kept durable and separate across sessions: user memory, agent memory, and world knowledge — explicitly named as distinct stores, not one blob, so a fact about the user, a fact the agent learned about its own tool behavior, and a general world fact don't get conflated or evicted by the same policy.
• Agent Templates: a successful workflow can be promoted into a shareable, reusable "digital worker" definition — the harness layer (tools, skills, memory config, policies) is bundled as one portable artifact a builder can start from, rather than every new agent rebuilding the harness from scratch.
• Explicitly named failure modes it's positioned against (its own "Why Raven" pitch): sessions overflowing context and losing details, every turn re-sending the same system prompt/skills/ tool defs (no caching of the constant parts), the agent staying passive even when it can see something actionable, and useful workflows staying "trapped in chat history instead of becoming reusable skills" — the last one is the same core problem rudder (#3) and nanobots (already banked) both solve differently; three independent projects converging on "chat history is not where a lesson should live" is a useful cross-check.

Exploit for this system: the three-way memory split (user / agent / world) is a cleaner mental model than this system's current binary (gbrain = curated knowledge, extract-approach = hard-won insights) for deciding where a new fact belongs — worth a five-minute gut-check the next time gbrain's RESOLVER.md routing rules get revisited, specifically whether "agent learned X about its own tool behavior" (as opposed to a fact about a person/company) has a clear home today. Agent Templates is a portable-unit idea worth comparing against the private skill library + .claude/agents/ — is a subagent definition currently bundled with the memory/policy context it needs, or does that live elsewhere?

Source: github.com/EverMind-AI/Raven — created 2026-05-21, pushed 2026-07-07T15:27Z, 883★, README fetched via gh api; built on sibling repo EverMind-AI/EverOS.

5. awesome-loop-engineering (ChaoYue0307) — a curated field guide that names "Loop Engineering" as a layer above prompt/context/harness engineering

Why high-signal: low stars (19) but this is a genuinely new meta-find worth logging even though the user's own loop-engineering skill already exists independently — it's the first curated, structured (380 resources, 15 named patterns, a symptom-indexed pattern matrix) public attempt found to formalize "Loop Engineering" as its own named discipline distinct from prompt/ context/harness engineering, with a "choose your loop by symptom" table strikingly close in spirit to the private skill's own design.

Concrete mechanic:

• Explicit four-layer stack: Prompt engineering = what do I say to the model; Context engineering = what state/knowledge does the model see; Harness engineering = what tools/permissions/tests/sandboxes surround one agent run; Loop Engineering = what recurring system discovers work, delegates, verifies, persists state, decides next actions, and re-runs when the human is no longer in the inner loop.
• "Choose Your Loop" table maps a plain-English symptom directly to a named pattern (e.g. "My PR is stuck" → PR babysitter loop, "CI keeps failing" → CI repair loop), each linked to a full write-up plus a comparison matrix (patterns/MATRIX.md) — a symptom-first navigation structure worth comparing against how this user's own loop-engineering skill and LOOPS.md catalog are organized.
• Explicit Loop Contract and Loop Maturity Model sections (not fetched in full this pass — worth a follow-up read) alongside a dedicated "Critiques, Risks, And Limitations" section, i.e. the list doesn't just catalog wins.

Exploit for this system: a five-minute skim of patterns/MATRIX.md and the Loop Maturity Model section (not pulled in this pass — budget-limited) is the highest-value next step; if its pattern taxonomy or maturity levels differ meaningfully from the existing loop-engineering skill's own framing, that's a cheap source of blind-spot-check content for the next skill revision. Lower priority than items 1-4 given its own small footprint, but cite-worthy as the first public attempt to name this exact discipline.

Source: github.com/ChaoYue0307/awesome-loop-engineering — 19★, active, CC0-1.0, README fetched via gh api; companion HuggingFace dataset at huggingface.co/datasets/cy0307/awesome-loop-engineering.

6. Addy Osmani — "Agent Harness Engineering" (blog, 2026-04-19) — the "Ratchet Principle" and a hard tool-count budget

Why high-signal: Addy Osmani (Google Chrome DevRel lead, high-reach independent voice, not selling a product) writing a dense, mechanics-first piece on exactly the harness layer this system's routing doctrine already leans on ("Model + Harness. If you're not the model, you're the harness.") — barely inside the 90-day window (2026-04-19) but net-new to every prior sweep's dedup base.

Concrete mechanic (8 named patterns, condensed):

• The Ratchet Principle: treat every agent mistake as a permanent signal — encode the fix directly into the harness (an AGENTS.md line, a pre-commit hook, a test wired back into the loop) so the same mistake becomes structurally harder to repeat, rather than re-explaining it in the next prompt. (Naming convergence worth noting: item #1's ratchet-loop repo independently arrived at "ratchet" for a related-but-distinct idea — that a loop only commits forward on verified progress. Two unrelated authors reaching for the same metaphor for "irreversible progress under a real check" is a decent signal the metaphor is doing real work.)
• AGENTS.md under 60 lines, every rule traceable to a specific past failure or external constraint — a hard anti-bloat discipline, directly relevant given this user's own CLAUDE.md is long and dense; a candidate audit question: which lines in the current CLAUDE.md/global memory trace to a specific documented failure vs. general best-practice prose that could live elsewhere (skills, hooks) instead.
• Tool-count budget: ~10 focused tools, not 50 overlapping ones — tool descriptions occupy every prompt turn, so breadth has a real, recurring cost; a concrete number to check this system's own MCP-tool surface against (90+ deferred MCP tools currently registered per the system reminder in this very session — worth a periodic audit of which are load-bearing).
• "Sprint contracts": have the agent negotiate explicit done-conditions before work begins, rather than grading its own completion after the fact — a lighter-weight cousin of ratchet-loop's check() function, phrased as a negotiation step rather than a mechanism.
• Success is silent, failures are verbose: hook output should stay quiet on pass and surface errors directly and loudly to the agent for self-correction — a concrete UX rule for any PreToolUse/PostToolUse hook this system adds.

Exploit for this system: two cheap, concrete audits worth running: (1) count active MCP tools against the ~10-tool budget claim and flag idle ones for disabling (this also independently corroborates the "idle MCPs tax every turn" finding already banked in RESEARCH_hn_spree Lane C #5); (2) spot-check whether CLAUDE.md's load-bearing lines each trace to a named past failure — Osmani's discipline gives a concrete acceptance test ("if you can't name the behaviour a component exists to deliver, it probably shouldn't be there") for the next CLAUDE.md prune pass.

Source: addyosmani.com/blog/agent-harness-engineering/ — published 2026-04-19, fetched via WebFetch.

7. Latent Space — "AIEWF Daily Dispatch: The Great Loops Debate" (2026-07-03) — the strategic disagreement underneath every mechanical loop pattern

Why high-signal: a live conference-panel dispatch (AI Engineer World's Fair), in-window (2026-07-03), naming the actual industry disagreement about loops that every mechanical pattern in this ledger sits on top of — useful as framing/color rather than a new mechanic, and a good one-paragraph gut-check before over-investing in loop tooling.

Concrete claims/positions (not a mechanic, a debate):

• Pro-loop: Geoffrey Huntley (creator of the Ralph Loop pattern, already banked as ralph-loop in RESEARCH_loops2) argues loops are inevitable and already here — "I don't see myself going back to writing code by hand" — and frames the engineer's job as a "locomotive engineer" keeping automation "on the rails," not driving by hand. Ian Livingstone (Keycard CEO): verifiability is what matters regardless of how code gets produced; loops just accelerate the existing try→learn→apply cycle.
• Skeptical: Dex Horthy (HumanLayer) draws a sharp line between deterministic loops (his example: Kubernetes control loops) and today's agentic loops — his core worry, verbatim- paraphrased: "the hype is outrunning the discipline," and his prescription is to step down a level of abstraction rather than up (i.e. simplify the loop before adding another layer on top of it). Greg Pstrucha (Subroutine) pushes the economic-viability question directly: "you cannot orchestrate your problems away by buying more tokens."
• Huntley's own closing hedge: "software factories" (his term for fleets of loops like L1-L11) are the future direction but remain "frontier thinking" and unsolved in practice — even the strongest pro-loop voice in the room doesn't claim it's a solved problem yet.

Exploit for this system: Horthy's "step down an abstraction level, not up" is a useful counterweight to reach for the next time a loop misbehaves — the instinct in a fleet of 11 named loops is to add a 12th supervisory layer (a health board, a meta-loop), but this framing argues the first move on a misbehaving loop should be simplifying that loop's own logic before reaching for more orchestration on top of it. Cheap to apply as a triage question: before building the Loop Health Board (RESEARCH_loops3's #1 action), check whether the specific loops motivating it (e.g. the wiki-compile no-op) actually need a fleet-wide dashboard or just a simpler, more deterministic check inside that one loop.

Source: latent.space/p/aiewf-daily-dispatch-locomotives — Latent Space, published 2026-07-03, fetched via WebFetch.

Honest nulls

• gh search repos --sort updated on every query cluster ("agentic loop," "agent harness," "self-improving agent," "agent runtime," "agent scheduler," "loop orchestrator," "reflection agent") returns an overwhelming flood of same-day, low/zero-star, often auto-generated-looking repos with near-identical AI-slop naming conventions ("2026 Edition," "Guardrails & Memory," "v2.0: Autonomous Coding with Guardrails & Self-Healing") — this appears to be either a mass AI-repo-generation trend or search-gaming; none surfaced real signal beyond what's logged above after star-count and README verification. Flagging so future sweeps don't re-waste budget re-scanning sort=updated — sort=stars combined with a freshness filter on pushedAt is the workable query shape.
• No new newsletter-native piece found from The Batch, Interconnects (Nathan Lambert), Ahead of AI (Sebastian Raschka), TLDR AI, Pragmatic Engineer, or Chip Huyen specifically on loop/ harness architecture in-window that wasn't either already banked (sniffly = Chip Huyen, RESEARCH_toolbelt) or a general model-release / benchmark post out of this ledger's scope — Latent Space and independent blogs (Osmani, danluu/dbreunig/etc. already banked in RESEARCH_hn_spree Lane D) are where the real loop-architecture writing is currently concentrated, not the roundup-style AI newsletters.
• reflection agent / agent scheduler / loop orchestrator query clusters returned mostly tutorial-tier LangGraph course repos (1-11 stars, dated) or enterprise-demo repos with no loop-engineering content worth reporting — no items drawn from those three clusters beyond what's logged above.

Provenance

Method: gh search repos "<query>" --sort updated|stars --limit 20-30 across 6 query clusters, gh repo view + gh api repos/<owner>/<repo>/readme for verification/full-text on 7 candidates, WebSearch + WebFetch for newsletter/blog coverage (Simon Willison, Latent Space, Addy Osmani checked; Simon Willison's most relevant loop post found — "Agentic Engineering Patterns" — dated 2026-02-23, outside the 90-day window, excluded). Budget: ~28 min, no repo writes/installs, no package installs.