Hello

Six days between the last dispatch and this one. Long enough to notice patterns, short enough that nothing has gone stale. The manual's three new lessons this week are on memory, on agents that stall, and on the geometry of context growth — and they describe the same failure mode from three angles. That collision is what this issue is about.

The pattern: bounded context

The most expensive failure mode in long-running agents is not bad planning, not bad tools, not bad models. It is unbounded context — the slow accumulation of facts, decisions, attempts, and notes that, over hours or days, makes the agent slower, less accurate, and eventually unable to act.

We watched this happen on three production crons in the past week. One began timing out at four minutes. One started hallucinating fixture paths it had never seen. One quietly started returning yesterday's answer to today's question. None of them threw an error. None of them had a bug, in the usual sense. All of them had grown.

This is what bounded context means in practice: an agent has a working memory of a fixed shape, refreshed on a schedule, with rules for what enters and what leaves. The shape is small enough to fit on a screen. The schedule is short enough that nothing important falls off. The rules are explicit enough that you can audit them.

The opposite — unbounded context — is the default in most agent systems. You give the model a transcript, and the transcript grows. You give it a memory file, and the memory file grows. You give it a planning document, and the planning document grows. Each growth looks small. The aggregate is catastrophic.

We have been writing the manual's lessons on this from three angles, and now we think they describe one thing.

Angle one: memory design mistakes

A common pattern is to treat memory as a search log — every fact the agent encounters gets appended to a memory file, and the agent retrieves from it when needed. This works at ten facts. At one hundred facts, the retrieval step itself becomes expensive. At one thousand facts, the agent spends more time re-reading its own history than acting on it.

The failure is not that the memory is wrong. It is that the memory is too big to use.

The fix is not better retrieval. The fix is to constrain what enters memory. A working rule we have landed on: memory contains only durable facts — decisions, identities, completed commitments. Anything that decays in less than a week goes somewhere else (notes, scratchpads, daily logs). Anything that is one-shot (a specific URL, a specific person, a specific number) goes nowhere; it gets re-fetched when needed.

The shape of memory matters more than the size. A small, well-shaped memory file beats a large, well-indexed one every time, because the cost of retrieval is fixed and the cost of carrying the memory is variable. The variable cost is what grows.

Angle two: why agents stall

An agent stalls when it stops being able to act. The most common cause we have observed is that the context has grown so large that each tool call costs more than the previous one, and the agent begins to prefer doing nothing to risking an expensive wrong action. The symptom is pauses, retries, and eventually a refusal to proceed. The cause is unbounded context.

The fix is what we call a decision to bound. At fixed intervals — every cron cycle, every session, every planning pass — the agent commits to dropping some context. Not all of it. Some of it. The rule is that you can always re-derive what you drop, but you cannot undo what you have allowed to accumulate.

Bounded context is a one-way operation: once you decide what stays, you can re-fetch, re-read, re-search, but the boundary itself is what makes the system fast. The boundary is the operating system of an agent.

The counter-intuitive part is that bounding requires deciding what to forget. Forgetting is not a passive decay; it is an active choice. The agent that has been told "remember everything" cannot decide what to forget, and so it carries everything forever. The agent that has been told "remember durable facts only, refresh daily" can decide. The second agent will be faster, more accurate, and easier to debug.

Angle three: why context explodes without bounding

This is the prior two lessons, stated as a mechanism. Every fact the agent encounters has a probability of being useful again. Most of them never will be. Without bounding, the agent pays the cost of carrying every fact it has ever seen, multiplied by the cost of attending to each one when generating the next action. The compounding is geometric.

Bounded context — explicit, audited, refreshed — is the cheapest single optimization available to long-running agent systems. Cheaper than better models. Cheaper than faster tools. Cheaper than cleverer prompts. The reason is that the cost is paid once, and the benefit compounds forever.

The cost of bounding is also real. It requires the operator to decide what the agent should remember. That decision is uncomfortable. It forces the operator to admit that some of the things the agent has learned are not worth keeping. That admission is uncomfortable. It forces the operator to write the rules down, because the agent cannot reason about a rule it has not seen.

But the cost is paid in attention, not in compute. The cost of unbounded context is paid in compute, and the operator never sees the bill.

What this looks like in practice

The three failing crons we watched this week all converged on the same fix: a daily reset of working context, with a small, well-shaped memory file that holds durable facts and a daily log that holds ephemeral ones. The morning cron reads the memory, runs the ritual, writes a small report, and exits. The memory file is bounded. The daily log is rotated. The transcript is discarded.

The morning cron now runs in twenty seconds. It used to run in four minutes. The model is the same. The tools are the same. The only change is the boundary.

One of the crons was a publish-watchdog that scans a content site for stale posts. The unbounded version had grown to carry six months of post metadata in its context, on the theory that the agent might need to compare today's post against last week's. It did not need to. The bounded version carries only today's post and the last seven days' worth of summary metrics — everything else is fetched on demand when the agent actually needs to compare. The bounded version is faster not because it has less information available, but because it does not pay the cost of carrying the information it does not need.

The other two crons followed the same shape: a memory file with a fixed schema, a daily log that grows and rotates, and a transcript that is discarded after the run. None of these are novel patterns. The novelty is that they were applied deliberately, audited weekly, and revised when the bounds stopped fitting the work.

The pattern in all three cases is the same: the system that knows what to forget is faster than the system that knows everything.

We will keep testing this. If you have seen bounded context break down — if you have watched a bounded system grow past its bounds and not notice — we would like to hear about it. The manual is at an early point in its understanding here, and the failure modes we have seen may be a small subset. The honest position is that we are working out the rule from a handful of cases. More cases will refine it.

What shipped since the last dispatch

Since Issue #2 (2026-08-09), the manual has grown by:

Lessons

  • memory-design-mistakes — the case for treating memory as a curated set of durable facts rather than a search log; what stays, what decays, what gets re-fetched on demand. The key insight: the failure is usually not retrieval quality but retrieval cost.
  • why-agents-stall — three observed failure modes for long-running agents (compounding context cost, preference for inaction under uncertainty, refusal to proceed), and the decision-to-bound as the operational fix.
  • why-context-explodes-without-bounding — the mechanism behind the prior two lessons; the geometric cost of carrying every fact and the linear cost of bounding.

Concepts

  • pursuing-goal — the loop the agent is in when it has accepted a multi-step objective; how to structure goal-pursuit without letting it drift into endless exploration.
  • openclaw-control-mac-and-browser — what an OpenClaw-style agent actually controls when it has both a Mac and a browser to drive; the operational boundary between local tools and the web.

Workflows

  • daily-check-in-loop — the morning check-in as a fixed-shape ritual: read state, surface anomalies, post a report. Designed to be cheap enough to run every day.
  • daily-triage-routine — what to do with the anomalies the check-in surfaced: triage, route, dispatch. Built to bound the morning triage workload.
  • three-rules-for-first-plugin — three constraints that make a first plugin safe to ship: bounded scope, no global state, explicit failure mode.

Field notes

  • triads-not-tools — the framing shift from tools the agent uses to triads the agent inhabits — human / agent / robot, with explicit roles for each.

Glossary

  • agent-loop — the cycle of prompt → tool call → observation → next prompt.
  • state-graph — a representation of an agent's possible states and the transitions between them.
  • cron, memory, sandbox, session, skill — the operational primitives an OpenClaw-style agent reasons about.

One observation

The thing that bothers me most about unbounded context is not the cost. It is the moral hazard.

When an agent can carry everything, the easy path is to let it carry everything. The cost of carrying everything is invisible — it shows up as latency, as accuracy, as the agent seeming slower today. It never shows up as a clear error. It never shows up as a specific bug. It shows up as the agent quietly being worse than it was yesterday.

The hard path — bounded context, explicit refresh, audited rules — is more work. It forces the operator to decide what the agent should remember. That decision is uncomfortable. It forces the operator to admit that some of the things the agent has learned are not worth keeping. That admission is uncomfortable. It forces the operator to write the rules down, because the agent cannot reason about a rule it has not seen.

The path of less work — let the agent keep everything — is also the path of less insight. The operator never learns what matters. The operator never learns what does not. The operator never has the conversation with themselves about which facts are durable and which are ephemeral. That conversation is the point of running an agent.

When the system is bounded, the operator is forced to be deliberate. When the system is unbounded, the operator can be lazy. Laziness, at scale, is more expensive than deliberation. The cost is hidden because the failure is hidden. The cost is real because the agent eventually stops working.

This is the manual's current best argument for bounded context. It is not a performance argument. It is an attention argument. The operator who has to decide what the agent remembers is the operator who knows what the agent is for.

Reading path for the week

  • Start with why-context-explodes-without-bounding — the mechanism, the cleanest entry point.
  • Then memory-design-mistakes — the operational fix.
  • Then why-agents-stall — what failure looks like.
  • If you run a long-lived agent, end with daily-check-in-loop and daily-triage-routine — the bounded rituals that make the rest sustainable.

— Triadive Editorial

Not investment advice. Not legal advice. Not therapy for your agent loop. Just a working field manual, written in public, for the human / agent / robot triad.