Long-Session Strategies

Introduction

Compression keeps a single session alive past its natural budget. For genuinely long-running work (research, multi-day investigation, an agent that runs for hours), compression alone is not enough. You combine it with a small set of other tactics that, together, let an agent operate for hours without quality degradation.

Key Concepts

• Delegation: Spawn a subagent (delegate_task) for a sub-task so its context is isolated.
• Checkpointing: Save the session state before risky operations so you can roll back without re-running everything.
• Persistent memory writes: Promote the most important facts out of session memory and into MEMORY.md before compression collapses them.
• Session restart with handoff: End the current session with a brief handoff note, start fresh.

Real World Context

A security researcher runs a multi-day Hermes session investigating a vulnerability. By day two, the buffer would be hopelessly bloated if every tool call lived in it. Instead, each investigation thread runs as a delegated sub-task. Findings are promoted to MEMORY.md at the end of each thread. The parent session stays lean and the work compounds.

Deep Dive

The four-lever model for long sessions:

1. Compress when the buffer is crowded: First lever. Free tokens, keep going.
2. Delegate when the sub-task is bounded: If you can describe the sub-task in one paragraph, give it to a subagent. The parent session sees the result, not the trail.
3. Promote what should survive: If the session produced a finding the agent should know forever, ask it to write the finding to MEMORY.md before compression risks losing the detail.
4. Restart when context is irrecoverable: If even compression leaves the buffer unsalvageable, end with a handoff ("summarize the state in five bullets") and start a fresh session referencing that summary via @-injection.

These levers complement each other. Compression is reactive; delegation is preventive; promotion is durable; restart is the reset button. A skilled operator uses all four, not just one.

A common anti-pattern: trying to do everything in a single sprawling session. The agent feels powerful, the operator feels in command, and quality degrades silently. The fix is structural: smaller sessions, more delegation, more promotion of stable facts into persistent memory.

Finally, do not mistake "long session" for "productive session". A four-hour session that produces three good decisions is worse than four one-hour sessions that produce one good decision each, because the four-hour session pays for the entire buffer on every turn. Operator habit matters more than tooling.

Common Pitfalls

1. Hoarding context out of fear of losing it: Compression and delegation feel like "losing" the work; promotion to memory is how you actually keep what matters.
2. Treating long sessions as a virtue: Length is not value. A clean, restarted session often outperforms a long carryover.

Best Practices

1. Decide upfront whether a task fits in one session or needs delegation: Estimate the tool calls. If it is more than a few, delegate.
2. Promote findings to persistent memory before compression: Anything you want the next session to know belongs in MEMORY.md, not in turn 40 of this one.

Summary

• Long sessions need more than compression; combine compress, delegate, promote, and restart.
• Compression is reactive; delegation prevents bloat in the first place.
• Promoting findings to MEMORY.md is how good outcomes survive across sessions.
• Operator structure beats raw session length; a clean restart often outperforms a sprawling continuation.

# A long-session ritual:

1. Start: review USER.md, MEMORY.md, AGENTS.md (auto-loaded). Skim status bar.
2. Hit a sub-task with bounded scope?    →  delegate it.
3. Tool output huge but no longer needed? →  /compress.
4. Finding worth keeping forever?         →  ask agent to write to MEMORY.md.
5. Buffer past 90% and unsalvageable?     →  handoff summary + fresh session.