You're working on something substantial. Not a quick task you can finish in one sitting—a real project that matters. Maybe it's a multi-phase contract review. A marketing campaign launch spanning several weeks. A comprehensive literature review for your research. A consulting engagement with multiple deliverables. You've estimated five hours of work, but life happens. You close the laptop after ninety minutes, promising to continue tomorrow.
Tomorrow arrives. You open Claude Code. Where were you? What decisions did you make? Which aspects did you complete? What's left?
Without a system, you spend the first thirty minutes re-establishing context—re-reading documents, re-explaining the goal, hoping Claude picks up where you left off. Sometimes it does. Often it doesn't. Work gets repeated. Decisions get forgotten. Progress feels like walking up an escalator going down.
This lesson introduces the architecture for long-horizon work: progress files that persist state across sessions, task decomposition that turns vague goals into trackable deliverables, and session protocols that ensure every session starts informed and ends with work preserved.
Lesson 6 taught you when to /compact versus /clear. But compaction and session resumption only help within a single narrative—a conversation that grows, gets compressed, and continues.
Real projects don't work that way.
Real projects span multiple days, interrupted by meetings, sleep, weekends, and the hundred other demands on your attention. Each interruption creates a session boundary. Each session boundary creates a continuity problem.
Claude Code offers --continue to resume the most recent session, but sessions accumulate context rot (Lesson 2). After 3-4 days, resumed sessions become convoluted—too many tangents, too much noise. You need a different architecture.
Harrison Chase, CEO of LangChain, introduced what he calls the "harness architecture" for long-horizon tasks. The insight: don't try to maintain one continuous conversation. Instead, treat each session as independent, coordinated through a shared artifact.
Traditional single-agent architecture:
One session, one agent, one conversation. Context accumulates until it overflows. Works for tasks you can finish in one sitting.
Long-horizon harness architecture:
The progress file becomes the coordination mechanism. Each session reads it to understand state, does work, then writes back to it. Sessions don't need to share context—they share the file.
Think of it as two collaborating agents:
The Initializer Agent runs once at project start. Its job:
The Working Agent runs in each subsequent session. Its job:
You might be thinking: "But I'm using Claude Code for both." Yes. The distinction is mental, not technical. The Initializer phase happens in your first session. Every subsequent session is a Working Agent session. The progress file bridges them.
Here's the template that makes this work:
Let's break down why each section matters.
The session markers aren't just for tracking. They help future-you understand the project arc. If something goes wrong in Session 5, you can trace back: "The stakeholder feedback was Session 3—what else changed then?"
Don't just mark things "in progress." Annotate them. What's done within this task? What remains? When you return after a weekend, this annotation prevents you from re-doing completed subtasks.
Blocked items need specific blockers. "Blocked on information" is useless. "Blocked on Q4 market data from finance team" is actionable—you can follow up with them.
This is the most undervalued section.
Why does this matter? Because in Session 7, you'll look at your deliverable and think "Why did we organize by business unit? Should we reorganize by timeline?" Without the decision log, you'll have to research the tradeoffs again—or worse, restructure and introduce inconsistency.
The decision log is your institutional memory. It answers "why did we do it this way?" when you've forgotten.
Known issues aren't failures—they're conscious acknowledgments of limitations. You know about them, you've assessed their impact, you have a plan. This prevents the "surprise" of discovering problems you actually knew about but forgot.
The session log is narrative context. When the progress file sections give you facts, the session log gives you story. "Hit a snag with competitor data formatting" explains why Session 3 took longer than expected.
The harness architecture only works if your tasks are granular enough to complete within a session. "Complete the market analysis" isn't a task—it's a project. You need decomposition.
Bad decomposition:
These are too vague. "Do the research" could take five sessions or fifteen. You can't track progress against it. You can't know when you're 50% done.
Good decomposition varies by domain. Here are examples across professional contexts:
Notice what all these decompositions share:
The 10-15 rule: For a ~5 hour project, aim for 10-15 granular tasks. Fewer tasks means each is too large; more means overhead exceeds value.
When facing a large project, use this questioning protocol:
Apply this recursively until each answer is a 30-90 minute task.
Every work session should start the same way. Consistency prevents context-reconstruction delays.
The Five-Step Initialization:
In practice, tell Claude at session start:
This prompt does several things:
The output should look like:
Now you know exactly where you are. No reconstruction. No guessing.
Ending a session well is as important as starting one well. The exit protocol ensures continuity.
The Two-Step Exit:
The Work Checkpoint Pattern:
Never end a session with work in an unstable state. This is critical.
If your deliverable is half-edited with notes to yourself scattered throughout, next session starts with cleanup instead of progress. If your research notes are unsorted, you'll waste time re-organizing before you can continue.
Different domains have different checkpoint mechanisms:
The checkpoint becomes a recovery point. If next session goes badly, you can return to this state. Your progress is preserved even if your experiments fail.
Progress File Update:
At session end, update all sections:
Example update prompt:
Progress files and version control work together. Your checkpoint history becomes a recovery mechanism.
Recovery scenario:
Checkpoint naming convention:
Cloud storage with version history:
Recovery scenario: Your latest edits made the document worse. You can't remember what it looked like before.
Citation manager checkpoints:
Note-taking checkpoints:
Whatever your domain, your progress file should capture checkpoints:
You've lost one session's work, not four. The progress file from the previous session tells you exactly where you were. Resume from there.
Objective: Complete a real project across 5 sessions using progress tracking. Experience the full harness architecture lifecycle.
Duration: 5+ hours across 5 sessions (can span multiple days)
Deliverable: A completed project AND a reusable progress file template refined from your experience.
Step 1: Choose a Real Project
Pick something that matters to you—a real work deliverable or personal project. It should require approximately 5 hours of work. Choose from your professional domain:
Legal Projects:
Marketing Projects:
Research Projects:
Consulting Projects:
Software Projects:
Step 2: Create Initial Progress File
Create a text file in your project folder:
Step 3: Decomposition
Ask Claude to help decompose:
Step 4: Populate Progress File
Based on the decomposition, create your initial progress file with all sections. Verify your baseline state (files accessible, tools working). Save your first checkpoint:
Step 5: Complete First Tasks
Work on 2-3 tasks. Practice the checkpoint pattern. End session with progress file update.
For each session:
Start:
Work: Complete 2-4 tasks per session, depending on complexity.
End:
Track: Note what works and what doesn't about your progress file format. What's missing? What's unnecessary?
Final tasks and polish:
Retrospective:
After completing the project, answer these questions:
Continuity: How long did it take to re-establish context at each session start?
Progress accuracy: How well did your decomposition match reality?
Decision utility: How often did you reference the "Decisions Made" section?
Template refinement: What would you change about your progress file format?
Deliverable:
Basic (Passing):
Proficient:
Advanced:
Failure: Vague tasks that never complete
"Address feedback" is infinite. It's never done because it's not defined. Replace with specific tasks: "Incorporate CFO's three budget comments," "Revise executive summary per marketing review," "Add competitor comparison table requested by VP."
Failure: Forgetting to update progress file
You close the laptop without updating. Next session, the progress file is stale. You re-do work that was already done.
Prevention: Make progress file update part of your checkpoint routine. They happen together or not at all.
Failure: Ending with work in disarray
"I'll organize this first thing tomorrow." Tomorrow, you've forgotten what was half-finished. You spend 30 minutes figuring out the current state before you can even start.
Prevention: Never end with work in disarray. If you can't clean it up in 10 minutes, save the stable portions and note clearly what's incomplete.
Failure: Decision amnesia
Session 3: "Let's use conservative projections." Session 6: "Should we use optimistic projections? Wait, did we already decide this?"
Prevention: Every decision goes in the Decisions Made section. Every time.
The harness architecture scales beyond solo work.
Team coordination: Multiple team members can use the same progress file, with session logs attributed to individuals. The file becomes a lightweight standup replacement—everyone reads current state, no meeting required.
Handoffs: When you need to hand work to someone else, the progress file is the handoff document. They don't need to understand your conversation history—they read the file.
Context for AI: Future AI sessions don't share your memory. The progress file IS the memory. Every session's Claude starts fresh but informed.
What you're learning: Task decomposition is a skill that transfers across domains. Most people start too coarse ("complete the analysis") or too fine ("format page 3"). This prompt trains the middle ground—tasks granular enough to track but substantial enough to matter. You're learning to think in completable units regardless of your professional context.
What you're learning: Progress files degrade. Without auditing, they become stale documentation rather than living coordination artifacts. This prompt builds the habit of treating your progress file as a system that needs maintenance, not a document you write once.
What you're learning: Consistency in session starts. By having Claude execute the same protocol every time, you build muscle memory. Eventually, you'll internalize the checklist. Until then, let the prompt be your checklist. You're learning that good processes can be encoded as prompts—whether you're resuming a legal brief, a marketing plan, or a software feature.