Three Endurance Rules
A context-usage curve and compression-threshold demo; three tasks: find the forgetting turn, write three rules, run a write-to-disk-then-read-back loop
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Three Endurance Rules”?
A context-usage curve and compression-threshold demo; three tasks: find the forgetting turn, write three rules, run a write-to-disk-then-read-back loop
Follow the handoffs, not the demo. A system becomes dependable at the boundaries between model, tools, state, permissions, and people. Read each handoff as a place where you can observe, test, and recover.
Name the input, owner, approval, and recovery action for one automated step.
A successful run that cannot explain what happened or be safely repeated.
When a user says "it got dumber as we talked," what's behind that is a very concrete curve: context usage climbs turn by turn, and once it's full the system can only quietly throw things away. What it throws is usually the earliest messages — the most important rules you laid down at the start.
20 turns of continuous chat: how context usage moves
Three rules, three kinds of forgetting
Compression threshold handles "only act when it blows up": compress when usage hits the line. Don't wait for an error.
Never-delete list handles "compressed too hard": the user's original words, the agreed requirements, the safety constraints — once those go into a summary you can't get them back. They must stay pinned in context.
Notes on disk handles "forgetting across sessions": write important conclusions to a file, and read the file first next time you start. That's what this chapter calls "filesystem persistent memory," and it's the starting point of Harness self-improvement. It has to remember what it learned last time before it can improve itself.
This Chapter's Hands-on Checklist
0 / 3 done
Find the turn it starts forgetting
15 min EveryonePull up your longest conversation with an AI. Read it from start to finish. Find the first turn it forgot something you had already told it. Write that number down — that's your Agent's real endurance with no management at all.
What counts as done
Write your three endurance rules
1 hour Anyone whose Agent runs long tasksMake the three rules concrete for your scenario: compress when usage hits what percent, which content never enters the compression zone (make a list — don't write vague junk like "important content"), and which conclusions get written to a file. Then paste them into your Agent config or system prompt.
What counts as done
Run one "write to disk, then read it back"
Half a day Anyone who works across sessionsAfter the Agent finishes a piece of work, have it write the conclusions into a fixed file (call it a work note). Then close the session, open a brand-new one, and as the first message tell it to read that file and continue. If the new session picks up seamlessly, you've just implemented this chapter's structured-notes pattern — the simplest and most useful form of long-term memory.
What counts as done
How “See it first · Forgetting is a curve you can draw” becomes executable
“When a user says "it got dumber as we talked," what's behind that is a very concrete curve: context usage climbs turn by turn, and once it's full the system can only quietly throw…” is not about a magic phrase. It is about giving the model enough information to know who the work is for, what must be done, and what counts as acceptable.
Background sets direction; constraints set the boundary
“Compression threshold handles "only act when it blows up": compress when usage hits the line.” shows why a useful request separates the task, audience, source material, output format, and constraints. Without background, the model guesses. Without acceptance criteria, fluent text is not evidence that the task is complete.
More words do not guarantee a better result
Turn “What M4 needs to record: the forgetting turn, the three rules in full, and where the on-disk notes live.” into a small experiment: change only one of background, requirements, or constraints while keeping the rest fixed, then observe which layer actually changes the output.
From “See it first · Forgetting is a curve you can draw” to “Hands-on checklist · Pick one, start it, tick it off”
“See it first · Forgetting is a curve you can draw” grounds the problem in “When a user says "it got dumber as we talked," what's behind that is a very concrete curve: context usage climbs turn by turn, and once it's full the system can only quietly throw things away . What it throws i…”. “Hands-on checklist · Pick one, start it, tick it off” then moves it toward “Pull up your longest conversation with an AI. Read it from start to finish. Find the first turn it forgot something you had already told it . Write that number down — that's your Agent's real endurance with no…”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
Build a request layer by layer: task and audience first, material and output rules next, constraints and acceptance checks last. Change one layer at a time so you know what actually helped.
- “See it first · Forgetting is a curve you can draw”: When a user says "it got dumber as we talked," what's behind that is a very concrete curve: context usage climbs turn by turn, and once it's full the system can only quietly throw things away . What it throws i…
- “Hands-on checklist · Pick one, start it, tick it off”: Pull up your longest conversation with an AI. Read it from start to finish. Find the first turn it forgot something you had already told it . Write that number down — that's your Agent's real endurance with no…
- “The closing point”: What M4 needs to record: the forgetting turn, the three rules in full, and where the on-disk notes live. The next square is the last one: turn the whole process into a spec someone else can reproduce
The final “The closing point” brings the discussion to “What M4 needs to record: the forgetting turn, the three rules in full, and where the on-disk notes live. The next square is the last one: turn the whole process into a spec someone else can reproduce”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.