Long-Horizon Tasks: Planning, Checkpointing, and Recovery

Why Long-Horizon Tasks Need Different Discipline

Everything so far in this course has assumed tasks measured in seconds to minutes. A task that runs for hours, or spans multiple sessions over days, needs two things a quick task doesn’t: an explicit plan to check drift against, and a way to resume cleanly if it’s interrupted, rather than restarting from zero.

Planning Before Executing

Hermes ships a bundled plan skill (the same skills system from Lesson 11, just one of the pre-authored, stress-tested ones from Lesson 19) built for exactly this. Instead of immediately executing a large request, it inspects context, writes a markdown implementation plan, and saves it, rather than diving straight into action:

/plan Refactor the authentication module to support SSO,
covering the three identity providers listed in the design doc.

Hermes: [inspects the codebase and design doc]
        Plan saved to .hermes/plans/sso-refactor.md

# .hermes/plans/sso-refactor.md

## Goal
Add SSO support for Okta, Azure AD, and Google Workspace to the
existing auth module, without breaking current password-based login.

## Steps
1. Audit current auth module structure and identify integration points
2. Add a provider-agnostic SSO interface
3. Implement Okta provider (reference implementation)
4. Implement Azure AD provider
5. Implement Google Workspace provider
6. Update login UI to offer SSO options
7. Write integration tests for all three providers
8. Update documentation

## Status
- [x] Step 1: complete, see notes below
- [ ] Step 2: in progress
- [ ] Steps 3-8: not started

## Notes
Step 1 findings: current auth module is tightly coupled to the
password flow in `auth/core.py`. Step 2 will need to introduce
an interface there before any provider-specific work begins.

This is the same skill-writing discipline from Lesson 11, applied to planning rather than execution: a durable, disk-based artifact rather than something that only exists inside one conversation’s context.

Why Saving to Disk Matters

A plan that only lives in chat history disappears the moment that session ends, or becomes expensive to reconstruct if you need to hand the task to a fresh session, resume after a terminal backend hibernation cycle (Lesson 14), or check progress days later. Saving to .hermes/plans/ gives you a fixed, durable reference point that survives all of that.

Checkpointing Progress, Not Just Environment

Lesson 14 covered serverless terminal backends that hibernate between active periods and preserve filesystem state on wake. That solves environment persistence, but not task-progress tracking, those are separate concerns. Waking a hibernated sandbox gets your files and installed packages back; it doesn’t tell the resumed agent which of the plan’s eight steps it had actually reached.

The fix is explicit: update the plan’s status section as steps complete, the same - [x] / - [ ] pattern shown above, so resuming means reading the plan file first, then continuing from the last completed step, rather than re-deriving progress from scratch or (worse) silently redoing completed work.

Continue the SSO refactor from .hermes/plans/sso-refactor.md

Hermes: [reads the plan file]
        Step 1 and 2 are marked complete. Resuming at step 3:
        implementing the Okta provider...

Watching for Drift

Periodically, especially after any interruption or hand-off, check actual progress against the saved plan rather than assuming the agent has stayed on track:

Compare what you've actually built so far against
.hermes/plans/sso-refactor.md. Where have you deviated, and why?

Asking this explicitly surfaces drift while it’s still cheap to correct, a step that quietly expanded in scope, a requirement that got reinterpreted, before hours more work compounds on top of a wrong turn.

Exercise: take a genuinely multi-step task you have queued up (not a toy example), run /plan on it, and review the saved plan file before letting the agent execute anything. Then, partway through execution, deliberately interrupt the session (close it, or restart your terminal backend) and practice resuming from the plan file alone, confirming the status section accurately reflects what was actually done.