Summary
Long-running Autoloop programs accumulate hundreds of iterations, which makes the per-program state file in memory/autoloop grow without bound. Two concrete problems follow:
- Repo-memory's default size limit is exceeded. The state file gets rejected by the memory tool; the pre-step then can't read or write state and the scheduler breaks.
- Agent context window floods. The state file is read in full on every iteration; hundreds of iteration log entries bury the useful state behind pages of stale history.
The fix has two pieces — a max-file-size bump in frontmatter and an explicit compaction rule in the agent prompt.
Current upstream state
workflows/autoloop.md frontmatter:
```yaml
tools:
repo-memory:
branch-name: memory/autoloop
file-glob: ["*.md"]
```
No explicit max-file-size. The default (around 4 KB) is quickly exceeded once a program has ~30 accepted iterations.
The state-file update prose (around upstream line 1162) says "prepend a new entry to Iteration History" but has no guidance on bounding the total size.
Proposed change — two pieces
A. Set an explicit max-file-size
```diff
tools:
repo-memory:
branch-name: memory/autoloop
file-glob: ["*.md"]
- max-file-size: 30720 # 30 KB — enough for ~150 iteration entries after compaction
```
30 KB is a reasonable default. Users with short-schedule programs (every 5m) should size up; users with daily-cadence programs can size down. The number should be documented as tunable.
B. Add a rolling-compaction rule
In the state-file update guidance (Step 5a-style post-accept flow), add a new bullet:
```markdown
-
Keep the state file compact. The state file must stay under the configured `max-file-size` (default 30 KB). When prepending a new iteration entry, collapse older iteration entries (beyond the most recent 10) into compressed summary lines. Example format for collapsed entries:
Iters 50–100 — ✅ (metrics 20→55): brief summary of what worked across this range
Also prune Lessons Learned to the most recent and relevant entries. If Foreclosed Avenues grows beyond a page, consolidate similar entries.
```
The compressed-range format (### Iters 50–100 — ✅ (metrics 20→55): …) is a useful convention that preserves enough signal (range of iteration numbers, status, metric band, one-line summary) without storing per-iteration noise.
C. Make the rule actionable — new autoloop.json field (optional)
The scheduler can report the current state-file size as state_file_size_bytes in autoloop.json. The agent prompt can then check "if size > 0.8 × max-file-size, compact aggressively this iteration" rather than lazily compacting only on overflow.
Why 30 KB, not more
A 100 KB state file full of iteration history costs a real chunk of the agent's context window every run and slows down every read/write. 30 KB is enough for the structured sections (Machine State + Current Priorities + Lessons + Foreclosed + Future Directions) plus ~10 most-recent iteration entries plus ~5 compressed-range summaries. Beyond that, value-per-byte drops sharply — older iterations' per-run detail is rarely referenced.
Related
Independent of other issues in this batch; can land first.
Summary
Long-running Autoloop programs accumulate hundreds of iterations, which makes the per-program state file in
memory/autoloopgrow without bound. Two concrete problems follow:The fix has two pieces — a
max-file-sizebump in frontmatter and an explicit compaction rule in the agent prompt.Current upstream state
workflows/autoloop.mdfrontmatter:```yaml
tools:
repo-memory:
branch-name: memory/autoloop
file-glob: ["*.md"]
```
No explicit
max-file-size. The default (around 4 KB) is quickly exceeded once a program has ~30 accepted iterations.The state-file update prose (around upstream line 1162) says "prepend a new entry to Iteration History" but has no guidance on bounding the total size.
Proposed change — two pieces
A. Set an explicit
max-file-size```diff
tools:
repo-memory:
branch-name: memory/autoloop
file-glob: ["*.md"]
```
30 KB is a reasonable default. Users with short-schedule programs (
every 5m) should size up; users with daily-cadence programs can size down. The number should be documented as tunable.B. Add a rolling-compaction rule
In the state-file update guidance (Step 5a-style post-accept flow), add a new bullet:
```markdown
Keep the state file compact. The state file must stay under the configured `max-file-size` (default 30 KB). When prepending a new iteration entry, collapse older iteration entries (beyond the most recent 10) into compressed summary lines. Example format for collapsed entries:
Iters 50–100 — ✅ (metrics 20→55): brief summary of what worked across this range
Also prune Lessons Learned to the most recent and relevant entries. If Foreclosed Avenues grows beyond a page, consolidate similar entries.
```
The compressed-range format (
### Iters 50–100 — ✅ (metrics 20→55): …) is a useful convention that preserves enough signal (range of iteration numbers, status, metric band, one-line summary) without storing per-iteration noise.C. Make the rule actionable — new
autoloop.jsonfield (optional)The scheduler can report the current state-file size as
state_file_size_bytesinautoloop.json. The agent prompt can then check "if size > 0.8 × max-file-size, compact aggressively this iteration" rather than lazily compacting only on overflow.Why 30 KB, not more
A 100 KB state file full of iteration history costs a real chunk of the agent's context window every run and slows down every read/write. 30 KB is enough for the structured sections (Machine State + Current Priorities + Lessons + Foreclosed + Future Directions) plus ~10 most-recent iteration entries plus ~5 compressed-range summaries. Beyond that, value-per-byte drops sharply — older iterations' per-run detail is rarely referenced.
Related
Independent of other issues in this batch; can land first.