Third loop-research push, on the territory the first two didn't map. 4 Sonnet lanes: (A) observability & fleet health, (B) multi-agent topologies & composition, (C) control-theory/cybernetics grounding + rigorous failure taxonomy, (D) emerging 2026 primitives. Deduped against the loop-engineering skill + RESEARCH_loops2.md. ~28 items. The theme: we've built the loops (L1–L11); this is how you RUN a fleet of them without it silently rotting.

TOP ACTIONS (ranked)

1. Build a LOOP HEALTH BOARD in Mission Control (Lane A + C + D converge — the clear #1 buildable). The user runs L1–L11 with no health view; the wiki-compile loop silently no-op'd for days and nothing caught it. Concrete mechanics from the research: a heartbeat / dead-man's-switch per loop that alerts on absence of PROGRESS, not on error (Lane A #4 — the exact thing that would've caught wiki-compile); cost-per-resolved-task, not cost-per-call (Lane A #3 — a real case where per-call cost fell 25% while per-task cost rose 40%); override-rate bands (<15% healthy, >25% needs rework — Lane A #6); defect vs. drift as two tiers (per-run deterministic checks vs. fleet-wide rolling defect-rate — Lane A #2); and Morph's shipped sub-100ms stuck-in-a-loop classifier (Lane D #6) as a ready detector. This is a natural Mission Control feature — the app already reads ~/loops/state + traces; a Fable+pxpipe build target.

2. Audit every loop's checker against Ashby's Law of Requisite Variety (Lane C — the deepest principle). "Only variety can absorb variety": a checker whose model of "correct" is thinner than the actual failure space will pass broken states in its blind spot — structurally, not as a tuning bug. The Good Regulator theorem sharpens it: the checker IS a regulator and must be a model of the system. Actionable: for each loop, write its real failure taxonomy first, then confirm the checker's signal is as expressive as that space (a tests: pass/fail checker is blind to everything that doesn't move that one variable). Reframes how every loop's verify step is designed.

3. Treat consent-fatigue as the #1 real failure of human-gated loops (Lane C — Microsoft Failure-Modes Taxonomy v2.0, 2026-06). The most-EXPLOITED failure mode in agentic systems is HitL bypass via consent fatigue — gates fail by rubber-stamping, not clever attack. Implication for L11's own gate and the /goal pasted-proof doctrine: don't rely on click-through as the safety boundary — force a real read on a sampled or high-risk fraction of approvals. (This is exactly why the L11 human gate must stay a genuine review, not a reflex.)

4. Grounded verify-loops are the cheap-model unlock, now with hard numbers (Lane D — IronBee, 2026-07-07). First quantified benchmark: a grounded verify-loop took DeepSeek from 20.4 → 80.6 (matching Opus) at ~1/7th Opus's cost. Validates the harness-over-model thesis (cf. Forge's 53→99 on an 8B) with a fresh datapoint — wrap cheap-model work in a grounded verify loop before escalating models. Feeds the routing matrix.

5. Blackboard coordination + stale-lock-safe fleet mechanics (Lane B). Google's bMAS paper: workers self-selecting off a shared blackboard beat master-slave assignment by 13–57% — validates the SQLite-blackboard instinct with benchmarks. forge-orchestrator (128★, live) is a shipped reference for exactly the ~/loops/state shared-state + event-log + file-locks + drift-detection + MCP-exposure pattern. Fleet hygiene: stale-lock-safe locks (owner-token compare-and-delete) + idempotency keys as the real double-effect net + per-agent token circuit breakers against documented 10–100× cost multipliers. Caution (Lane B #1): decentralizing costs +285% tokens — only leave orchestrator-worker when the task genuinely needs it.

Honest nulls (Lane D): no fresh A2A protocol release in-window; no Temporal/Inngest agent-loop feature — the durable-execution frontier this cycle shifted from raw crash-safety to verifiable execution lineage (Dapr v1.18 signed workflow history).

Lane A

Lane A — Loop Observability & Operational Health (fleet ops for L1-L11)

1. Fleet-level "control plane" pattern: health score + alert feed + drill-down, built on OTel GenAI semconv

Why it matters for a loop fleet: This is Microsoft's actual shipped answer to "I run a dozen agents, how do I not manually tail logs for each one." It's a concrete blueprint for a Mission Control "loop health board" rather than a philosophy. Concrete mechanic: Every loop emits OpenTelemetry traces following the GenAI semantic conventions (one shared schema across all agents, not bespoke per-loop logging). A control-plane layer aggregates these into: (a) an Overview pane with trend-based fleet health score, alert summary, active-agent count, error-rate trend, compliance metrics, filterable by date range; (b) an Assets > Agents tab listing every registered agent with top-level metrics (error rate over time, run count, token usage); (c) per-agent drill-down showing active alerts grouped by severity (policy/security/evaluation) plus recent activity. Buildable analog for L1-L11: standardize a JSON heartbeat line per loop run (loop id, outcome, cost, duration, alert flags) written to one shared log; a single dashboard script aggregates across all ~/Library/LaunchAgents / cron loops instead of N separate log-tail habits. Source: Monitor AI agent fleet health and performance — Microsoft Learn / Azure Foundry Control Plane (dated 2026-05-12)

2. Defect vs. drift are different signals, caught by different mechanisms — and the drift-judge itself needs versioning

Why it matters for a loop fleet: Directly answers "how do you notice a loop has silently degraded" — the failure mode the user hit with the wiki-compile loop. Gives a non-vague operational split instead of "monitor for degradation." Concrete mechanic: Two-tier detection. (1) Per-run defect check, cheap and mostly deterministic: compute a distinct-tool-argument (or distinct-action) entropy ratio and flag runs below a 0.4 threshold as suspiciously repetitive/no-op-y; separately run structural checks with zero model calls — illegal state transitions against a per-loop allow-list, excessive looping (>4 revisits to the same state), dead-end halts. Only escalate to one fenced LLM-judge call per run, returning a strict enum (tool_entropy, role_drift, execution_gap), never free text. (2) Fleet-wide drift is the population signal: the per-run defect rate rising across a rolling window — not any single bad run. (3) Guardrail: the LLM judge prompt itself is versioned (e.g. clear-v1-2026-06) so that when defect-detection accuracy shifts, you can tell "the loop drifted" from "the judge drifted." A KILL_SWITCH env var can disable the judge entirely and fall back to deterministic-only signals. Source: Vadim Nicolai — Detecting Agent Defects & Drift in Production (2026-06-15)

3. Cost-per-resolved-task / Failure Cost Share exposes budget drift that cost-per-call hides

Why it matters for a loop fleet: Answers the cost-economics angle directly, with a real worked failure case: teams that only watch per-call/per-token cost can look like they're improving while actually getting worse, because rising retries/turns per task hide behind falling unit price. Concrete mechanic: Track two numbers per loop, not one: (a) cost-per-call (what most token dashboards already show) and (b) cost-per-resolved-task = total fully-loaded spend (including failed attempts, retries, abandoned runs, escalations, shadow-mode evals) ÷ count of accepted/resolved outcomes only. Report Failure Cost Share alongside it: % of total loop spend that produced no accepted outcome, broken out by failure mode (rejected / abandoned / timed-out / tool-error / escalated). The cited case: cost-per-call fell 25% quarter over quarter while average turns-per-task drifted 4→7, driving a 40% increase in cost-per-resolved-task that nobody caught because no one owned that specific metric. Directly portable to L1-L11: log token spend AND outcome-acceptance per run so a "fleet cost board" can compute cost-per-resolved-task per loop, not just aggregate token burn. Source: Tian Pan — The Agent Budget That Approved Cost-Per-Call and Never Measured Cost-Per-Resolved-Task (2026-06-02)

4. Heartbeat / dead-man's-switch: alert on absence of progress, not on error, to catch a loop that's "running" but doing nothing

Why it matters for a loop fleet: This is the exact mechanic to have prevented the wiki-compile-loop-can't-read-~/brain bug: a job that exits 0 and "completes" every run while silently doing no useful work looks identical to a healthy loop under normal cron/launchd monitoring (which only checks exit code / process-ran). Concrete mechanic: Instrument a heartbeat ping inside the loop body, after a real-progress checkpoint (e.g. "N new items summarized," "diff applied," "file actually read and non-empty") — not merely at process start/exit. Push it to a dead-man's-switch service (healthchecks.io-style: you register an expected check-in interval + grace period; the absence of a ping past the window is the alert, inverting normal error-based monitoring). This distinguishes "the launchd job fired" from "the loop made forward progress," which is precisely the gap that let a no-op loop run silently for a while. Cheap to self-host: a local cron that checks "last heartbeat timestamp per loop" against expected cadence and pages if stale, no external service required. Source: Healthchecks.io — dead man's switch monitoring docs; Drumbeats — Heartbeat Monitoring for Workers, Daemons & Sync Loops

5. Bake outcome-validation into the loop's own exit logic, not just "did it run" — the classic false-success failure mode

Why it matters for a loop fleet: Practitioner consensus (not a new idea, but a concrete implementable checklist) on the single most common way loops silently degrade: they return success (exit 0 / "task complete") while doing nothing useful — same shape as the wiki-compile bug where Bash couldn't read ~/brain but the loop still "completed." Concrete mechanic: Each loop should assert a semantic postcondition before declaring success, not just check for a clean exit: before/after size or count comparison (e.g. "did the compiled wiki file actually grow / change hash"), a canary read-check (deliberately verify a known-good file is readable at loop start; if that fails, abort loudly instead of silently no-op'ing through the rest), and a minimum-output-size or record-count floor. If any check fails, the exit status/alert should reflect that, not "process completed." For a fleet, this becomes a shared "loop contract": every loop script must emit a machine-readable postcondition result (pass/fail + reason) alongside its normal output so the fleet dashboard can flag "ran but didn't actually do the thing" separately from "crashed." Source: Ask HN: How do you catch cron jobs that "succeed" but produce wrong results? (2026-01-30)

6. Human-override-rate and escalation-appropriateness bands as ready-made alert thresholds

Why it matters for a loop fleet: Gives numeric, not vague, thresholds for "should a human be looking at this loop more" — directly usable as a health-board red/yellow/green rule for loops that page or defer to the user (e.g. babysit, triage). Concrete mechanic: Track override rate = % of the loop's proposed actions/drafts that the human edits or stops. Cited healthy band: under 15% override rate is fine; above 25% means the loop's decision logic (not just its threshold/prompt) needs rework. Separately track escalation-appropriateness = % of the loop's escalations-to-human that were actually necessary in hindsight; target ≥75%, with 55-65% typical for a freshly stood-up loop and 80-90% for a mature one. For a fleet board: compute both per-loop over a trailing window (e.g. 30 runs) and flag any loop crossing the bad-band threshold as a candidate for retuning or pause — a concrete, non-subjective version of "this loop feels annoying now." Source: Fin.ai — AI Agent KPIs: Performance Metrics Framework 2026; Beam.ai — 5 AI Agent Production Metrics Teams Miss

7. 11-20 concurrent agents is cited as the point manual debugging stops scaling — a concrete trigger for building fleet tooling now

Why it matters for a loop fleet: The user is already at 11 named loops (L1-L11). This gives a specific, sourced number for "you have crossed the threshold where eyeballing logs per-loop stops working and you need an aggregate board" — useful as a justification/urgency data point rather than a vague "it'll get harder eventually." Concrete mechanic: The claim (from agent-observability vendor research, treat as directional not lab-verified) is that below ~10 agents, ad hoc per-agent log review is tractable; in the 11-20 range, agents start failing in combinatorial/non-obvious ways (interactions between loops, shared resource contention, cost bleed across loops) that no longer surface from single-agent logs and require a fleet-level aggregation layer to catch. Actionable trigger: treat crossing 10 active loops as the line to stand up the shared heartbeat/dashboard log (per items 1 and 4 above) rather than deferring "I'll build a dashboard someday." Source: Rubrik — Agent Observability: How to Monitor AI Agents; Arize — Best AI Observability Tools for Autonomous Agents in 2026

Lane B

Lane B — Multi-Agent Loop Composition & Topologies

Angle: how INDEPENDENT loops/agents coordinate ACROSS each other, not the single-agent 4-level stack. Excludes: 4-level stack, swyx Loopcraft, existing fan-out doctrine, nanobots/openclaw heartbeat (already known).

1. Topology choice has production data now — orchestrator-worker still wins by default, but at a measured overhead tax

Why it matters: the user already runs orchestrator-worker (Opus→Sonnet/Fable). 2026 roundups now cite production mix and, critically, the token-overhead cost of decentralizing — a number to weigh before ever trying blackboard/swarm for the independent launchd loops.

Concrete mechanic: three topologies dominate production in 2026 — supervisor/hierarchical, orchestrator-worker (~70% of deployments: orchestrator holds the plan, delegates to workers, maintains global state, workers report back), and swarm (no central controller, agents share context/vote/consensus, a shared-state layer tracks progress, behavior emerges from local rules — ant-colony style; more resilient, much harder to debug). Measured overhead: independent/decentralized multi-agent setups run ~58% extra tokens vs single-agent baseline; centralized (heavier context-sharing) setups run ~285% extra. Rule of thumb from the same source: only decentralize when the task genuinely needs specialization, parallelism, or critique — otherwise the overhead isn't earned.

Source: Multi-Agent Orchestration: 5 Patterns That Work in 2026 (digitalapplied.com, 2026); Multi-Agent Systems Explained: 2026 Patterns (decodethefuture.org, 2026)

2. A2A (Google) has absorbed IBM's ACP — one converging protocol for horizontal agent-to-agent comms, distinct from MCP

Why it matters: the user's system uses MCP as a shared read surface (mission-control endpoint) for tool access. That's the right split going forward: MCP = agent-to-tool, A2A = agent-to-agent. As of 2026 there's no longer a live fork to pick between — ACP folded into A2A under Linux Foundation governance, so A2A is the converged standard if the user ever wants Sonnet/Fable/Codex workers to discover and delegate to each other directly instead of only reporting to Opus.

Concrete mechanic: each agent publishes an Agent Card (JSON: capabilities, skills, auth requirements) at a well-known endpoint. Other agents fetch the card, then negotiate task delegation and exchange structured JSON messages over HTTP, maintaining multi-turn context. Peer-to-peer, not hub-and-spoke — any agent can be a client of any other agent's card. As of mid-2026, LangGraph, CrewAI, Vertex AI Agent Builder, and AutoGen all speak it; IBM's ACP team "wound down active development" and contributed its tech to A2A in the merge.

Source: A2A Protocol Guide 2026: The Standard Unifying Multi-Agent AI (dailyaiworld.com, 2026); What is Agent Communication Protocol (ACP)? — IBM (IBM Research, notes the ACP→A2A merge, 2026)

3. Blackboard architecture beats master-slave orchestration empirically — the SQLite-blackboard instinct is validated, not just a folk pattern

Why it matters: the user is weighing a SQLite-blackboard option against orchestrator-worker. This is now a published, benchmarked result from Google Cloud AI Research (not just a design-pattern blog post): blackboard-style coordination outperformed the master-slave (orchestrator-worker) paradigm specifically because the central agent doesn't need advance knowledge of every worker's capabilities — workers self-select.

Concrete mechanic (bMAS): a central agent posts a request to a shared blackboard (not a specific worker). Autonomous subordinate agents — each owning a partition of the problem space — read the blackboard and volunteer to respond based on their own capability match, rather than being assigned by the orchestrator. Benchmarked on KramaBench/DS-Bench/DA-Code: 13–57% relative improvement in end-to-end task success and up to 9% F1 gain over both RAG and master-slave baselines, across proprietary and open-source LLMs. Translates directly to the user's fleet: independent launchd loops post "I found X" to ~/loops/state, and other loops/workers self-select whether to act, instead of Opus having to pre-know every loop's capability.

Source: LLM-based Multi-Agent Blackboard System for Information Discovery in Data Science — Parmar, Goyal, Song, Yoon, Zamani, Palangi, Pfister, Google Cloud AI Research / UMass Amherst, arXiv 2510.01285, Oct 2025

4. Observation-driven coordination (CRDT/stigmergy) — lock-free claim protocol for concurrent agents writing to shared state

Why it matters: this is the concrete mechanic for making a SQLite blackboard safe under concurrent writers without a lock manager — relevant the moment two of the user's scheduled loops or worker agents might touch the same state row at once.

Concrete mechanic (CodeCRDT): agents coordinate by monitoring shared state with observable updates, not explicit message-passing — the same lineage as Linda tuplespaces and blackboard architectures, applied to LLM agents. A TODO-claim protocol gives provable at-most-one-agent-per-task under strong eventual consistency (CRDT-backed): an agent claims a row, others observe the claim and skip it, no central lock manager, no polling race. Evaluated across 600 trials (Claude Sonnet 4.5): 100% convergence, zero merge failures — but 5–10% semantic conflicts still slipped through (duplicate declarations, type mismatches) that structural convergence can't catch, meaning claim-based coordination removes collisions but not semantic drift; still needs a review/verify pass downstream. Coordination overhead is O(N×U) — N agents watching U updates — worth budgeting before scaling loop count.

Source: CodeCRDT: Observation-Driven Coordination for Multi-Agent LLM Code Generation — Sergey Pugachev, arXiv 2510.18893, Oct 2025

5. forge-orchestrator — a real, shipped implementation of exactly the "SQLite blackboard + mission-control MCP" idea, for cross-tool (not just cross-model) agents

Why it matters: this isn't a paper — it's a working 4.7MB Rust binary (128 GitHub stars, actively updated as of Jun 2026) solving the precise problem the user has: multiple independent agent tools (their case: Claude Code, Codex CLI, Gemini CLI) editing a shared repo with no shared state, stepping on each other. Worth studying as a reference architecture even without adopting the binary — it's the productionized version of "state dir + event log + locks + MCP read surface."

Concrete mechanic: forge init creates a .forge/ state directory holding an event log, a knowledge base (auto-classified decisions/patterns/learnings captured across tools), and a task board with dependency-aware assignments. File locking gives exclusive per-file locks so two tools can't edit the same file simultaneously. Drift detection continuously diffs in-progress work against the original spec and flags divergence early — a coordination failure-mode the user's fleet doesn't currently guard against. An 11-tool MCP server exposes the entire orchestration state (locks, tasks, knowledge, event log) to any connected AI client — structurally identical to the user's "mission-control MCP endpoint as shared read surface" idea. Author's stated origin story: two AI tools refactored the same module in parallel, saved conflicting versions, neither knew the other existed — exactly the failure this architecture targets.

Source: nxtg-ai/forge-orchestrator — 128 stars, updated 2026-06-21, README fetched directly (verified via gh repo view)

6. Infinite Agentic Loops (IAL) — the specific cross-agent-handoff failure mode, plus a production mitigation already running in a scheduled-agent system

Why it matters: this is the multi-agent-specific version of thrashing/deadlock the user asked for — not "an agent loops on one tool," but a feedback path that crosses agent handoffs and workflow transitions where no single agent's own termination guard catches it. Directly relevant to independent launchd loops that can trigger each other.

Concrete mechanic (failure mode): IALs arise from the interaction of agent logic, framework semantics, and termination checks — not from an obvious while True. Static per-agent limits (LangChain's max_iterations, LangGraph's recursion limit, CrewAI's max_iter) don't catch it because the loop is a chain of handoffs, each individually bounded, whose composition isn't. A static analyzer (IAL-Scan) built an "Agentic Loop Dependence Graph" across 6,549 real agent repos and confirmed 68 real IAL failures across 47 projects (91.9% precision) — so this is not theoretical; it ships in real multi-agent codebases today. Failure signature: cost exhaustion, context growth, and repeated external side effects (the dangerous one for a loop system that sends messages or writes state).

Concrete production mitigation (Hermes Agent, a scheduled-cron LLM agent system, docs updated 2026-07-07): two guardrails directly portable to the user's launchd fleet — (1) cron-run sessions cannot recursively create more cron jobs — the scheduling tool is deliberately disabled inside cron executions, which structurally forecloses runaway self-scheduling loops; (2) fail-closed on config drift — a job snapshots its provider/model at creation; if the global default later changes, the job skips its run and alerts rather than silently inheriting a (possibly paid/different) model — preventing an unattended loop from silently changing its own cost profile.

Source: When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents — Hou, Wang, Zhao, Wang, arXiv 2607.01641, 2026; Hermes Agent — Scheduled Tasks (Cron) docs, fetched 2026-07-07

7. Distributed locking + per-agent token budgets are the two concrete guardrails for a fleet of independent scheduled loops sharing state

Why it matters: directly answers "how do multiple scheduled loops avoid stepping on each other at fleet scale" — this is the mechanical layer under items 3–6, for the user's ~/loops/state today (file-based) and Redis/SQLite if it grows.

Concrete mechanic: (a) Stale-lock-safe file locking — write an owner token into the lock file at acquire time; on any cleanup/restart, compare-and-delete only if the token still matches, so a crashed loop's lock doesn't wedge every other loop forever (this is the exact bug class that bites naive flock-only cron setups). (b) Idempotency keys on every side-effecting call (the post, the DB write, the webhook) — the real safety net once loops overlap, because locks prevent double-start, not double-effect if a loop crashes mid-write and retries. (c) At larger fleet scale than a single machine's file locks can serve, the standard escalation is Redlock across Redis instances or ZooKeeper ephemeral znodes for strongly-consistent distributed locks — overkill for the user's current single-box launchd setup, but the documented next rung if loops move off one machine. (d) On cost: documented multi-agent token multipliers run 3.5x baseline in general, and 10x–100x specifically in CI/CD-triggered agent fan-outs — the mitigation pattern is a hard per-agent/per-workflow token budget with a circuit breaker (halt and surface an error on breach, don't retry-and-compound).

Source: Distributed Locking for Scalable Cron Jobs: Preventing Chaos in Microservices (Medium, 2026); Agentic Token Explosion: How to Attribute, Budget, and Control LLM Costs When AI Runs in CI/CD (TrueFoundry, 2026)

Method: WebSearch + curl r.jina.ai for full-text fetch of arXiv/blog sources, HN Algolia API for community signal, gh search repos / gh repo view to verify real repos (forge-orchestrator, roundtable, hector all confirmed live with current star counts). Budget: ~25 min, no repo writes/installs.

Lane C

Lane C — Theoretical Grounding for Agent Loops (control theory, cybernetics, failure taxonomy)

Scope note: this lane deliberately skips the 4-level stack, swyx Loopcraft, Ng's 3 loops, and the existing 5-diseases list. It supplies the deep frame — control theory, cybernetics, OODA, convergence math, and a rigorous failure taxonomy — that explains why loops work and how they fail.

1. The Good Regulator Theorem (Conant & Ashby, 1970)

The principle. "Every good regulator of a system must be a model of that system" — formally, there must exist a homomorphism (a structure-preserving mapping) from the states of the system being controlled to the internal states of the regulator. A controller that lacks this mapping cannot systematically minimize unwanted outcomes; it can only react to the specific disturbances it happens to represent.

What it predicts/prescribes for a real agent loop. An agent's "checker" step (the verifier, the reviewer subagent, the test suite, the eval) is a regulator of the codebase/task-system. If the checker's internal model of "what correctness looks like" is thinner than the actual space of failure modes the system can produce, the checker cannot regulate against failures outside that model — it will pass broken states that fall in its blind spot. Concretely: a loop whose only feedback signal is "did the tests pass" is a regulator whose model of "system state" is exactly {tests: pass|fail} — it will be blind to any failure that doesn't perturb that variable (e.g., a silently-wrong-but-untested code path, a doom-loop that keeps re-running a no-op tool call). The prescription: the verifier's state space must be enlarged (richer eval, human spot-check, diff review, a second model with a different training distribution) until it's expressive enough to distinguish every failure mode you actually care about catching. This is the same idea as Ashby's Law below, applied specifically to the checker/verifier component rather than the whole loop.

Caveat on rigor. Wikipedia notes a documented criticism (John Baez) that the theorem's formal proof does not fully support the strong claim in the paper's title — treat "good regulator = model of system" as a powerful heuristic frame, not an airtight mathematical guarantee for arbitrary agent architectures. A 2026 extension ("A Good Regulator May Provide a World Model for Intelligent Systems," arXiv:2506.23032, and "A 'good regulator theorem' for embodied agents," arXiv:2508.06326) recasts it for embodied/LLM-style agents: regulation success depends on how well the agent's internal representation captures the causal structure of the environment it's coupled to, and sensorimotor (tool-output) feedback is what refines that internal model over time — i.e., an agent loop is how a good-enough model gets built, not just how it's exploited.

Source. Good regulator theorem — Wikipedia (accessed 2026-07-07); A "good regulator theorem" for embodied agents, arXiv:2508.06326.

2. Ashby's Law of Requisite Variety (1956)

The principle. "Only variety can absorb variety." For a control system to hold a regulated variable within bounds, the controller's own repertoire of distinguishable states/responses must be at least as large as the repertoire of disturbances the environment can throw at it. If disturbance-variety exceeds controller-variety, the controller cannot guarantee stability — some disturbances will pass through unregulated.

What it predicts/prescribes for a real agent loop. Directly generalizes item 1 to the whole loop, not just the checker: a loop's guardrail/critic step must be at least as expressive as the space of failures it's meant to catch. If an agent loop can fail in N structurally distinct ways (wrong output, infinite tool-call loop, silent no-op, reward-hacked metric, context poisoning, goal drift) but the guard condition only checks one axis (e.g., exit code == 0), the guard has less variety than the failure space and Ashby's Law says it will eventually let something through — this isn't a tuning problem, it's a structural inevitability. Practical implication for loop design: enumerate the actual failure taxonomy first (see item 6), then size the checker's variety to match — every named failure mode needs its own detector, because one scalar signal cannot regulate a multi-dimensional failure space.

Source. Ross Ashby's Law of Requisite Variety — Edge.org; general treatment at ScienceDirect: Requisite Variety (accessed 2026-07-07).

3. PID-controller framing for agent self-correction

The principle. A PID controller corrects error using three terms: Proportional (respond to the current error's size), Integral (respond to accumulated/persistent error over time), and Derivative (respond to the rate of change, to avoid overshoot). A pure-P controller oscillates around the setpoint or undershoots; adding I eliminates steady-state bias; adding D dampens oscillation.

What it predicts/prescribes for a real agent loop. Most "agent self-correction" prompting is P-only: "here's the current error, fix it" — which is exactly the term that causes oscillation (overcorrect, then overcorrect back) when the error signal is noisy, as LLM-graded error signals often are. The I-term implication: a loop should track persistent error across iterations (e.g., "this same test has failed 3 iterations running" or "this same class of review comment recurred twice") and escalate response magnitude or escalate to a different strategy/model, not just react to this turn's diff. The D-term implication: a loop should throttle correction magnitude when the error is shrinking fast, to avoid overshooting past a good state into a new bad one (a documented failure mode in the "doom loop" literature, item 7 below, where each fix is sized to the whole observed state rather than the marginal error, causing thrash). A dedicated paper (arXiv:2404.00828, "PID Control-Based Self-Healing to Improve the Robustness of Large Language Models") formalizes this: applying proportional-integral-derivative correction terms to LLM output-robustness feedback rather than naive re-prompting.

Source. PID Control-Based Self-Healing to Improve the Robustness of Large Language Models, arXiv:2404.00828; general PID framing in Understanding PID Control — Medium (accessed 2026-07-07).

4. OODA loop (Boyd) applied to agents — and where it breaks

The principle. Boyd's Observe-Orient-Decide-Act loop: the combatant (or system) that cycles through all four phases faster relative to how fast the environment is changing wins, not the one that's fastest in absolute terms. Orient is the pivotal phase — it's where raw observations get filtered through existing mental models, and a broken or stale Orient stage corrupts every downstream Decide/Act even if Observe and Act are individually sound.

What it predicts/prescribes for a real agent loop. In agent terms: Observe = tool outputs/logs; Orient = what gets synthesized into and persisted in the context window (system prompt, prior state, "constitution" directives); Decide = the model's next-tool-call choice; Act = execution. The theory predicts a specific, common agent-loop failure: agents over-invest in Observe (dump full file contents, full DOM, full logs back into context) and under-invest in Orient (no compression, no synthesis, no discarding of stale beliefs), so the loop's tempo slows and its Orient stage becomes polluted with raw, unfiltered material — precisely the mechanism behind the "doom loop" in item 7. Prescription: treat context-window curation as the Orient stage explicitly, and budget it — a loop that skips Orient (feeds Observe output straight into Decide) is not doing OODA, it's doing "OoDA" with a degenerate middle step, and will be slow to adapt when the environment (codebase, task) shifts.

Source. OODA Loop: A Decision-Making Framework Applied to Autonomous AI System Design — Sand Garden (accessed 2026-07-07); Agentic AI's OODA Loop Problem — IEEE Computer Society / Security Boulevard.

5. Convergence, oscillation, and divergence in iterative self-refinement

The principle. Self-Refine (Madaan et al., arXiv:2303.17651) established that LLM-on-LLM iterative feedback improves output by ~20% absolute on average — but follow-up work documents a hard plateau: on GSM8K/MATH, refinement gains flatten once accuracy crosses a threshold, because the model lacks the domain-specific competence to discover genuinely new problem-solving strategies through self-critique alone; it can only rearrange what it already "knows." Separately, safety-refinement studies show most of the gain lands by iteration ~4, after which further iterations add little — a classic diminishing-returns/fixed-point-approach curve, not linear improvement.

What it predicts/prescribes for a real agent loop. Iterating a fixed model against itself (self-review, self-grading, "keep refining until it says it's good") is not indefinitely productive — it converges to a fixed point set by the model's own capability ceiling, not by the task's actual difficulty. Two prescriptions follow: (1) cap iteration count with a decreasing-marginal-gain stopping rule rather than a fixed large budget — running past the plateau burns tokens for ~0 quality delta; (2) when a loop plateaus below the required bar, the fix is not "iterate more," it's to change the regulator — swap in a different model/checker with an independent error distribution (matches item 1's "expand the regulator's variety"), because a model self-grading its own blind spots cannot discover them by construction. This is the internal analog of the external "self-consuming loop" / model-collapse literature (arXiv:2404.01413): training (or in this case, iterating) exclusively on your own outputs without injecting outside signal narrows the distribution over generations rather than improving it — real external verification is the "accumulating real data" fix documented there.

Source. Self-Refine: Iterative Refinement with Self-Feedback, arXiv:2303.17651; plateau finding via search synthesis of follow-up GSM8K/MATH and safety-refinement studies (accessed 2026-07-07); Is Model Collapse Inevitable? Breaking the Curse of Recursion by Accumulating Real and Synthetic Data, arXiv:2404.01413.

6. Rigorous failure taxonomy I — Microsoft's "Taxonomy of Failure Modes in Agentic AI Systems" v2.0 (2026)

The principle. Based on a year of red-teaming, Microsoft's updated taxonomy separates novel agentic failure modes (don't exist in non-agentic systems) from existing modes amplified by agency, then adds seven new v2.0 categories from a further year of findings: Agentic Supply Chain Compromise (poisoned plugin/MCP-server/tool definitions), Goal Hijacking (adversarial instructions silently redirect the agent's terminal goal without fully compromising it), Inter-Agent Trust Escalation, Computer-Use-Agent Visual Attack (hidden/off-screen prompt injections in screenshots), Session Context Contamination (early adversarial data biases reasoning across a multi-step run without tripping any single-turn safety control), MCP/Plugin Abuse (tool-description poisoning), and Capability/Architecture Disclosure. Their single strongest empirical finding: Human-in-the-Loop bypass was the most consistently exploited failure mode, largely via "consent fatigue" and zero-click chains.

What it predicts/prescribes for a real agent loop. Two items translate directly to a benign (non-adversarial) unattended loop, because the same mechanisms cause accidental failures, not just attacks: (a) Session Context Contamination is the security-framed twin of "context poisoning" (item 7) — a bad fact planted early in a long-running loop's context biases every downstream decision without any single check firing, because no individual step looks wrong in isolation. Prescription: periodic fact re-verification against ground truth (re-read the file, re-run the check) rather than trusting accumulated context, especially past a session-length threshold. (b) HitL bypass being the top exploited mode is a direct warning for /goal-style unattended loops with human-approval gates: the mechanism that breaks isn't a clever attack, it's routine consent fatigue — a human who has clicked "approve" 50 times stops reading. Prescription: gates should sample/escalate (force a real read on some fraction, or on any high-blast-radius action) rather than relying on a rubber-stamp click as the safety boundary.

Source. Updating the taxonomy of failure modes in agentic AI systems — Microsoft Security Blog, 2026-06-04; full whitepaper PDF.

7. Rigorous failure taxonomy II — context poisoning, termination poisoning, and the "doom loop" mechanism

The principle (three related, named mechanisms):

• Context poisoning (multiple 2026 write-ups converge on the same mechanism): the agent's own accumulated context becomes the source of wrong information — it confidently reports a stale fact from step 1 while executing step 9, and because the false claim is now in the context window as prior model output, it self-reinforces: subsequent generations condition on it as established fact. Invisible to standard monitoring because nothing crashes.
• Termination poisoning (LoopTrap, arXiv:2605.05846): an adversary — or, in a benign setting, a malformed tool output — corrupts the progress/completion signal the agent uses to judge "am I done," so the agent never recognizes a legitimate stopping point and loops unboundedly. Mechanism: signal disruption (poisoned content masks completion criteria) + environment manipulation (tool responses make the task look perpetually incomplete).
• Doom loop (getunblocked.com, 2026-04-18; independently corroborated by other 2026 practitioner posts): has two distinct sub-mechanisms worth separating. Within-session: many tool calls return full state (whole file, whole DOM, whole log) which re-enters context and re-triggers the same tool call — the tool output is the next input, and without a damping term the loop oscillates (this is the OODA/PID connection above — no derivative/damping term). Cross-session: "each session starts with zero memory of previous corrections" — described explicitly as "an organizational memory failure rather than a model capability failure." A correction made and verified in session N is invisible to session N+1, so the same mistake recurs indefinitely across restarts, not within one run.

What it predicts/prescribes for a real agent loop. These three give three distinct, testable design requirements, not just one "add more context" fix: (1) against context poisoning — re-derive facts from source instead of trusting context-window claims at decision points that gate irreversible actions (matches item 6's fix); (2) against termination poisoning — completion/exit conditions must be verified independently of the same channel that could be poisoned (e.g., don't let the tool whose output you're evaluating also be the sole arbiter of "task complete"; use a hard iteration cap as a backstop regardless of self-reported progress); (3) against the doom loop — add an explicit damping/summarization step between tool-output and next-decision (don't feed raw full state back in unmodified) for the within-session variant, and add durable, automatically-injected memory of prior corrections (not a static CLAUDE.md, which "suffers from documentation decay") for the cross-session variant.

Source. LoopTrap: Termination Poisoning Attacks on LLM Agents, arXiv:2605.05846; Context Poisoning in Long-Running AI Agents — TianPan.co, 2026-04-15; Context Poisoning: When Agent Context Becomes Unreliable — Agent Patterns; AI Agent Doom Loop: Why Agents Repeat the Same Mistake — getunblocked.com, 2026-04-18.

Summary table

Lane D

Lane D — Emerging 2026 Loop Primitives & Protocols (last ~30-45 days through 2026-07-08)

Dedup respected: no re-report of swyx Loopcraft, LangChain 4-level stack/Engine, DSPy/GEPA, HarnessFix, Reflexion/Self-Refine, ClaudeDevs taxonomy, nanobots/ralph-loop/claude-code-loop-patterns.

1. Gemini Interactions API goes GA, with native background=true execution

What's new: Google's Interactions API (successor to generateContent) went Generally Available in June 2026 and is now "the recommended interface for all new projects." Core primitive: an Interaction resource that stores the full chronological execution-step history (thoughts, tool calls, tool results, model output) server-side, addressable by previous_interaction_id. Long-running work uses background=true + store=true (background execution requires storage — store=false explicitly disables it). Also ships observable execution steps for debugging/UI rendering, and a single interface across raw models and managed agents (Deep Research, "Antigravity" agent). Why it changes loop design: This is Google formalizing the server holds the loop state, not your process pattern — the same shape Anthropic's Messages API + prompt caching nudges toward, but with an explicit background-job primitive baked into the resource model instead of bolted on via polling conventions. Execution steps as a first-class, replayable object (not just a message array) means a loop's "state" is now inspectable/resumable via API without the caller owning a session store. Exploit: For any L-tier loop that runs multi-hour Gemini-backed work (or a future mixed-provider fleet), background=true + previous_interaction_id chaining gives crash-safe resumability for free — kill the poller, come back later, pick up by ID instead of re-deriving state from a transcript file. Worth a thin adapter if the fleet ever routes hard problems to Gemini 3.1 Pro as a second opinion alongside Codex. Source: ai.google.dev/gemini-api/docs/interactions-overview (fetched 2026-07-07, HN thread same day) — freshness: GA'd June 2026, doc content current as of fetch. In-window.

2. Dapr v1.18 ships cryptographically verifiable execution lineage for agent chains (Diagrid Catalyst)

What's new: Dapr v1.18 (via Diagrid Catalyst) adds Workflow History Propagation — three mechanisms: local history signing (tamper-evident workflow state), cross-identity completion attestation (a child workflow/activity signs its result before the parent trusts it), and lineage chunk signatures (each hop's contribution to a cross-app history chain is independently signed and verified). Positioned explicitly as "durable execution is solved; verifiable execution lineage is not" — and calls out that Temporal's Nexus is peer-to-peer, not hierarchical: a caller's workflow history is never propagated to the handler and vice versa, so no engine on the market today can answer "did the right things happen upstream, and can I prove it" across a multi-agent/MCP tool chain. Why it changes loop design: Durable execution (crash-safe retries) is now table stakes — the interesting frontier is trust propagation across agent-to-agent / agent-to-tool boundaries where each hop may run under a different identity. This directly targets the MCP multi-agent chain problem (agent A calls agent B's MCP tool, which calls agent C) where today nothing verifies that upstream steps (approval, budget check, fraud check) actually happened rather than being claimed in a payload. Exploit: If any future loop does agent-to-agent handoffs with consequential actions (spend money, approve merges, touch prod), this is the primitive to reach for instead of hand-rolled signed tokens — the DAPR_WORKFLOW_HISTORY_TAMPERED failure mode is a genuinely new crash-safety category (tampered state, not just crashed state) worth designing loop kill-switches around even without adopting Dapr itself. Source: diagrid.io/blog/verifiable-execution-lineage-agent-workflows (published 2026-06-18, HN discussion via "Why Temporal Isn't Enough" search) — in-window (20 days old).

3. MCP Enterprise-Managed Authorization (EMA) goes stable — zero-touch OAuth for agent tool access

What's new: The MCP Enterprise-Managed Authorization extension (SEP-990) is now stable as of 2026-06-18. Instead of per-server, per-user OAuth consent screens, the org's IdP (Okta first) becomes the authority: client obtains an ID-JAG (Identity Assertion JWT Authorization Grant, an OAuth/IETF draft) during SSO and exchanges it for MCP server access tokens — no per-server consent redirect. Anthropic has shipped it in Claude/Claude Code/Cowork's shared MCP layer; VS Code added support; Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase are early server adopters. Why it changes loop design: Removes the single biggest practical blocker to background, unattended MCP-tool-using loops in an enterprise/team context — today an autonomous loop that needs a new MCP server mid-run stalls on a human clicking "authorize." With EMA, any server the admin pre-approved is available to the loop with zero interactive step, which is precisely the failure mode Cloudflare's temp-accounts launch (#4 below) is solving from the deploy-target side. Exploit: Directly relevant to the OpenClaw fan-out ceiling problem noted in ~/.pxpipe/SCOPE.md — if the user's MCP servers (Slack, Drive, Gmail) move to EMA-supporting hosts, unattended loops stop needing pre-flight "am I still authorized" checks. Not actionable today (needs org IdP + Okta), but the direction (auth becomes a runtime-guaranteed precondition, not a step in the loop) is worth tracking for /loop//schedule reliability. Source: blog.modelcontextprotocol.io/posts/enterprise-managed-auth/ (published 2026-06-18T17:00Z) — in-window (20 days old).

4. Cloudflare ships wrangler deploy --temporary — zero-signup deploy targets for background agents

What's new: 2026-06-19/20 launch: any agent can run wrangler deploy --temporary and get a live Worker deployment with no account, no OAuth, no API token up front. Cloudflare provisions a throwaway account, gives Wrangler a token, and returns a claim URL a human can redeem within 60 minutes (or it auto-expires). Wrangler itself now prints a discoverable hint about the flag so agents self-discover it from CLI output, not from being told. Explicitly framed as solving background-agent auth friction ("no human in the loop... any auth step that needs a browser or copy-paste means the agent gets stuck"). Why it changes loop design: A genuinely new pattern — self-expiring, self-discovering credentials as a CLI affordance, not a protocol extension. The write→deploy→verify loop (agent codes, deploys, curls its own output, decides pass/fail) is a core primitive for any coding-loop that needs to verify against a real running instance rather than static analysis; this removes the "needs a Cloudflare account" precondition entirely for cheap iteration. Exploit: Directly usable pattern for any loop that needs a scratch deploy target to verify a generated app actually runs (not just typechecks) — e.g., an L-tier loop building/iterating a small web tool could deploy-and-curl each iteration for real signal instead of trusting static output, with zero account setup cost per throwaway run. Source: blog.cloudflare.com/temporary-accounts/ (published 2026-06-19) — in-window (19 days old).

5. IronBee publishes first empirical data: a verification loop = 4x effective intelligence, ~7x cheaper than a bigger model

What's new: 2026-07-07 (today) — IronBee (a browser-verification-and-fix layer for coding agents) ran DeepSeek-v4-pro solo vs. DeepSeek-v4-pro + their verification loop (open real app in browser, exercise change, find failure, drive fix, re-verify) on ByteDance's Web-Bench sequential-task benchmark. Result: solo DeepSeek averaged 6.8/20 tasks (score 20.4); DeepSeek+loop averaged 17/20 tasks (score 80.6) — matching Claude Opus 4.8's own solo average (82.8) at ~1/7th Opus's per-run cost ($2.4 vs ~$15), with the verifier's own model calls counted in that cost. Methodology is disclosed-interest but public/rerunnable (Web-Bench is open). Why it changes loop design: First quantified data point (not just an anecdote) for a claim the loop-engineering community has asserted but rarely measured: a grounded verify-loop (evidence from a running app, not blind retries) beats spending the same budget on a stronger model. They explicitly flag the open ablation — guided iteration vs. equal-budget blind retries — as still unproven, which is an honest caveat worth carrying forward. Exploit: Reinforces the existing L-tier "verify" discipline (the verify skill already in the user's toolchain) with actual numbers to cite when deciding whether to escalate a stuck cheap-model loop to a smarter model vs. just adding a verification pass — a verify-loop may be the cheaper lever before reaching for Opus/Fable escalation per the CLAUDE.md routing table. Source: ironbee.medium.com/what-a-verification-loop-adds-to-a-coding (published 2026-07-07T12:58Z, HN same day, 24 pts) — in-window (0 days old — today). Caveat: single vendor's own benchmark, one project, disclosed conflict of interest, first post in a series — treat as an early signal, not settled.

6. Morph "Reflexes" — sub-100ms trace classifiers, including a shipped stuck-in-a-loop detector

What's new: Morph (docs updated 2026-07-06, HN Show post 2026-06-30/07-05) ships Reflexes: 11 pretrained, no-GPU, 90ms text classifiers designed to label every turn of an agent trace at scale (LLM-as-judge doesn't scale to "thousands of turns a day," so they built small dedicated classifiers instead). Notably includes a stuck-in-a-loop class (progressing vs. looping) alongside jailbreak, leaked-thinking, user-frustrated, ambiguity, difficulty (for model routing), and domain classifiers. Runs either async over stored traces or inline (predict) to block/route a turn before it proceeds. Priced at $0.0005/classification on the async batch tier. Why it changes loop design: This is a productized, cheap circuit-breaker primitive for exactly the failure mode every "loop" architecture worries about — silent unproductive looping — without needing to build a custom heuristic or spend a full LLM call to detect it. The difficulty classifier is also directly useful as a pre-routing signal (route hard prompts to a smarter model automatically, matching the CLAUDE.md "route hard problems up a model" doctrine). Exploit: A stuck-in-a-loop Reflex call before each iteration of a long-running fleet loop (e.g. any L1-L11 stage) is a cheap (90ms, sub-cent) alternative/complement to turn-count hard caps for early-exit — catches "agent is thrashing" before the turn cap is hit, not just after. Could pair with the required hard-cap discipline from CLAUDE.md's unattended-runs rule as a softer, earlier trigger. Source: docs.morphllm.com/sdk/components/reflexes (page updated 2026-07-06), HN Show post docs.morphllm.com/sdk/components/reflexes 2026-06-30 (20 pts) — in-window (2-8 days old).

7. Doordash open-sources "Agentic Orchestrator" (agentico) — phased, worktree-isolated, evaluator-optimizer loop with human gates

What's new: doordash-oss/agentic-orchestrator (repo created 2026-05-12, actively pushed as of 2026-07-07 — today, 72 stars) is a TUI orchestrator that turns one high-level feature prompt into a full phased pipeline: knowledge-base build → inquiry → research → design → roadmap planning → per-phase detailed plans → tracer-bullet implementation → TDD fill-in → verification-gated review → publish (PR). Every feature gets its own isolated git worktree/branch/session so parallel workflows never share state. It's explicitly built as a codification of Anthropic's "Building Effective Agents" patterns (prompt chaining, parallelization, orchestrator-workers, evaluator-optimizer loops) plus Claude Code's explore→plan→code loop — and is provider-agnostic across Claude Code, Codex, and OpenCode CLIs, picking a per-phase default model per provider with runtime override. Why it changes loop design: It's a concrete, shipped reference implementation of "quality gates before the diff gets expensive" — plan validators run before code is written, and optional human-approval gates are scoped to specific decision points (inquiry review, design review, roadmap review, phase-plan review, publish) rather than blanket human-in-the-loop. This is a cleaner instantiation of the Definition-of-Ready-gate + human-owns-the-20%-that-prints doctrine than most OSS loop tools attempt. Exploit: Worth a closer read as a structural reference for the fleet's own multi-agent handoff design (RUN-STATE.md pattern) — its per-phase artifact model (inquiry.md, design.md, roadmap.md, phase-plan.md as structured handoff objects the implementer reads instead of a raw chat history) is exactly the "Definition of Ready" pattern already mandated in CLAUDE.md, just implemented end-to-end with isolated worktrees per feature. Source: github.com/doordash-oss/agentic-orchestrator (README + gh repo view: createdAt 2026-05-12, pushedAt 2026-07-07T17:43Z) — in-window, actively maintained as of today.

Honest nulls

• New standalone A2A-protocol news: "Ask HN: Is anyone using the A2A protocol?" (2026-06-18, 96 pts) shows continued discussion but no new spec/release found in-window — A2A itself hasn't shipped a notable update in the last 45 days per this search; skipped to avoid padding.
• Durable-execution-for-agents via Temporal/Inngest specifically: no major Temporal or Inngest agent-loop feature release found in-window; the durable-execution frontier this cycle is the trust/lineage layer (Dapr, item #2), not raw crash-safety, which appears to be treated as solved.