No implementation currently clears the Snapshot + Claim threshold; this is not a claim that the product lacks the capability.
Inspect coverage boundary →MECHANISM · RELIABILITY · CORE
Retry and Recovery
Classify failures, bound retries, avoid duplicate side effects, and preserve enough state for a safe continuation or explicit pause.
2 lessons3 agent snapshots0 experiments
reliabilityretry-recoveryproblem → policy → evidence
L0Intuitionpartial
L1Buildmissing
L2Engineeringpartial
L3Architecturepartial
L4Researchpartial
DEPENDENCY GRAPH · READER PATH
What feeds it, and what does it unlock?
Arrows show learning and design dependencies, not runtime data flow. Follow any node to continue through the Atlas.
Prerequisites
retry-recoveryRetry and RecoveryCurrent research boundary
UnlocksNo dependents yet
Classify failures, bound retries, avoid duplicate side effects, and preserve enough state for a safe continuation or explicit pause.
The structured record is in the Atlas, but the L0–L4 article has not passed content review.
AGENT MAPPING · EVIDENCE ONLY
Snapshot implementations
An implementation enters the map only when both a snapshot and claims exist; unknowns remain visible.
No implementation currently clears the Snapshot + Claim threshold; this is not a claim that the product lacks the capability.
Inspect coverage boundary →1 evidence-backed claim.
grok-build-2026-08-10-source →1 evidence-backed claim.
opencode-2026-08-10-source →No implementation currently clears the Snapshot + Claim threshold; this is not a claim that the product lacks the capability.
Inspect coverage boundary →1 evidence-backed claim.
reasonix-2026-08-10-source →No implementation currently clears the Snapshot + Claim threshold; this is not a claim that the product lacks the capability.
Inspect coverage boundary →CLAIMS · EVIDENCE LEDGER3 RECORDS
sourcereviewed
grok-build-source-retry-policy
Grok Build's pinned sampler retry module produces explicit decisions for rate limits, transient failures, context limits, image fallback, and client rebuilds, using retry-after or exponential jitter while leaving fatal outcomes non-retryable.
- Agent
- Grok Build
- Snapshot
- grok-build-2026-08-10-source
- Reviewed
- 2026-08-10
sourcereviewed
opencode-source-retry-policy
OpenCode's pinned retry policy classifies provider and HTTP failures, honors retry-after metadata, applies bounded exponential delay, and excludes non-retryable failures such as context overflow.
- Agent
- OpenCode
- Snapshot
- opencode-2026-08-10-source
- Reviewed
- 2026-08-10
source + sourcereviewed
reasonix-source-retry-recovery
Reasonix replays one frozen sampling payload across bounded stream-recovery attempts, commits only the selected clean attempt, and separately breaks repeated identical write-like failures after a small threshold unless a safe state recheck clears the signature.
- Agent
- Reasonix
- Snapshot
- reasonix-2026-08-10-source
- Reviewed
- 2026-08-10
EXPERIMENTS · EXERCISES
What has actually been tested?
Formal experiments are separate from course exercises. Exercises can validate the reference implementation but cannot replace Native evidence from a real agent.
Formal experiment · not registered
No experiment record means untested, not passed. The course checks below cover only the deterministic reference harness.
s01-agent-loopobserve
Verify the Golden TraceThe committed JSONL exactly matches a real demo run and passes the trace schema.
python3 -m curriculum.golden verify s01-agent-loops01-agent-loopmodify
Preserve loop invariantsA completed run keeps contiguous sequence numbers and ends with session.stop.
python3 -m unittest curriculum.tests.test_vertical_slice.VerticalSliceTests.test_s01_minimal_loop -vs03-tool-dispatchobserve
Verify the tool roundtripThe request, result, and second model request appear in causal order.
python3 -m curriculum.golden verify s03-tool-dispatchs03-tool-dispatchmodify
Test the dispatch contractThe tool result returns to the next turn as a tool message bound to tool_call_id.
python3 -m unittest curriculum.tests.test_vertical_slice.VerticalSliceTests.test_s03_tool_roundtrip -v01
Which retries are safe before a provider response is committed?
02
How should repeated tool failures be recognized without suppressing legitimate retries?
03
What state must be persisted so recovery never replays a mutation accidentally?