I. The 65% datum

Real Python's recent audience research surveyed 278 Python developers about agentic coding workflows. 65% reported being stuck on a context-loss / chat-AI workflow pain that named the gap precisely. One respondent put it in 11 words: "AI is good for solving a small task, but only this."

The diagnosis behind that statistic is right. Real Python's framing — that the problem isn't the AI, it's the workflow — captured something the agentic-tooling space had been talking around. Most coverage of Claude Code, Cursor, and the rest of the agentic-coding category had defaulted to tool questions: which model, which IDE integration, which prompt template. The 65%-stuck cohort answered a different question. They had the tool. The tool worked on small tasks. The workflow was where everything fell apart.

There are two ways to extend that diagnosis into a prescription. The first is to chase the runtime: build pipelines that compose small tasks into bigger ones, add verifier stages that catch errors before they cascade, instrument the runtime with circuit breakers around the unreliable bits. That's the right move at the runtime layer, and a peer engineer named Drew published the canonical write-up of how to do it: Fail-Open LLM Architecture: Why Your Reviewer Stage Should Never Block a Decision.

The second extension is the one this article argues. The 65%-stuck pain isn't only a runtime problem. The runtime layer answers "how do we compose small tasks within a single session?" The other layer — the one Real Python's workshop curriculum legitimately doesn't cover, the one Drew's piece doesn't reach because it stops at the runtime boundary by design — is the session boundary. What happens when session N ends with the work half-finished and session N+1 starts cold? What happens when the context window fills up partway through a refactor? What happens when you close the editor and come back two days later and the agent has no memory of what it was doing?

The right diagnosis is workflow not tool. The right prescription needs more than a tool. This article extends the prescription one layer.

II. Drew's runtime answer

Drew, writing as A3E Ecosystem on dev.to, sets up the runtime case in production terms. His Fail-Open LLM Architecture piece argues, correctly, that "every stage degrades to the simplest correct behaviour when its neighbour fails." The argument starts from a real production incident — OpenAI's API outage on December 11, 2024, when a newly-deployed telemetry service caused every node across hundreds of Kubernetes clusters to execute resource-intensive operations simultaneously, taking the API down for roughly four hours.

The piece then walks through what production-grade LLM pipelines should do about it. The pattern is a three-state circuit breaker around the unreliable stages — typically the reviewer-or-checker stages that sit downstream of the primary model decision. Closed state is normal: requests pass through, the reviewer runs, life is good. Open state is failure: the breaker has seen enough errors that it stops calling the reviewer entirely; requests fail-open with a logged warning, the primary's output passes through unaltered. Half-open state is recovery: after a cooldown window, a probe request tests whether the reviewer is back; if it passes, breaker closes and traffic resumes.

The numbers in the piece are not hypothetical. Well-instrumented circuit breakers around LLM reviewer stages produce 83.5% reductions in cascading failures during upstream incidents. The article cites Anthropic's own degraded period — a roughly nine-month window after the OpenAI outage — where peak failure rates reached 16% and median time-to-recovery sat between 0.77 and 1.23 hours across major providers. Three distinct bugs ran concurrently: a routing error, a TPU corruption, and a compiler bug returning wrong tokens. None of them announced themselves. Detection took weeks because the failures were silent and stochastic. The piece makes a precise claim about silent degradation as a class of failure: it is, the argument goes, always the real enemy, because full outages are at least obvious.

The fix is structural, not heroic. You don't write better reviewers; you build pipelines that don't depend on the reviewer being available. When the breaker fires, the reviewer is treated as missing. The primary's decision passes through with a logged warning that the verification step didn't run. The pipeline returns something correct — possibly slightly degraded — instead of returning nothing. That is what fail-open means at the runtime layer: every stage knows what to do when its neighbour fails. The reviewer falls back to pass-through. Authorization falls back to fail-closed-with-escalation. Content generation falls back to queue-and-retry. Domain-specific error handling, the piece concludes, is what separates production systems from demos.

The runtime answer is right. It's not even controversial — Nygard's Release It! documented the pattern in 2007, Fowler's circuit-breaker bliki entry has been canonical for over a decade, and Netflix's Hystrix project shipped a production implementation engineering teams have leaned on for years. What's new is the application to LLM pipelines specifically: identifying which stages are reviewers (and so candidates for fail-open), which are gatekeepers (and so candidates for fail-closed), which are generators (and so candidates for queue-and-retry).

It stops at the runtime boundary by design. The piece is about what happens inside a single request when one of the stages fails. That's the right scope for a runtime-architecture article. But the 65%-stuck cohort Real Python surveyed wasn't reporting failures inside a single request. They were reporting failures across requests — across sessions, across days, across context windows. The pipeline frame is right; the boundary it covers is one of two.

The session boundary needs the same pattern.

III. The session-boundary mirror

Consider what session N looks like at the moment it ends. The agent has done some work. The user has reviewed some outputs. The conversation has accumulated context — open files, prior decisions, partial implementations, half-debugged bugs. All of that lives in the session: in the model's context window, in the editor's state, in the agent's working memory. None of it persists by default.

Now consider session N+1. It might start the next morning. It might start an hour later after the context window filled up and the conversation auto-compacted, leaving only a summary. It might start because the model timed out, or the network dropped, or the laptop rebooted. From session N+1's perspective, session N's context is gone. The agent has no memory of what was being implemented, what was already debugged, what the user already explained, what was already decided and ruled out.

This is the runtime stage whose neighbour just failed silently. Not a reviewer stage failing inside a single request — the prior session failing as an upstream stage. Without a fall-back, session N+1 has two options: block (ask the user "what were we working on, and where did we leave off?") or hallucinate (invent a context that may or may not match what session N actually did). Both are the cross-session equivalent of "the whole pipeline returns None." Both turn the user into the recovery mechanism.

The cross-session equivalent of Drew's circuit breaker is a Findings Tracker: a markdown artefact written by session N to disk, which session N+1 reads as its first action. The session boundary becomes a fail-open boundary. When the upstream session's context is missing — and at the session boundary it is always missing — the simplest correct behaviour is "read what's on disk." The next session resumes with the same warning convention Drew's reviewer logs: I am reading the tracker, not the live state. Verify before mutating. The pattern transposes one layer up: every session degrades to the simplest correct behaviour when its predecessor's context fails.

To name the artefact precisely, it helps to contrast it with what Claude Code projects already ship.

Claude Code projects ship with a CLAUDE.md file — a markdown document at the project root that captures static persona and preferences. "This project uses pytest. Use type hints. Prefer markdown tables over JSON for status reports." It tells session N+1 who the user is and what the project's conventions are. Real Python's workshop covers CLAUDE.md directly in its lesson on understanding the file.

A Findings Tracker is the task-state layer. It does not record who the user is or what conventions the project uses. It records what work is in flight: this finding is at the Designing stage, F1.4 implementation is checked, F1.5 forge-review hasn't run yet, F1.6 verification depends on an external event scheduled Friday. CLAUDE.md is to a project's .env what a Findings Tracker is to a job-queue checkpoint. One holds static configuration; the other holds dynamic task state.

The two artefacts are complementary — CLAUDE.md is the static project-config layer; the Findings Tracker is the dynamic task-state layer. The workshop curriculum legitimately covers the first; the methodology layer above the agentic tool is the second. They do not compete. They occupy different positions in the same agentic-coding stack.

Most engineering blogs would stop here, having defined the primitive. The interesting question is the next one: what does a Findings Tracker actually look like, and how does the cross-session fail-open behaviour show up in practice?

IV. What a Findings Tracker actually is

Here is one. The tracker below comes from a real ops workflow I run for FluxForge AI™ — an Upwork screening process that captures cohort data on which jobs to bid on, which to skip, and why. The work spanned five sessions across two weeks. I'll show what the file looks like and walk through how the cross-session boundary actually behaves.

The tracker file lives at docs/findings/2026-04-24_1025_upwork_activity_log_FINDINGS_TRACKER.md. The header opens with timestamps and origin:

**2026-04-24 10:25 UTC**

# Upwork Activity Log — Findings Tracker

**Created**: 2026-04-24 10:25 UTC
**Last Updated**: 2026-04-28 20:57 UTC
**Origin**: Session 5 start — S5 handoff Priority 1 (third carry-over across S2, S3, S5).
**Session**: ops 5
**Scope**: Missing rolling cohort record for post-F1 Upwork job screenings.

Created in session 5; last touched in session 10, four days later. The origin field tells session N+1 what triggered the work — in this case, a third carry-over from earlier sessions where the same problem had been deferred. The scope field tells session N+1 what's in and out: this tracker is about the capture mechanism, not about the filter logic that produces what gets captured (that's a sibling tracker).

The Overview section comes next, with a single F1 row table:

| # | Finding | Type | Severity | Status | Stage |
|---|---------|------|----------|--------|-------|
| F1 | Upwork activity log artifact does not exist | Gap | Medium | Verified | Verified |

One finding per tracker; one row per finding. The columns name what kind of work it is (Gap), how urgent (Medium), where it sits in two orthogonal dimensions: Status (Open → In Progress → Resolved → Verified) and Stage (Open → Designing → Blueprint Ready → Planned → Implementing → Reviewed → Resolved → Verified). The Stage column is the closed/open/half-open of the cross-session circuit breaker — it tells the next session exactly where the work paused.

The F1 section that follows the Overview contains the substantive work. Summary, root cause, resolution tasks as checkboxes:

- [x] **F1.1**: Design approach — decide schema, update protocol (→ /design tradeoff)
- [x] **F1.2**: Blueprint + implementation prompt (→ /blueprint)
- [x] **F1.3**: Implementation plan (→ /plan)
- [x] **F1.4**: Implement via /wrought-implement
- [x] **F1.5**: Code review via /forge-review --scope=diff
- [x] **F1.6**: Verify

Six tasks, each tied to a specific pipeline stage. Session N might check off F1.1 and F1.2; session N+1 reads the checkboxes and knows it should start at F1.3. The state is on disk, not in memory.

The cross-session magic moment is the Lifecycle table at the bottom of the F1 section:

| Stage           | Timestamp            | Session | Artifact |
|-----------------|----------------------|---------|----------|
| Open            | 2026-04-24 10:25 UTC | ops 5   | Finding Report |
| Designing       | 2026-04-24 10:40 UTC | ops 5   | Design Analysis |
| Blueprint Ready | 2026-04-24 12:45 UTC | ops 5   | Blueprint + Prompt |
| Planned         | 2026-04-24 13:00 UTC | ops 5   | Plan approved via ExitPlanMode |
| Implementing    | 2026-04-25 18:13 UTC | ops 5   | /wrought-implement iteration 1 |
| Resolved        | 2026-04-25 18:15 UTC | ops 5   | All 12 structural checks PASS |
| Reviewed        | 2026-04-25 18:18 UTC | ops 5   | /forge-review SKIPPED (doc-only) |
| Verified        | 2026-04-25 18:18 UTC | ops 5   | F1.6 closed; carry-over closed |

Eight stage-transition rows. Look at the timestamps: the Designing row was written at 10:40 UTC; the Implementing row was written 30 hours later at 18:13 the next day. Different agent invocations, different conversations, same work item. None of those agents spoke to each other. They read the file.

The Changelog at the bottom captures every session's actions in append-only form — one row per update. If session N+5 needs to understand why a particular decision was made, it reads the Changelog and finds the row that records the decision plus the session it happened in. This is the audit log. git log tells you what changed; the Changelog tells you what was happening. The two views are complementary.

Six months from now, an agent picking up this file knows exactly what was decided, when, and why. The reviewer-around-primary problem at the runtime layer has its session-around-session twin: structured fall-back, explicit warning, persistent log, automatic recovery on next session start. Same shape, one layer up.

V. The methodology layer above the agentic tool

So step back. The 65% of Python developers Real Python's audience research surfaced are stuck somewhere between the agentic tool works on this small task and the agentic tool didn't help me ship the actual feature. That gap has a runtime layer and a session-boundary layer.

The agentic tool answers the runtime question. It composes small tasks within a session — read a file, edit a function, run the tests, observe the output, iterate. That's what the workshop curricula teach, and they teach it well. The Claude Code workshops, Cursor's tutorials, the increasingly mature category of agentic-IDE content — all of it is about the within-session loop.

The Findings Tracker answers the session-boundary question. It's the markdown artefact that lets the next session start where the previous one stopped, with the same fall-back behaviour Drew's circuit breaker provides at the runtime layer: read what's on disk, log a warning that this is post-context state not live state, verify before mutating, then resume.

Together they answer the 65%-stuck problem. Not as a tool fix and not as a runtime-pattern fix in isolation — both are necessary, neither is sufficient. The methodology layer is the layer that makes both work in production.

The Findings Tracker pattern is captured in the open-source Wrought™ plugin for Claude Code (MIT, https://github.com/fluxforgeai/wrought-plugin). Markdown is the substrate; the plugin just automates the writes. The pattern works in any editor with or without it — the trackers are plain markdown files that any session, any agent, any editor can read.

That's the open-core honesty of the artefact: there is nothing magic about the plugin. It generates markdown that follows a particular schema, and the schema is the load-bearing thing. If you fork the schema and never touch the plugin, you still get the cross-session fail-open behaviour. The plugin makes the writes consistent and saves you from re-deriving the schema; it does not own the pattern.

What this article argues is that the methodology layer — the schema, the stages, the verifier-gates, the changelog discipline, the zero-carry-over rule between forge-review runs — is the missing primitive in the agentic-coding stack as it stands in mid-2026. The runtime layer is the workshop's territory, and they own it well. Drew's piece set up half of this argument. The other half is what to do when the session is the stage that just failed.

VI. Closing

If you've built this layer differently — different schema, different state machine, different fall-back convention at the session boundary — I want to hear about it. The pattern as it stands in this article is one shape that works; it is almost certainly not the only shape. The goal is not the schema. The goal is the cross-session fail-open behaviour, expressed concretely enough that the next session knows exactly what the previous one was doing.

If you're chasing the 65%-stuck problem from a different angle — building it into Cursor's memory layer, into LangGraph state, into a custom MCP server, into something else — then the runtime layer and the session-boundary layer are the two places to look. Both need the same shape: the simplest correct behaviour when the upstream stage fails.

— Johan Genis (dev.to/usewrought)