← logs/

Long-horizon agents: state, skills, recovery

A two-hour agent run is a different artifact from a twenty-turn chat. The chat can afford to recompute; the run cannot. What separates them comes down to three things: how state is kept, how skills are acquired, and how the agent recovers from dead ends. Three pieces of work, one per lever: a model release, an RL paper, a skill-internalization paper.

The field map

Long-horizon capability is a stack. Naming the layers helps:

  • State. Can the system sustain quality across hours of messy trajectory? This is context engineering: capacity, compaction, reconstruction. I close-read that family separately in Context engineering: what to keep, what to fold, what to drop.
  • Skills. Where does task competence live: in retrieved documents, in the prompt, or in the weights?
  • Recovery. When the agent is stuck, does the harness notice, and can the agent get back to a good state?

GLM-5.2 is the state layer. The CLI-agents paper is the recovery layer: recovery is knowing which earlier action to undo, and credit assignment is exactly the mechanism that attributes the final outcome to that action. SKILL0 is the skills layer.

GLM-5.2: context as an engineering substrate

Z.ai's official post, GLM-5.2: built for long-horizon tasks (June 2026), leads with exactly that framing: a flagship model for long-horizon tasks, on a solid 1M-token context that stably sustains long-horizon work. The sentence I care about comes right after: long context has to be engineering-usable. The model must hold quality across long, messy coding-agent trajectories, not just accept more tokens.

The release's substance:

  • Training was substantially expanded at 1M context for coding-agent scenarios: large-scale implementation, automated research, performance optimization, complex debugging. That is a bet that long-horizon ability is trained, not windowed.
  • IndexShare reuses one indexer across every four sparse-attention layers, cutting per-token FLOPs by 2.9× at 1M context. Long context is a cost problem before it is a capability problem.
  • The multi-token prediction layer was upgraded for speculative decoding, with acceptance length up to 20% longer.
  • On FrontierSWE, open-ended projects at the scale of hours to tens of hours, GLM-5.2 trails Claude Opus 4.8 by 1% and edges GPT-5.5 by 1%. It is the top open-source model across FrontierSWE, PostTrainBench, and SWE-Marathon, and the weights are MIT-licensed. These are Z.ai's self-reported numbers, and FrontierSWE is a young benchmark; treat the 1% margins as directional, not settled.

My read: the model vendors converged on the realization the agent literature reached first. The benchmark that matters is sustained multi-hour execution. A 1M window is the substrate; what the harness does with it is still the open problem. The blog says it plainly: a 1M context is easy to claim, much harder to keep reliable under real engineering pressure.

Credit assignment: teaching the agent which actions mattered

Learning CLI Agents with Structured Action Credit under Selective Observation (arXiv 2605.08013, May 2026, Haoyang Su and Ying Wen) attacks the recovery problem from the training side. CLI agents operate over evolving filesystems, and learning them couples two bottlenecks: the agent must find task-relevant evidence in a large codebase from partial observations, and sparse terminal rewards must be assigned to the actions that shape a long multi-turn trajectory.

The contributions, in brief:

  • σ-Reveal selects a token-budgeted workspace view before the agent acts, deciding what the agent is allowed to see.
  • A³ (Action Advantage Assignment) builds turn-level advantages from episode-level relative feedback, AST-based action sub-chain residuals, and tree-level trajectory margins. Shell commands are compared by parse-tree structure rather than surface text, so credit flows to structurally similar action sub-chains across rollouts. That is how you learn "the second cd was the mistake" without a reward at every step.
  • ShellOps and ShellOps-Pro are verifiable CLI task suites in repository environments: a 1624-task corpus plus a 150-task harder out-of-distribution split.

The result that matters for long horizons: on ShellOps-Pro, the same Qwen3-14B policy trained with A³ reaches the range of Qwen3-235B-A22B as the horizon grows, though a gap to frontier models remains. Credit assignment is what lets a small policy survive long trajectories. A policy that knows which actions shaped the outcome can retrace and re-plan; one that does not just flails forward.

Skills: moving competence from context into weights

SKILL0: In-Context Agentic Reinforcement Learning for Skill Internalization (arXiv 2604.02268, April 2026, Zhengxi Lu and colleagues at Zhejiang University and Meituan) asks the uncomfortable question about the skill-library paradigm: if an agent follows skills injected into its context, is it executing skills or learning them? The answer: competence lives in the context, not the model. That motivates internalization. Train with skill context present, withdraw it progressively, end with zero retrieval at inference.

The mechanism is in-context RL with a curriculum. Skills are grouped offline and rendered compactly; a dynamic curriculum measures each skill file's on-policy helpfulness and drops the files the current policy no longer benefits from, under a linearly decaying budget. The result is a fully zero-shot agent that improves over the standard RL baseline by +9.7% on ALFWorld, +6.6% on Search-QA, and +10.1% on WebShop, at fewer than 0.5k tokens per step.

Why this matters for long horizons: skills are the recovery mechanism of an agent system. When a run stalls, the fallback is "what do I know how to do here?" A skill bank answers by retrieval, at a token cost that compounds across steps. SKILL0's bet is that stable, reusable behavior should be priced into the weights once, at training time, and never paid again at run time. On an hours-long run with a constrained budget, that compounding saving is the difference between a run that fits and one that does not.

My position

All three are doing versions of the same move: pushing capability from the run-time artifact into something cheaper and more durable. GLM-5.2 pushes capacity into trained long-context behavior. A³ pushes credit knowledge into the policy. SKILL0 pushes skills into the weights. The pattern is a shift from context as the working memory of the run toward context as a small, reconstructible surface over durable state.

The harness version, if the three composed explicitly:

  • an event log as the source of truth for state reconstruction, where the log is the trajectory and the context window is a view over it;
  • recovery as a first-class protocol: stall detection, rollback to a logged checkpoint, re-plan from reconstructed state, trained with credit that rewards getting back on track rather than only finishing;
  • skills as versioned artifacts with an internalization pipeline: retrieval first, distillation into weights once a skill proves stable.
state      GLM-5.2       1M context, trained for long coding-agent runs
skills     SKILL0        competence moved from context into weights
recovery   A3 + harness  credit assignment, checkpoints, re-plan

Where this is headed in my own work

At PiPlan.ai, the guardrails we have shipped (proposal-first review, a simulation sandbox, and an event log that doubles as trajectories) are the substrate these papers assume. The event log is the reconstructible state. The sandbox is where recovery can be rehearsed cheaply. Proposal-first review is the check that keeps a diverging run from spending hours in the wrong direction. On top of those, the conversational planner-executor agent is in progress: the piece that ties the loop together, propose, simulate, log, recover. These three papers map directly onto the open questions in that build, and the one I have not settled is where stall detection lives. It could sit in the harness, watching the event stream for a run that stops making progress, or in the policy, trained with credit that rewards calling its own stall. The event log makes either possible; I have not decided.

Sources linked in this post were fetched and verified.