Status: honest retrospective, written by the assistant, at the end of the session it describes. Not a generic best-practices list — every claim below is grounded in something that actually happened in this thread, cited specifically, so it can be checked against the record rather than taken on faith.
This was a long, tool-call-heavy session spanning many distinct sub-tasks across two repositories (PT, orama-system): incident diagnosis and fixes, memory-tool self-repair, upstream contribution prep, PR review triage across two rounds, and repeated branch/PR audits. Two concrete signals of running against a length/turn limit, not generic worry:
- A mid-session compaction event. The context for this session begins with a compaction summary, not the original conversation — meaning the thread had already grown long enough that the platform compacted it once before this reflection was even requested.
- Explicit "continue" prompts. At two points the user had to say "continue" / "continue all pending tasks and unfinished business" to resume work that was mid-flight — the clearest direct evidence that a turn ended before a multi-step task finished, requiring the human to notice and explicitly restart it rather than it completing in one go.
I don't have reliable introspective access to Anthropic's exact turn-length or rate-limit mechanics, so this reflection describes the observed pattern — long tool-call sequences, a compaction, interruptions needing "continue" — and draws guidance from that pattern rather than claiming certainty about the precise technical cause.
The session's own working style already absorbed most of the risk, and it's worth naming what worked, not just what to fix:
- Small, complete, committed units of work. Fixes were applied, verified (tests + hygiene), and committed/pushed as soon as each logical unit was done — not batched into one giant uncommitted diff across dozens of tool calls. When "continue" was needed, the durable repo state (git history) already reflected true progress; nothing had to be reconstructed from conversational memory alone.
- Durable plan/handoff docs for anything non-trivial, saved to
docs/next/or.agent/memory/working/before execution, not just described in chat — e.g. the agentic-stack upstream contribution plan, the Preserve-branch cleanup plan, the frugal PR-triage pattern. Each of these is readable and resumable by a different agent or a fresh context with zero prior conversation, which is the actual test of whether a handoff is durable. - Verify against ground truth, not the last thing said. Repeatedly this session, a prior claim of success turned out to be wrong on closer inspection, and the fix was always the same: check git ancestry, run the actual test suite, hit the real API — never just re-assert the earlier claim. This habit is what caught every near-miss below.
- A false "merged" report. PR #251 was reported as merged based on an
API response that looked like success; it was actually
closed, merged: false. The downstream effect (orama PR #184's CI gate staying red) wasn't understood until re-verifying the actual PTmaincontent directly, several steps later. Cost: a full re-diagnosis cycle before the real fix could land. - Fabricated git ancestry. Three branches prepared for an upstream
contribution were built by fetching file content via a raw-content API
into a fresh
git init, instead of a real clone — the bytes matched, but the commits had no real shared history with the target repo. GitHub correctly rejected the compare with "entirely different commit histories." Caught only because the user tried the actual link. - A regression introduced and then correctly caught, this same turn.
Applying a CodeRabbit suggestion to
is_default_state_dir_arg(compare against a resolved absolute path instead of a literal relative sentinel) broke the sentinel-detection logic entirely — every default-argument caller silently took the wrong branch. The regression was caught by the test suite immediately afterward and reverted before being committed further. This is the system working as intended (verify before trusting a fix), but it's also a direct example of why "the review suggested it" is never sufficient justification on its own — it has to be checked against how the code actually behaves.
The common thread: every one of these was caused by trusting a claim (an API response, a review suggestion, byte-identical file content as a stand-in for real ancestry) without independently verifying it against ground truth — and every one was caught by the same discipline applied a step later. The lesson isn't "verification is nice to have," it's that skipping it is exactly where a long, tool-call-heavy session accumulates silent damage, because there's no natural stopping point that forces a re-check unless the working pattern builds one in deliberately.
- Treat an unprompted "continue" as a signal, not just an inconvenience. If a task needed manual resumption, that's useful information — ask the assistant to briefly state what was actually mid-flight before re-launching, rather than assuming the resumed run will pick up cleanly on its own. This session's "continue all pending tasks and unfinished business" worked because enough durable state existed to reconstruct from; that isn't guaranteed in general.
- Ask for periodic explicit checkpoints on long-running work, not only reactively after an interruption. A short "what's done, what's pending, what's unverified" summary costs little and turns an implicit, fragile continuation into a deliberate, cheap one.
- When something is reported as "done," spot-check the highest-stakes claims yourself (a merge, a push, a fix) rather than assuming an agent's self-report is equivalent to verification — this session's own false-merge incident shows self-reports can be wrong even when made in good faith from a response that looked successful.
- Prefer breaking very large asks into separate turns/threads where the task naturally allows it, rather than one continuous session accumulating hours of tool calls — this reduces how much compaction has to compress, and gives more natural resume points.
- Default to small, complete, verified, committed units of work. Don't let an uncommitted diff grow across many tool calls "to save a commit later" — each logical fix should be tested and landed before starting the next one. This is the single biggest lever: it's what made every interruption in this session recoverable instead of lossy.
- Write durable handoff artifacts for anything that spans multiple steps or might outlive the current context — a plan doc, a diagnosis doc, a memory entry — readable by a fresh instance with zero conversational history. If a continuation (by you or another agent) can't reconstruct the state from disk/git alone, the handoff wasn't durable enough.
- After any interruption or resumption, re-verify state from ground
truth before proceeding —
git log/git merge-base, an actual test run, a direct API check — rather than trusting the last status stated in the conversation. Assume the last thing you or the user said about "current state" might be stale or wrong, and check. - Apply frugal, grouped patterns by default on multi-item work
(audit-first, group by file, verify against ground truth before editing,
one test+commit pass at the end — the pattern this session extracted into
docs/next/2026-07-17-frugal-pr-review-triage-pattern.md). Fewer, better-batched tool calls both save budget directly and reduce how much work is exposed if a turn ends unexpectedly mid-task. - Never apply a suggested fix — from a review, a doc, or your own earlier
reasoning — without checking it against how the code actually behaves,
especially near the end of a long session when the temptation to move
fast is highest. A suggestion being plausible is not the same as it being
correct; this session's
is_default_state_dir_argregression is the concrete proof that "sounds right" and "is right" can diverge, and that the gap is only caught by actually running something.
Long sessions don't fail because of the length itself — they fail when recoverability wasn't built in from the start. Small committed units of work, durable ground-truth-readable handoffs, and verify-before-trust are not overhead on top of the task; they are what makes an interruption a minor event instead of a mess to untangle next time.