What you will be able to do
- Keep a long-running piece of work efficient by managing context and handing state between sessions
- Build verification into a request so that output isn't regenerated by trial and error
- Turn a recurring correction into persistent instructions or a Skill, and decide what belongs there
1.Treat context as a resource, and hand work across sessions cleanly
A workflow that runs over hours or days hits a problem that short requests never meet: context runs out. Anthropic's write-up on long-running agents states the core difficulty plainly. Work happens in discrete sessions, and each new session starts with no memory of what came before. Claude Code's workflow guide offers two everyday responses. You can resume previous conversations so a task can span several sittings, and you can delegate research to subagents so the main context stays clean instead of filling up with exploratory reading.
Automatic summarising of the conversation, called compaction, helps but is not a complete answer. In Anthropic's experiments, an agent that tried to do too much at once, attempting to one-shot an entire app, ran out of context mid-implementation. The next session then had to guess at a half-finished, undocumented feature. Compaction did not prevent this, because it does not always pass perfectly clear instructions forward.
What worked was structure. Each session took on only one feature at a time, committed its progress with descriptive messages, and wrote a summary to a progress file. The next session could then read the current state quickly from a fresh context window. The write-up reports that this also improved efficiency, because agents no longer spent time guessing what had happened and repairing the basics.
A short, deliberate handoff. The state of the work is written down somewhere the next session can read it quickly, like the progress file and commit history in Anthropic's experiments. Then a fresh context starts from a clear summary instead of an overloaded thread, and nobody has to reconstruct what happened.
2.Build the check into the request
Wasteful regeneration usually looks like this: produce an answer, notice it is wrong, ask again, notice something else. Claude Code's best-practices guide cuts the loop short by putting the success criterion inside the request. Give Claude the test cases or the expected result, and ask it to run the check and iterate in the same message. It then corrects itself before handing anything back, instead of making you discover the problem one turn later.
| Strategy | Before | After |
|---|---|---|
| Provide verification criteria | implement a function that validates email addresses | write a validateEmail function. example test cases: user@example.com is true, invalid is false, user@.com is false. run the tests after implementing |
| Address root causes, not symptoms | the build is failing | the build fails with this error: [paste error]. fix it and verify the build succeeds. address the root cause, don’t suppress the error |
For higher-stakes output, the same guide suggests a second opinion. A verification subagent, or a workflow that checks its own findings, has a fresh model try to refute the result, so the worker is not grading its own output. This mirrors the parallelization pattern in Anthropic's agent guidance, where running several attempts or reviewers raises confidence. It is extra machinery, though, so keep it for work where an undetected error would cost more than the additional calls.
A coordinator has been running a Claude-assisted intake process successfully on his own and now wants twelve colleagues to use it. What should he do first?
Correct answer: C — Write down the steps that actually worked and run them on two recent real cases to confirm.
- A. Training people in a procedure that has not been written down or re-tested spreads the gaps as well.
- B. A guide written from his description records what he thinks he does, not what actually worked.
- C. Correct. What works in one person's hands is often partly undocumented habit; writing the steps down and re-running them on real cases is what turns it into something twelve people can repeat.
- D. Twelve personal adaptations produce twelve different results and no shared practice to improve.
3.Make the fix persistent instead of re-solving it
The last source of waste is repetition. If you find yourself correcting the same convention every session, the efficient move is to write it down once where Claude reads it every time. In Claude Code that means the project's CLAUDE.md instructions, or a Skill: a small file of instructions Claude applies when they are relevant. The best-practices guide is specific about what earns a place in persistent instructions and what does not.
| Include | Exclude |
|---|---|
| Bash commands Claude can’t guess | Anything Claude can figure out by reading code |
| Code style rules that differ from defaults | Standard language conventions Claude already knows |
| Common gotchas or non-obvious behaviors | Information that changes frequently |
| Architectural decisions specific to your project | Long explanations or tutorials |
The exclude column matters as much as the include column. Frequently changing information goes stale inside persistent instructions and keeps being applied as if it were still true, so link to a maintained source instead. Long tutorials and things Claude can work out for itself only add bulk to every session. A reusable convention, by contrast, fits naturally into a Skill like the example below.
---
name: api-conventions
description: REST API design conventions for our services
---
# API Conventions
- Use kebab-case for URL paths
- Use camelCase for JSON properties
- Always include pagination for list endpoints
- Version APIs in the URL path (/v1/, /v2/)Sources3
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Automatic compaction means a long task can simply keep running in one ever-growing thread.Why is that wrong?
Compaction does not always carry clear instructions forward. Working in small increments and leaving a written record of progress is what lets a fresh session pick up efficiently.
Covered in Treat context as a resource, and hand work across sessions cleanly
2.The more you put into persistent project instructions, including current figures and fast-moving details, the better every session will be.Why is that wrong?
Persistent instructions should hold stable, non-obvious rules. Frequently changing information is explicitly on the exclude list because it goes stale while still being applied.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://code.claude.com/docs/en/common-workflowsOfficial docs
“Delegate research to subagents to keep your main context clean”
↩︎ Treat context as a resource, and hand work across sessions cleanly“Resume previous conversations so a task can span multiple sittings”
↩︎ Treat context as a resource, and hand work across sessions cleanly - 2.
“This happens even with compaction, which doesn’t always pass perfectly clear instructions to the next agent.”
↩︎ Treat context as a resource, and hand work across sessions cleanly“the next iteration of the coding agent was then asked to work on only one feature at a time.”
↩︎ Treat context as a resource, and hand work across sessions cleanly“These approaches also increased efficiency, as they eliminated the need for an agent to have to guess at what had happened”
↩︎ Treat context as a resource, and hand work across sessions cleanly“However, compaction isn’t sufficient.”
↩︎ Exam trap 1 - 3.https://code.claude.com/docs/en/best-practicesOfficial docs
“In one prompt: ask Claude to run the check and iterate in the same message, as in the table above.”
↩︎ Build the check into the request“has a fresh model try to refute the result, so the agent doing the work isn’t the one grading it.”
↩︎ Build the check into the request“Common gotchas or non-obvious behaviors”
↩︎ Make the fix persistent instead of re-solving it“Long explanations or tutorials”
↩︎ Make the fix persistent instead of re-solving it“Information that changes frequently”
↩︎ Exam trap 2 - 4.https://www.anthropic.com/engineering/building-effective-agentsSecondary source
“Parallelization is effective when the divided subtasks can be parallelized for speed, or when multiple perspectives or attempts are needed for higher confidence results.”
↩︎ Build the check into the request