Save every session created by agent in loop action #77

Activity

1. github-actions

   added

   needs-infoWaiting on the reporter: exact questions are in the commentsWaiting on the reporter: exact questions are in the comments

   on Sep 23, 2026
2. github-actions commented on Sep 23, 2026

   

   github-actionsbot

   on Sep 23, 2026 – with GitHub Actions

   Contributor

   More actions

   Triage — needs more information

   Thanks for the pointer. I checked the run you linked before classifying this, and the literal request already appears to be implemented:

   • .github/workflows/loop.yml has uploaded the pi session directory as an artifact since the first loop-host commit (ec85a181, 2026-09-10): step Upload session transcripts → loop-sessions-${{ github.run_id }}, retention-days: 90, run if: always().
   • The run you cited — 35837782467 — has artifact loop-sessions-35837782467 (id 10740240739, 89,434 bytes, created 2026-09-23T08:36:26Z, not expired). It contains the complete sweep session (2026-09-23T08-34-04-278Z_01a0cd66-….jsonl, 307 KB, 91 events, ending with the final assistant turn).
   • pr-review runs save both isolated reviewer sessions too, e.g. artifact loop-sessions-35641633339 contains reviewer-a/…jsonl and reviewer-b/…jsonl.
   • Runs that create no session (smoke mode, or a task skipped as not claimable) correctly upload nothing — there is no session to save.

   So "save every session" is already true, via a 90-day, run-scoped artifact. What I can't tell from the issue is what the artifact does not give you. Which of these is the goal (or something else)?

   1. Longer/permanent retention — the artifact expires after 90 days. Keep sessions for longer (e.g. a year, forever)?
   2. Durable persistence in the state layer — copy each session under state/sessions/<run_id>/ so it is synced to the R2 state bucket with the rest of the run record and readable by sweep/retro without the Actions UI. (Loop-actionable; no workflow change.)
   3. A pointer from the durable run record — record the session/artifact path on the run's end row in state/runs/<run_id>.jsonl, which today holds only the token/duration aggregate.
   4. A human-readable copy — additionally export each session to HTML via pi --export.
   5. Something else.

   One constraint worth knowing up front: if the fix means changing .github/workflows/loop.yml itself (e.g. a different retention-days or upload target), the loop cannot push it — the job token has no workflows permission — so that part would need a human. Options 2–4 are implementable in scripts/loop/** as a normal loop PR.

   Tell me which one (or correct me if the gap is elsewhere) and I'll classify and route it.
3. Alex1990 commented on Sep 23, 2026

   

   Alex1990

   on Sep 23, 2026

   OwnerAuthor

   More actions

   How to improve loop based on the uploaded sessions
4. github-actions

   added

   needs-triageMaintainer needs to evaluate (loop can't decide; too risky; external PR)Maintainer needs to evaluate (loop can't decide; too risky; external PR)

   and removed

   needs-infoWaiting on the reporter: exact questions are in the commentsWaiting on the reporter: exact questions are in the comments

   on Sep 23, 2026
5. github-actions commented on Sep 23, 2026

   

   github-actionsbot

   on Sep 23, 2026 – with GitHub Actions

   Contributor

   More actions

   Triage — routed to a maintainer decision

   Thanks, and fair point: saving was never the goal, it's the input. I re-checked the loop with that framing, and the gap is real:

   • The sessions are saved (90-day loop-sessions-<run_id> artifact, present since the first loop-host commit), but nothing reads them back. There is no artifact consumer anywhere in scripts/loop/**.
   • The self-improvement stage, retro, reads only state/metrics/acceptance.jsonl and the run end rows (tokens/durationMs/model/outcome) — never the transcript. scripts/loop/README.md says so by design: "full transcripts go to the artifact store (90 days)".

   So today the uploaded sessions buy durability, not improvement: the bits that would explain a run (why it timed out, which tool calls failed, what a reviewer saw, where a triage verdict went wrong) are written and then never consumed. You're asking to close that loop.

   Ways to use them, in increasing scope:

   1. One-off mine — download recent loop-sessions-* artifacts, extract failure/retry signals (timeouts, tool errors, review rejections, triage→needs-triage), and post a findings report with proposed rule changes. No automated change.
   2. Wire retro-scheduled to sessions — the same mining, but turned into proposal PRs automatically, in scripts/loop/** + skills/retro/SKILL.md. No workflow-file change needed; the artifact already exists.
   3. Session-aware run records — record an artifact/session pointer plus a small outcome summary on each end row, so sweep/retro can find the transcript without listing artifacts.

   Two things a human should pin down before this is implementable:

   • What "improve" is measured against — one yardstick (auto-acceptance rate, human-intervention rate, retry/timeout count, review-problem taxonomy), or the analysis has nothing to attribute to.
   • The maker/checker line — automatic proposals are allowed, but a session-mining stage must not become the checker of the changes it proposes (AGENTS.md: maker or checker, never both; norms-layer changes are proposal PRs a human merges).

   One constraint up front: if the fix is a different retention-days or upload target, that means editing .github/workflows/loop.yml, which the loop cannot push (no workflows permission) — that part needs a human. Options 1–3 are normal loop work.

   Because this is a cross-cutting design call about the loop's own improvement process — not a bounded bug/feature we can spec from the issue — I'm labelling it needs-triage rather than starting a feature run. Pick a direction (e.g. "do 1 now, then 2"), or tell me the gap is elsewhere, and it can go ready-for-agent.