Claude Code workflows & session control

It isn't the model degrading — it's context drift. After an hour of back-and-forth the agent answers a simple question based on a tangent from forty messages ago. It feels like the assistant "forgot" something, but it's the opposite: it remembered too much, including things you already superseded.

Three drift modes look fine inside one turn and compound across forty:

• Style drift. You said "use snake_case." Twenty messages later it's producing camelCase because it picked up your last paste, which happened to be JavaScript.
• Goal drift. You started debugging an auth bug, fixed it, then asked a database question — and the reply still carries auth-related caveats.
• Anchoring drift. You shared a file at the start; it keeps generating against that file after you've moved on, suggesting methods that don't exist on your current one.

Past roughly 70% window saturation, attention degrades non-linearly. The reset triggers are worth memorizing: the agent suggests a change it already made, contradicts a decision you locked in, confuses two files, starts producing smaller and more conservative diffs for no reason, or you find yourself writing longer and longer prompts to fight it.

The fix is not a bigger window — a 200K window with 180K tokens of stale context is more drifty than a 50K window with 5K current tokens. The right axis is curation, not capacity. Three resets, cheapest to nuclear: inline re-anchor ("forget auth.ts, db.ts is the ground truth now"), hard reset (new chat with the same project context but no message history), and session retire (close it, write a two-line note about what you decided, start fresh tomorrow). The note is the part people skip — without it you re-litigate the same decisions the next day.

No. The single most effective change is to split the work across two distinct sessions.

The planner is broad and shallow: it reads the relevant code, talks through architecture, weighs tradeoffs, and writes a plan — on a cheap or fast model. Its job is not to ship code; its job is to produce a document that can be handed off. The implementer is narrow and deep: it receives the plan, reads only the files the plan names, and writes the diff. Its context is never polluted with rejected ideas or architectural debate.

A good plan doc is boring on purpose:

## Goal
Add rate limiting to /api/upload.
## Files to touch
- src/middleware/rate-limit.ts (new)
- src/server.ts (wire middleware)
## Decisions already made
- Token bucket, in-memory, 10 req/min per IP, 429 + Retry-After
## Out of scope
- Distributed / per-user limits
## Open questions
- None. Implementer should not deviate.

Then chunk by what fits, not by what completes the feature. Anything that fits in 30–50% of the window produces reliable output; anything needing 70%+ will not. If a unit of work needs more than half the window to do cleanly, split it — schema first, then API, then UI; migration first, then the code that uses it; tests first, then implementation. Each chunk should be handable to a fresh session with a one-paragraph brief; if it isn't, it's too big. This is not the same as making tasks artificially small: a 200-line diff across three files is fine, a 50-line diff across twelve files is not.

It also helps to budget the prompt explicitly — tell the agent what must stay in context, not to re-read files it already read, not to dump directories, and to stop and ask if it wants to open more than five files. That gives it permission to refuse the expensive, low-value reads it would otherwise default to.

A loop can be genuinely useful: run the test, read the failure, patch the code, run the test again. That's a normal developer rhythm and agents can accelerate it. The problem is a loop with no stop condition. It stops feeling like automation and starts feeling like a slot machine that charges by the spin.

Make the loop explicit before it starts, not after the bill arrives. A controlled loop can answer: what command is being repeated? What changed between attempts? Which failure is still unresolved? How many times has it retried? Is the test output actually improving, or is the agent circling the same error with slightly different patches? Give it a budget and a stop condition up front.

That visibility matters for both ends of the experience spectrum. An experienced engineer wants to know when to intervene. A newer developer wants to avoid accepting a patch just because the assistant sounds certain. In both cases the loop should produce evidence, not just activity — the most dangerous output is not obviously-wrong code, it's plausible code with no proof behind it. A model will happily claim a bug is fixed because one narrow case passed. If the agent can't tell you which failure is still unresolved from the session record, it hasn't converged — it's spinning.

Model choice used to be purely a quality question. Now it's a cost and workflow question too. Route everything through the strongest model and cost becomes unpredictable while feedback slows down. Route everything through the cheapest and quality failures move downstream into debugging. The practical answer is not a universal model choice — it's matching the job to the tool.

A rough routing policy that holds up in practice:

• Cheap-first for low-risk exploration — summarizing logs, drafting a test, inspecting a small file.
• Stronger model for high-risk reasoning — architecture, an unfamiliar bug, careful review of a risky change.
• Local search before long-context prompting, so you're not paying to re-read the repo every turn.
• Explicit review before merging generated code.

Token budgets become engineering inputs the moment you decide which task deserves expensive reasoning and where the proof of completion has to appear. The mistake is treating every task as if it deserves the same model and the same amount of context — that's what makes usage feel unpredictable and turns the most expensive tool into the default. And the best routing decision is usually made after you can see the current state — the diff, the test output, the terminal history in one place — not guessed before the task starts. One team was ready to leave Anthropic because cost no longer matched their confidence, but provider loyalty was never the fix; a layer that lets you change engines per task is.

Sub-agents make coding feel less like a chat window and more like an operating system — and that changes the failure mode. When one assistant delegates to another, calls MCP tools, burns quota, edits files, and returns a clean summary, you can no longer judge the work from the final paragraph.

When several agents touch the same repository, context fragmentation becomes real: one agent solves a problem another already handled, a second edits a file without knowing it's been claimed, a third follows the plan superficially and skips the helper tests that would have proven the change. Coordination needs four things that become necessary the moment agent work goes parallel: shared memory, file ownership, explicit task boundaries, and a record of verification.

The cleanest time to define a boundary is before the run begins. A reviewer should be able to see the planned roles, the file scope, the tool access, and the stopping conditions. If an agent is only supposed to inspect logs, it should not silently edit source. And because MCP expands the surface area of every run, packaging should be visible rather than folklore: which servers are enabled, which agent can call them, what credentials or environment are assumed, and what log proves the call happened. Without that, one developer knows the right local setup, another copies half of it, and a third agent fails because a schema changed. If the only durable artifact of a nested run is a success summary, you're reconstructing responsibility from side effects.

Writing a rule once is easy. The hard part is proving the rule shaped the work every time an agent ran. A repo with AGENTS.md, CLAUDE.md, MCP configuration, and team conventions is just a pile of instruction files unless you have a visible way to confirm which rules each agent actually received. Otherwise you have documentation without enforcement.

This is a real gating concern, not a nicety. One developer wanted chat-level Skills and rule adherence in Claude Code before they'd trust parallel agents on something as consequential as legal drafting — because a coding agent can sound completely confident while skipping tests, ignoring style rules, duplicating another agent's work, or carrying hidden context the user never meant to include. The answer to that is not a stronger model and not a sharper one-off prompt; it's a workflow that exposes state.

Concretely, you want to be able to see which conventions were loaded into a given run, which Skills were available to it, and whether the agent that edited a file inherited the same rules as the agent that planned the change. Standardize the setup, then make it inspectable instead of tribal knowledge. That's the difference between a rule you wrote and a rule that actually governed the run.

The most dangerous AI coding output is not obviously-wrong code. It's plausible code with no evidence. A model can produce a clean explanation for a patch that was never run, claim a bug is fixed because one narrow case passes, or review its own work and miss the exact assumption that caused the mistake. A confident answer is not evidence, and a working screen is not evidence by itself.

Evidence is the reviewable trail that connects the task to the patch: scope, the files that changed, the commands that ran, the test output, what failed before it passed, and what still needs human judgment. The key is to ask for those receipts while the session is still active, not to reconstruct them at review time. Which files changed? What commands ran? What did the tests actually print? Was the failing case reproduced before the fix? A claim dies at the end of the session; evidence compounds, because it's reusable in PR review, incident debugging, onboarding, and the next agent's run.

This is also where a human belongs in the loop — but human-in-the-loop does not mean stopping every action. It means placing review where the cost of being wrong is high: destructive commands, secret handling, production deploys, and unclear tests. Let an approval gate slow down those, not routine edits. Sub-agent runs raise the stakes further: if the only durable artifact is a success summary, the reviewer is reduced to reconstructing the whole run from its side effects.

This is a real failure, not a hypothetical: a developer lost two weeks of Cursor agent chat and file changes after editing an old message, with no Git history or clear local checkpoint to fall back on. The lesson isn't "be more careful" — it's that AI-assisted work needs durable state that lives outside the chat window. Conversation is volatile; files are durable.

Anything important the agent figures out should be written to disk, not held in conversation the next session will never see. Decisions ("we chose X over Y because Z") belong in a DECISIONS.md. Intermediate state — a complex mapping, a non-obvious pattern the agent derived — belongs in a scratchpad you can throw away when the feature ships. Don't lean on /compact for this either: compaction is a lossy summary of a lossy summary and tends to discard exactly the architectural decisions you needed to keep.

When you end a productive session, write a structured handoff first: current state (what's done, in progress, untouched), the decisions made this session and why, the files changed, the next three concrete steps, open questions, and anything the next session should not redo. You read it, correct it, and save it. The next session opens cold, reads the handoff as its first action, and primes from a clean 500-token summary instead of a 50,000-token chat replay — it inherits the old session's conclusions, not its confusion. And the cheapest insurance is the oldest one: commit to Git at checkpoints, so a bad edit is a revert instead of a loss.

Two beginner-but-high-intent questions keep surfacing together.

First, setup clarity. A new MacBook Pro owner who wants to build an iOS app doesn't know whether Claude Code runs locally or in the cloud, how it performs on 16GB of RAM, or what else to install. The short version: the Claude Code CLI runs on your own machine and talks to a hosted model over the API, so the heavy computation happens remotely and 16GB is plenty for the tool itself — the real constraints are your API usage limits and whatever else you're running alongside it (simulators, builds, a browser). The tool is light; the model is elsewhere.

Second, provider trust. A team was leaving Anthropic because their confidence in high-stakes output no longer matched the cost. That pressure shows up from several directions at once — speed changes, billing changes, quota limits, setup confusion. None of it is solved by loyalty to a single provider. The durable move is a layer above the provider that remembers your project rules and records what happened, so you can change engines without changing your whole operating model. Framed that way, "which provider" stops being an identity and becomes a routing decision. A new developer shouldn't have to reverse-engineer the last twenty prompts to understand why an agent made a change, and a lead shouldn't have to ask which model was used or whether the tests ran.

The shift showing up in r/ClaudeAI threads is exactly this: experienced users have stopped asking "what prompt gets better code" and started asking for a repeatable engineering system around the agent. The pieces that keep coming up form a pipeline, not a prompt list:

• Codebase understanding first. Before any feature work, have the agent build (and persist) a map of the repo — architecture, conventions, where the bodies are buried — instead of re-discovering it every session.
• Plan before implement. Separate the planning conversation from the implementing one, and review the plan yourself. Most runaway diffs trace back to skipping this.
• Token discipline as a budget, not a vibe. Decide per task what model tier it deserves and how many tokens it may burn. One thread had a user about to buy a second Claude Pro subscription because limits kept interrupting work — that's a routing-and-budget problem, not a capacity problem (see model routing & costs).
• Tests and review as gates. Generated code doesn't merge until tests ran and a review pass (human or second agent) happened — "it runs" and "it's solid" are different claims.
• Decision docs / memory files. Write down what was decided and why, in files the agent reads next session. One builder's Claude Code Blender pipeline grew structured memory files so load-bearing they had to be extracted from the game code into their own layer — that's the point where a workflow has become real infrastructure worth maintaining.
• Multi-agent flows where they pay. Split planner/executor roles once the single-session ceiling hurts (see multi-agent control).

Adopt these one at a time — each is useful alone, and together they're the "engineering control system" people keep asking for.