Previously in the series

• The Bare Minimum Setup
• CLAUDE.md Done Right
• Models, Tiers, and Effort
• The Context Window Tax
• Hooks That Guard Your Code
• MCP Servers Worth Adding
• Skills That Actually Fire
• Subagents Done Right
• Agent Teams in Practice

Introduction

Nine articles in, we've covered every major piece of Claude Code's configuration surface — models, context management, hooks, MCP servers, skills, subagents, and agent teams. The last two articles in particular moved from isolated delegation (subagents that do work and return a summary) to direct collaboration (agent teams where multiple Claude instances communicate with each other). Treating them in isolation is the right way to learn them — but it's not how they behave once you're running a real session.

Real sessions span all of it. You're scoping a feature, delegating research to a subagent, enforcing lint through a hook, pulling from a GitHub MCP server, and keeping context lean enough that the session is still useful three hours in. The question isn't whether you understand each piece — it's whether they hold together as a workflow that you can run repeatably on new work.

Rather than introducing anything new, this article shows how the pieces interact under real conditions — where the seams are, what breaks first, and what a deliberately assembled workflow actually looks like.

The stack, in one view.

Before getting into specifics, it helps to see all the layers together:

Every layer affects every other layer. A misconfigured CLAUDE.md buries important rules under noise. An MCP server with 50 exposed tools inflates every tool call budget. A subagent that returns verbose output lands the cost right back in your main session. Agent teams add a further wrinkle: when instances share intermediate state, the coordination overhead itself becomes a context cost — something article 9 covered in detail. The systems interact, and the interactions matter more than any individual setting.

Starting a session right.

The setup you do before the first prompt determines how far the session can go without degrading.

Use /init once per project, then refine manually. The /init command generates a starter CLAUDE.md from your codebase structure — build system, test framework, common patterns. That starting point is usually 60–70% right. The remaining 30% is the stuff the tool can't infer: deployment conventions, what NOT to do, which directories are off-limits, which tests are slow enough to skip in early iteration. Write those by hand.

Load context selectively. Don't start a session with /load everything. Claude reads what it needs if your CLAUDE.md tells it where to look. The session that starts with five large file imports starts with a context window that's already 20% spent before you've typed a question.

Set model and effort explicitly for non-trivial work. If you're starting a feature implementation session, say so. If you want extended reasoning on an architecture decision, ask for it with effort deliberately set. The default is reasonable; the deliberate choice is better.

Scope before you explore.

The single most reliable way to extend a session's useful life is to scope work before sending Claude to explore it.

Unscoped exploration is the primary failure mode in longer sessions. "Investigate why the authentication is slow," sends Claude through hundreds of files — middleware, database queries, caching layers, logs. By the time it surfaces an answer, the context window has absorbed the journey, not just the destination. You compact, lose the reasoning trail, and start partially blind.

The alternative: specify what you want explored, in what order, with a maximum scope.

Check the database query in auth/session.ts. If the query looks fine, check the Redis client initialization in lib/cache.ts. Stop there and report back.

That's not micromanagement — it's context conservation. Claude can always ask for a wider scope if the answer isn't there. Expanding the scope on demand costs far less than letting exploration expand it by default.

For genuinely broad investigations, delegate to a subagent with an explicit output format:

Use the codebase-researcher subagent to identify all database calls in the auth module.
Return: file path, function name, query type. Maximum 20 items.

The subagent does the traversal. You get the summary. The traversal cost stays isolated. Article 8 covered subagent configuration in full, including why verbose output negates the isolation — the short version is that whatever the subagent returns lands directly in your main context, so output format isn't optional.

CLAUDE.md as the session's backbone.

By the time you're running complex multi-step workflows, your CLAUDE.md has to carry the context that would otherwise have to be re-established every session. Not everything — just what Claude can't infer from the code.

The practical content that belongs there:

• Constraints with teeth: things Claude consistently gets wrong without being told. Not "write clean code" — that's noise. "Never commit directly to main" is a real constraint that affects real behavior.
• Architecture decisions that aren't obvious from file structure: why something is split across modules the way it is, what the intended extension points are.
• What to avoid: the legacy file that keeps getting modified, the deprecated API path, the directory that's being migrated, and shouldn't receive new logic.
• Verification expectations: what "done" means on this project. If tests pass, does that mean the feature is correct? Or are there integration tests, manual steps, or a staging check?

What doesn't belong: style preferences, Claude already follows, explanations of how the language works, and general good-practice reminders. Those cost context and return nothing.

One useful diagnostic: if you've typed the same correction to Claude more than twice in the same project, it belongs in CLAUDE.md. The second article in this series covers the file hierarchy and import mechanisms in detail — the point here is how CLAUDE.md functions in the context of a full session, not how to write it from scratch.

Hooks as the safety layer.

The distinction between hooks and CLAUDE.md instructions is worth restating clearly: CLAUDE.md is advisory, hooks are deterministic. Article 5 covered hook configuration in full — the point here is where hooks fit in the broader session flow. If something must happen every time — lint, formatting, test execution after edits to specific files, a block on writes to a protected directory — it belongs in a hook, not in a CLAUDE.md instruction.

Instructions can be missed. Context can be compact. The model can reason its way around a rule it thinks shouldn't apply in this particular case. A hook runs regardless of any of that.

The three hook events that cover most production use cases:

• PreToolUse: block or warn before a tool executes. The right place for "never write to migrations/ without a confirmation" or "run a dry-run before any destructive bash command."
• PostToolUse: run after a specific tool completes. Linting after file writes, test execution after edits to test files.
• Stop: run when Claude finishes a turn. Build checks, compilation verification, and log writes.

One hook pitfall worth flagging: formatting hooks that run on every file write can accumulate significant token cost over a long session — some users report 160K tokens consumed in three automated formatting passes. If your formatter is slow or your session involves many small edits, run it between sessions rather than after every write.

MCP Servers: The fewer, the better.

Every MCP server you add loads its tools into Claude's context on every turn. Twenty tools from GitHub, thirty from a Sentry integration, another fifteen from a database connector — that's 65+ tools consuming token budget before you've typed anything.

The pattern that works: add MCP servers scoped to what the session actually needs, not everything you might need. A feature implementation session probably needs GitHub and your database. It doesn't need Sentry, the analytics platform, and the Slack integration simultaneously.

For project-specific servers, scope them in .mcp.json at the project root rather than globally. Servers you need everywhere go in ~/.claude/mcp.json. The separation keeps your global configuration lean and prevents project-specific tools from polluting unrelated sessions.

The other side: if you're running Claude in CI or automated pipelines, use --mcp-config with --strict-mcp-config to pin the servers explicitly. You want deterministic behavior in automation, not whatever MCP configuration drifted into the user settings.

Context Management Mid-Session

A few signals that it's time to intervene before the session degrades:

• Claude starts qualifying answers with uncertainty about details that it was handling confidently earlier.
• Responses reference earlier decisions incorrectly or with inconsistencies.
• Token usage indicators are climbing into compaction territory.

The interventions, in order of cost:

1. /clear between unrelated tasks. Don't carry the context from a debugging session into a feature implementation. The old context is more likely to interfere than help.
2. --continue when resuming rather than starting fresh. It re-establishes the prior session without reconstructing context from scratch.
3. Manual compaction prompts: "Summarize what we've established so far about the auth module before we continue." This forces a clean reference point into the active context.
4. Session restart with a tight spec: if the session has genuinely degraded, save the decisions you've made, close the session, and restart with a spec that encodes those decisions. A 500-token spec is more useful than a 50K-token degraded context.

Context editing — Claude Code's 2026 feature that automatically clears stale tool call outputs while preserving conversation flow — handles a lot of the routine accumulation without intervention. It doesn't eliminate the need for /clear between genuinely different work, but it does reduce the rate at which a single task bloats context.

The common failure patterns.

After running this stack seriously for a while, the same failure modes appear across teams and codebases.

Over-specified CLAUDE.md: too long, too many rules, important constraints buried under noise. Claude starts ignoring the file effectively, not deliberately — important instructions just don't surface. Fix: ruthlessly prune. If Claude does something correctly without the instruction, delete it. Move detailed instructions into skills or separate referenced files.

Unscoped exploration bleeding into main context: A research task that should have gone to a subagent runs inline instead, consuming the context window that was supposed to carry the implementation. Fix: Any task you'd describe as "investigate," "explore," or "find all" belongs in a subagent by default.

Verbose subagent output negating the isolation: The subagent does isolated work but returns a 6,000-token report, which lands directly in the main session. Fix: Output format is part of the subagent definition. Specify maximum items, required fields, and whether code snippets are permitted in the response.

Trust-then-verify gap: Claude produces a plausible-looking implementation that doesn't handle edge cases, and you ship it because it looked right. Fix: Verification is your responsibility, not Claude's. Tests, scripts, staging checks — define them as part of what "done" means, in CLAUDE.md if they're always true for the project.

MCP tool count inflation: Too many connected servers, too many exposed tools, context budget shrinking before the session starts. Fix: Scope servers per-project in .mcp.json, audit what you actually use, and drop what you added experimentally and forgot.

A Worked Example

Here's what a feature implementation session looks like with this stack assembled deliberately.

Project setup (done once):

• CLAUDE.md: architecture overview, constraints, what "done" means
• .claude/agents/: code-reviewer, db-researcher, dependency-checker
• .claude/settings.json hooks: PostToolUse lint on *.ts writes, PreToolUse block on migrations/
• .mcp.json: GitHub and PostgreSQL MCP servers scoped to this project

Session start:

I'm implementing the user notification preferences feature.
Spec is in docs/specs/notifications.md.
Start with a plan, don't write code yet.

Research phase: Delegate to db-researcher subagent for the schema impact. It returns a structured summary — affected tables, proposed changes, migration notes. The main context sees 400 tokens, not the 8,000-token schema traversal.

Implementation phase: Explicitly set effort for the database migration logic. Write the schema change, the hook blocks the write to migrations/ until confirmed, PostToolUse lint runs on the TypeScript service files.

Review phase: Invoke the code-reviewer subagent with a bounded prompt — files changed, max 10 findings. Review lands as a structured list.

Verification: Run the test suite. Check that the spec's acceptance criteria are met explicitly, not just that the tests pass.

Close: /clear before moving to the next task.

That's not a complex workflow. It's a deliberate one.

Summary

Claude Code is a framework for orchestrating AI work, not a chat interface with file access. The features covered in this series — CLAUDE.md, model tiers, context management, hooks, MCP servers, skills, subagents, agent teams — aren't independent tools you adopt or skip based on preference. They're a layered system, and the leverage comes from using them together with intention.

The highest-impact practices in that system:

• Write CLAUDE.md for what Claude can't infer, not for what it already does
• Scope work before exploring it
• Use hooks for things that must happen, instructions for things that should
• Scope MCP servers to what the session actually needs
• Route verbose or exploratory work to subagents by default
• Define verification as part of the workflow, not as an afterthought

After nine articles and however many hours you've spent reading and experimenting — the point is that these tools compound. A well-written CLAUDE.md makes subagent prompts shorter because the project context is already there. Good hooks mean you're not second-guessing whether lint ran. Scoped exploration means the context is still clean when you reach implementation.

Get the stack right once for a project, and every session in that project starts from a better position than the one before it.