From Endless Loops to Hierarchical Thought

This post argues for a specific architectural claim about agentic systems built on frontier LLMs: that the dominant “sequential loop” pattern—accumulating an ever-growing transcript and asking the model what to do next—hits a scaling wall that cannot be solved simply by larger context windows, better summarisation or even better memory models.

I propose that longer-horizon, interdependent tasks require explicit hierarchical decomposition plus an executable planning representation, and—crucially—a repair mechanism that treats plan structure as a provisional hypothesis rather than a brittle contract.

I’m posting here because this intersects with LessWrong’s interests in epistemic hygiene, failure modes of cognition under noise, and the design of systems that can be inspected, corrected, and updated under uncertainty. I would particularly value pushback on: (i) whether the “transcript is not memory” diagnosis is right, (ii) whether repair is truly structural rather than an implementation detail, and (iii) what counterexamples exist where sequential loops scale without silently accumulating incoherence.

I wrote this piece and used an LLM only for light editing (phrasing/structure). The arguments and claims are mine, and I’m happy to clarify or revise them under critique.

Claims

Core claims

The transcript-shaped sequential loop cannot scale to deep, long-horizon work.
As iterations accumulate, the context becomes a mixture of revisions, retractions, and superseded assumptions; signal-to-noise degrades, stale premises resurface, and cost/latency rise monotonically. Summarisation helps but introduces irreversible loss and flattens epistemic distinctions. Eloquent Kitsune
Decomposition is not optional; it is a structural constraint.
Systems that solve large problems must operate with locality, bounded inputs/outputs, and insulated subcontexts. For agents, this entails explicit decomposition into subgoals and dependencies rather than monolithic “global context.” Eloquent Kitsune
Explicit planning requires a design language, and that introduces brittleness.
Executable plans force names, scopes, IO contracts, dependency rules, and failure representations. Many systems avoid this because when structure breaks, failure is abrupt (schema violations, invalid plans, misrouting). Eloquent Kitsune
Therefore, repair is unavoidabl

...

Posts

Wikitag Contributions

Comments

Posts

Wikitag Contributions

Comments