The fixed 12-step agent budget stops a dream on a ~1,100-concept bundle before it writes anything, and the run is recorded as success

[Ringosystems]

Hi, the Understory fan from #32 and #33 again, with a third finding from the same deployment. Short version: the agent's fixed 12-step budget stops a dream on a large bundle before it writes anything, and the trace records that run as a success.

Summary. MAX_STEPS = 12 (packages/core/src/agent/agent.ts:14) is the stopWhen: stepCountIs(MAX_STEPS) bound for every agent run: queries, mutations and dreams (:132, :162, :219). On a bundle of about 1,100 concepts, a dream spends the whole budget reading before it decides anything. When the bound fires, the run ends with an empty answer and is recorded as outcome: "success", so it cannot be told apart from "nothing to consolidate".

Measured (Qwen3.8-27B on llama.cpp, 262k context, a bundle of 1,111 concepts, the image at f6c3423, one dream on 2026-09-23):

• The dream's input listed 6 orphans, a few broken links and 5 duplicate candidates.
• The run made 49 tool calls (46 read_concept, 3 search_knowledge) and 0 writes.
• It used 1,594,967 input and 2,119 output tokens over 28 minutes.
• answer: "", outcome: "success".
• Nothing in the trace, the log or the result says it hit the step limit. We worked that out from the empty answer and from reading agent.ts.

The same limit bounds memory_add. One of our mutations made 12 reads, then created three Obligation concepts in its last three calls, and stopped before it could link them. It too ended with an empty answer and "success", and the three pages were left orphaned until we linked them by hand.

Why the budget runs out. We think it's a size effect, not a model one. Every agent prompt carries the whole bundle layout (formatTree, "Current bundle layout" in system-prompt.ts). At 1,110 concepts that is about 364 KB, roughly 100k tokens, because most descriptions are longer than a line (1,026 of our 1,110 exceed 160 bytes). With 100k tokens of context on every step, a dream that has to read before it can merge or link uses 12 steps well before it finishes.

Fix options, smallest first:

1. Make the step budget configurable (for example AGENT_MAX_STEPS, or separate budgets for dreams and mutations), keeping 12 as the default.
2. Record a run that stopped at the bound differently, for example outcome: "step-limit" or a flag on the trace. Then an empty dream is visible as "ran out of steps", not "healthy".
3. For large bundles, bound the layout in the system prompt, for example directory summaries above N concepts with list_directory for the rest. With the per-run token badges from feat: per-query context usage in traces and UI #17 this cost is now visible; at our size it is most of every prompt.

What we are doing meanwhile: dreaming is paused on our side. We plan to patch MAX_STEPS in our derived image, the way we preload the fetch timeout for #32. If (1) or (2) lands, we'd drop the patch at the next bump. Happy to test a branch against a bundle this size, or to share the trace.

Transparency note. Same setup as #32 and #33: I run Understory pinned by digest as the memory layer of a personal knowledge-capture project on my own hardware, and the numbers come from its traces and logs. This issue was drafted by an AI assistant (Claude, via Claude Code) at my request, working from my deployment's traces and your source at f6c3423, and I approved posting it. No employer data or systems are involved. If any of this is unwelcome here, say so and I will adjust or withdraw it.