Stateless-agent assumption failure

Research Question

When an agentic workflow spans multiple session boundaries — each session starting with a fresh context window and no memory of prior runs — what are the mechanisms by which external state becomes orphaned, how frequently does this failure mode occur in production systems, what signals reliably detect it before it compounds, and what design patterns reliably prevent or recover from it?

Findings

Executive Summary

• [inference] This failure is best understood as a continuity failure: a new session treats the world as clean even though earlier sessions already changed durable external state. (Sources: Failure mode taxonomy expansion; Context engineering: first principles)
• [inference] Public evidence is strongest in the solution surface rather than in a named incident class, because official frameworks independently ship checkpointing, session memory, replay, and durable execution as core workflow features while using different terminology for the underlying problem. (Sources: LangGraph Persistence; LangGraph Durable Execution; OpenAI Agents SDK Quickstart; Temporal Workflow Execution)
• [inference] In practice, the safest operating rule is to begin each session with state reconciliation across repository files, git history, workflow state, and metadata before selecting new work or retrying a side effect. (Sources: .github/workflows/research-loop.yml; .github/workflows/research-review.yml; src/research/item.py)
• [inference] Idempotent retry plus checkpoint-resume covers the common case, while compensation or manual quarantine is reserved for workflows whose external mutations cannot be retried safely as a single atomic step. (Sources: AWS idempotency guidance; microservices.io idempotent consumer; microservices.io saga; Temporal durable execution)

Key Findings

1. High confidence — [inference]: Stateless-agent assumption failure is a Layer 5 operational failure in which volatile in-session reasoning operates over durable out-of-session state without a mandatory reconciliation step, so later sessions can hide, duplicate, or contradict prior work even when each individual session behaves coherently. (Sources: Failure mode taxonomy expansion; Context engineering: first principles)
2. High confidence — [inference]: Leading production-oriented agent frameworks already treat persistence, resumability, and replay as first-class concerns, which supports the conclusion that cross-session orphaned-state risk is a normal systems problem rather than an exotic edge case tied to one repository or one vendor. (Sources: LangGraph Persistence; LangGraph Durable Execution; OpenAI Agents SDK Quickstart; Temporal Workflow Execution)
3. Medium confidence — [inference]: The agent ecosystem has not yet converged on a single standard name for this failure class, because public documentation standardises the remedy vocabulary — checkpointing, session memory, durable execution, replay, and persistence — more clearly than the underlying continuity failure itself. (Sources: LangGraph Persistence; OpenAI Agents SDK session memory cookbook; Temporal durable execution)
4. Medium confidence — [inference]: Longer workflows materially increase exposure to this failure because they create more opportunities for interruption, partial side effects, and stale assumptions between sessions, and METR's long-task results show that agent reliability falls sharply as task duration rises. (Source: METR — Measuring AI Ability to Complete Long Tasks)
5. High confidence — [inference]: Reliable detection requires checking at least four state surfaces together — file-system artefacts, git-history transitions, external-service state, and explicit metadata such as status or review_count — because each surface can expose orphaning that the others leave invisible. (Sources: .github/workflows/research-loop.yml; .github/workflows/research-review.yml; src/research/item.py)
6. High confidence — [inference]: Idempotent side effects with at-least-once retry semantics are a better default for agent workflows than literal exactly-once guarantees, because repositories, workflow engines, human review steps, and tool Application Programming Interfaces (APIs) do not share one transaction boundary that a single coordinator can enforce. (Sources: AWS idempotency guidance; RabbitMQ reliability; Kafka delivery semantics; microservices.io idempotent consumer)
7. Medium confidence — [inference]: Saga-style compensation and dead-letter or manual-review paths become necessary when an agent workflow performs multi-step external mutations whose partial completion cannot be made atomic, because recovery must then undo or quarantine inconsistent intermediate state rather than merely retrying the last step. (Sources: microservices.io saga; Temporal Workflow Execution)

Assumptions

• [assumption] No public benchmark currently isolates this failure under the exact label "stateless-agent assumption failure." The reviewed public sources expose adjacent categories such as checkpointing, replay, persistence, or session memory instead.
• [assumption] The motivating repository incident is representative of a broader architectural class. That assumption is justified because the same remedy structure appears independently in agent-framework docs and in older distributed-systems reliability guidance.

Analysis

• [inference] The central mistake is treating context reset as though it implied world reset. In production workflows the opposite assumption is safer: processes are disposable, but state written to files, workflows, queues, and service-side records persists until something explicitly reconciles it.
• [inference] That is why prompt-only mitigations are weak. A reminder like "check in-progress items first" helps, but the reliable fix is architectural: one authoritative state register, explicit status transitions, idempotent side effects, and a mandatory preflight that compares expected state with actual state before the session chooses its next action.
• [inference] The distributed-systems analogy is operational rather than decorative. Agent workflows with tools now face the same constraints as message-driven systems: retries happen, acknowledgements can be lost, side effects escape the local process, and partial completion is normal.

Risks, Gaps, and Uncertainties

• [fact] Public incident counts for this exact failure label remain sparse, so exact frequency can only be stated qualitatively rather than numerically.
• [fact] Framework documentation proves practical importance, but it does not quantify how many production failures each feature prevents.
• [inference] Classical distributed-systems patterns do not fully capture human-review steps, unstructured tool outputs, or repository-specific state machines, so some translation into agent workflows remains design work rather than settled doctrine.

Open Questions

• Can a lightweight repository-local continuity manifest capture enough state to prevent most orphan classes without adopting a full durable-execution engine?
• Which classes of agent side effects should default to idempotent retry, which require compensation, and which should always route to manual review?
• Can future agent evaluations measure cross-session continuity failure directly instead of burying it inside generic long-horizon success or failure rates?

Output

• [fact] Type: knowledge
• [fact] Description: Structured findings on stateless-agent assumption failure as a Layer 5 operational failure, including definition, empirical framing, detection signals, and recovery patterns for multi-session agentic workflows.
• [fact] Links:
  • [fact] LangGraph Durable Execution docs — durable execution and replay requirements
  • [fact] Temporal Workflow Execution docs — durable workflow execution and replay semantics
  • [fact] Amazon Web Services (AWS) event-driven architecture idempotency guidance — idempotency and duplicate-processing guidance

sources

• [x] Research/completed/2026-03-12-failure-mode-taxonomy-expansion.md — parent taxonomy; Layer 5 operational failures
• [x] Research/completed/2026-03-08-context-engineering-first-principles.md — adjacent Layer 5 failures and the token-level / goal-level distinction
• [x] Research/completed/2026-03-01-github-specify-ralph-loop-lisa-planning.md — stateless loops, persistent planning layers, and the "Groundhog Day" memory problem
• [x] Research/completed/2026-03-03-research-loop-quality-prompt-engineering.md — prompt-level forcing functions and prior-work detection gaps in this repository
• [x] .github/workflows/research-loop.yml — fresh-session research loop implementation
• [x] .github/workflows/research-review.yml — review workflow and review_count mutation pattern
• [x] src/research/item.py — frontmatter status-to-directory mapping
• [x] LangGraph Persistence docs
• [x] LangGraph Durable Execution docs
• [x] OpenAI Agents Python Software Development Kit (SDK) Quickstart
• [x] OpenAI Agents SDK session memory cookbook
• [x] Temporal Workflow Execution docs
• [x] Temporal durable execution essay
• [x] Model Evaluation & Threat Research (METR): Measuring AI Ability to Complete Long Tasks
• [x] Amazon Web Services (AWS) event-driven architecture idempotency guidance
• [x] Confluent Kafka delivery semantics
• [x] microservices.io idempotent consumer pattern
• [x] microservices.io saga pattern
• [x] RabbitMQ reliability guide