Claude Code Best Practices: Prompts, Agent Decay, and 6 Features

You will learn how to systematically diagnose prompts that break after a model switch, how to recognize that your Claude Code agent is gradually getting worse, and which six features you are probably leaving unused. This article contextualizes best practices from an Anthropic conference for development teams and tech leads at SMEs, and checks them against the official documentation.

About the source: This article evaluates a video compilation of several sessions from the Anthropic conference "Code with Claude" London (May 19, 2026). Reliably identifiable are Margot van Laar, Applied AI Engineer at Anthropic (prompting talk), and Ivan Nardini, Developer Advocate at Google Cloud (partner talk). All statements were checked against the official documentation (full source list at the end of the article).

Figures from live demos are individual observations, not benchmarks, marked "(Demo)" in the text; unverified practical tips from the speakers are marked "(Speaker heuristic)". Status of this article: July 13, 2026. Current at conference time were Claude Opus 4.7 and Sonnet 4.6. Now available: Opus 4.8 and Claude Fable 5 (access to the Fable 5 promo).

How do I prompt Claude correctly?

Before any prompt fix, first build an eval suite that delivers the diagnosis. A prompt that has been running in production for months and suddenly breaks test cases after a model switch has two possible causes (recommendation from Margot van Laar in the prompting talk).

Either the new model simply behaves differently, which can be corrected through the prompt. Or it is simply less capable for the task, in which case no prompt tuning helps, only a different model or a different architecture.

Your eval suite needs three case groups:

• Control cases: must always pass because they are uncontroversial.
• Edge cases: cases where the model has demonstrably failed before.
• Competence boundary cases: check whether the model recognizes when it should escalate or clearly decline a request, instead of overreaching into competencies it does not have.

Clean up the prompt only after that, instead of immediately fine-tuning the wording. Prompts that have grown over months accumulate clutter: outdated patches for earlier model generations, copied website text, contradictory instructions. Rule of thumb: if you can no longer distinguish between role, guideline, policy, tone, and data while reading it, the model certainly cannot either.

Separate these elements structurally using XML tags: role, guidelines, policy, tone, and payload data each in their own blocks. Add an output contract and, at the API level, stop sequences that secure the response format.

In goal statements, always name both sides of a trade-off, never just one. In the example shown, the prompt of a support bot essentially said: avoid escalating to a human because it costs around 8 US dollars (Demo). Afterward, the bot did not escalate even when it would have been necessary, for example with a genuine billing error.

The fix: name both sides, the cost of escalation and the cost of non-escalation (refunds, loss of trust). The more capable a model becomes, the more consistently it optimizes for the explicitly stated goal. A one-sidedly formulated goal is therefore not interpreted more leniently, but followed more strictly: stating both sides in full becomes more important with stronger models, not less important.

Solve tasks with hard constraints through a generate, evaluate, repair loop instead of a single large model. In a live demo, a simple prompt failed at creating a weekly schedule with hard constraints (staff availability, minimum staffing) (Demo). A large model with extended thinking did solve the task completely, but needed around three times as many tokens and correspondingly more latency to do so (Demo).

The cheapest and most reliable approach was a loop of three separate, simple prompts:

1. Generator produces a draft.
2. Evaluator checks it rule by rule, with evidence for each violation.
3. Repair fixes only the reported problems in a targeted way.

Result: all test cases solved, at lower cost than the large model alone. A practical side effect: soft, case-dependent additional rules, such as "person A should preferably not be scheduled with person B", simply move into the evaluator prompt instead of requiring a hard-coded check function to be adjusted.

Why does my Claude agent get worse over time?

How to recognize that your agent has become bloated:

• The system prompt has grown over months, and nobody dares to cut anything anymore.
• Several of your tools are actually disguised sub-agents with their own logic.
• The hit rate in your evals is quietly declining without any single change seeming responsible.
• The model takes on reasoning work for which it would actually need a tool.

The first step: have Claude triage its own eval failures. In a conference workshop on agent decomposition, an inventory management agent served as a case study (Demo): grown over months to around 400 lines of system prompt and twelve tools, three of them disguised sub-agents. The eval hit rate had dropped from 83 to 62 percent.

The workshop participants did not make the diagnosis themselves: they had Claude Code triage its own eval results and extract failure themes. Result: the model was taking on a lot of reasoning work for which it would actually have needed tools, the output structure of sub-agents was not cleanly enforced, and the overly long system prompt led to contradictions.

Rebuild the agent to be radically leaner once the diagnosis is in place. The rebuild reduced it to a 15-line prompt, three tools (Bash, Read, Write), skills for the domain logic, and exactly one remaining sub-agent for sales forecasting.

A task that previously consumed over 200,000 tokens because a complete CSV file was loaded into the context became drastically cheaper after switching to file system access and code execution (Demo). Claude writes and executes Python itself in the process, instead of processing raw data "in its head". The pattern behind this: agents grow additively, nobody removes anything, and eventually the prompt carries more clutter than substance.

The lever against this: Agent Skills. Anthropic officially defines them as "packages" of instructions, metadata, and resources. The central design principle is progressive disclosure: skills load in three stages, first only the frontmatter (name plus short description), then the body if needed, then linked additional files.

The context stays lean as long as a skill is not needed, and skills can be combined (official documentation). Anyone who wants to have an agent built for their own company will find a starting point with us at AI agent development. A lean prompt plus skills instead of a monolithic system prompt is now a central building block of professional agent architecture.

Use this order for tool selection (speaker heuristic): first built-in primitives (Bash, file system, web search), then custom tools if needed, and only MCP servers once several clients or agents need to share the same tool set. The underlying idea is backed by documentation: Anthropic's engineering blog recommends executing MCP servers through code ("Code execution with MCP"), which brings token and latency advantages over many MCP tool definitions placed directly in the context.

Use sub-agents deliberately, not by default. They pay off mainly with genuine parallelization: many Claude instances working on a problem at the same time, for example codebase exploration. Or when you need an unburdened, "fresh" context: a reviewer that is not the same agent as the author. Everything else is usually easier to solve directly in the main agent, supplemented by a matching skill.

Which Claude Code features do most teams overlook?

According to the speakers, very few teams use six smaller but practically effective features. A quick check of what is missing from your workflow:

1. Esc+Esc / /rewind: pressing Escape twice on an empty input line opens a rewind menu that lets you reset code and/or conversation to an earlier point. If an agent has gone off track, this is often faster than manual cleanup (documentation).
2. CLAUDE.md hierarchy: at startup, Claude Code fully loads the CLAUDE.md from the current working directory, plus all CLAUDE.md files in parent directories and the global ~/.claude/CLAUDE.md. CLAUDE.md files in subfolders, by contrast, are not loaded automatically at startup but only when needed. The @ path syntax can additionally import further files. Recommended content: build commands, code style, recurring workflows, things that would otherwise have to be explained again in every new chat (documentation).
3. /model and /config: model and configuration can be switched at any time directly within the session (documentation), without needing a new session for subtasks of different complexity.
4. Interleaved thinking, no longer "think hard": since the Claude 4 generation, Claude keeps thinking between tool calls too, not just once at the start of a response (Anthropic calls this interleaved thinking). The conference video still named "think hard" as the trigger for this, which is outdated. According to the current documentation, "ultrathink" is the only trigger word Claude Code recognizes for extended thinking; other phrasings such as "think hard" are now treated as ordinary running text (extended thinking documentation, model config documentation).
5. Effort slider and auto mode: five official levels, low, medium, high, xhigh, max, switchable via /effort, plus a separate dedicated /fast mode. Shift+Tab cycles through the permission modes, including auto mode. The documentation recommends auto mode conditionally: when you trust the direction of the task, not across the board (model config documentation, interactive mode documentation):

Mode / level	Command	Short description
low	/effort low	Lowest reasoning effort, for simple and unambiguous tasks
medium	/effort medium	Balanced ratio of speed and thoroughness
high	/effort high	More reasoning depth for more complex tasks
xhigh	/effort xhigh	Very high reasoning effort for demanding multi-step tasks
max	/effort max	Maximum reasoning effort, with correspondingly higher latency and cost
Fast mode	/fast	Separate mode, distinct from the effort levels, for especially fast responses
Auto mode	Shift+Tab (permission modes)	Recommended by the documentation "when you trust the direction of the task"

6. Parallel sessions via Git worktrees: not a makeshift solution but an officially documented best practice: multiple sessions work simultaneously on different branches without getting in each other's way (best practices documentation). For teams without parallel experience, this is often the simplest step toward higher throughput, without touching the prompt or agent architecture.

What are Routines, Memory Stores, and Dreams?

Check these five platform building blocks if you want to run agents persistently and with memory, not just interactively in a single session. They form the second major topic block of the conference. Important up front: all the building blocks mentioned here officially carry beta or research preview status, not generally available, fully mature products, but features still under development.

The foundation is formed by Claude Managed Agents (Beta): a prebuilt agent harness on managed infrastructure, either Anthropic's own cloud sandbox or self-hosted. Advantage over a self-built agent loop: no sandboxing of your own, no scaling or session management of your own to build, you focus on tools, skills, and sub-agents.

Multi-agent sessions build on top of this, still called "callable agents" in the video, officially multi-agent sessions. A coordinator delegates to up to 20 agents, each as its own session thread with built-in events and observability. This addresses a known problem of self-built multi-agent setups: communication between orchestrator and sub-agents is easily lost, and logging across multiple agents is cumbersome.

For memory beyond individual sessions there are Memory stores (Beta): persistent, versioned storage under /mnt/memory/, either read_write or read_only at the file system level. Every change creates a new, immutable version as an audit trail, manageable via API, CLI, or console. Limits: eight memory stores per session, 2,000 memories per store.

Because such stores become cluttered over time, there is Dreams (research preview, access on request). An asynchronous job generates a new, separate memory store from a memory store plus 1 to 100 session transcripts: verified, deduplicated, reorganized. The input store remains unchanged in the process.

For proactive, time- or event-driven runs there are Routines (research preview): complete Claude Code sessions on Anthropic's cloud infrastructure, triggered by a schedule (at least an hourly interval), an API trigger (HTTP POST with bearer token), or GitHub events such as pull requests and releases, including filters. Set up via /schedule, available for Pro, Max, Team, and Enterprise accounts.

Three team patterns from the talk:

• A generator-critic pair: one routine opens pull requests, a second automatically reviews them.
• A deploy verifier via a CD webhook.
• A weekly automated backlog prioritization.

To put these five building blocks in context, here is a compact overview:

Building block	Official name	Status	Purpose
Managed agent harness	Claude Managed Agents	Beta	Prebuilt, hosted infrastructure for agents (cloud sandbox or self-hosted)
Delegation to multiple agents	Multi-agent sessions	Part of Claude Managed Agents (Beta)	Coordinator delegates to up to 20 agents, each with its own session thread and observability
Persistent storage	Memory stores	Beta	Versioned storage under /mnt/memory/, read_write or read_only, with audit trail
Memory consolidation	Dreams	Research preview (access on request)	Asynchronous cleanup/reorganization of a memory store into a new copy
Proactive sessions	Routines	Research preview	Schedule-, API-, or GitHub-triggered Claude Code sessions in the cloud

How do I verify what Claude has built?

Build your verification so that not only humans but also agents can check it reliably. An internal Anthropic team prepares frontend changes accordingly: through Storybook fixtures, DOM data attributes that machine-readably mirror a component's state to the outside, and Microsoft's official Playwright MCP.

Central idea: three equivalent verification paths to the same result.

• A human manually clicks through the application.
• An agent drives the same flow in the browser.
• The same flow runs headless in CI.

Every run is recorded and filed as evidence.

Build specifications as a clickable HTML artifact, not as a long Markdown document. This is more information-dense and easier to judge than running text, which hardly anyone reads in full anyway.

Let Claude actively interview you through the AskUserQuestion mechanism, where Claude asks structured follow-up questions with selectable options instead of jumping straight in, rather than having to spell everything out in advance yourself. For design decisions, also have several variants generated in parallel and compared visually.

This has become more practical because, according to Anthropic, Opus 4.7 processes significantly higher image resolution than its predecessor: up to 2,576 pixels edge length (around 3.75 megapixels, three times as much as Opus 4.6). On the visual acuity benchmark, the model reaches 98.5 percent instead of 54.5 percent for Opus 4.6 (Anthropic).

Anyone who wants to build such verification and interview workflows within their own company will find a practical introduction to this way of working with Claude in our AI certificate course.

Does Claude Code also run on Google Cloud?

Yes, and for companies with existing Google Cloud infrastructure it is more than a footnote. In the partner talk, Ivan Nardini, Developer Advocate at Google Cloud, showed how Claude Code runs on Google Cloud's Agent Platform (formerly Vertex AI). Three things change during setup:

• Auth: application default credentials instead of an API key, activated via the environment variable CLAUDE_CODE_USE_VERTEX=1, no separate key to rotate.
• Billing: you either pay per token consumption, or you book provisioned throughput with reserved capacity for production applications.
• Governance: your requests run through your own GCP project with its IAM permissions, quotas, and billing; Google documents data governance and zero data retention separately (Claude Code documentation, Google Cloud documentation).

On top of that come global and regional endpoints, depending on availability and data residency requirements. For database access, the talk named MCP Toolbox for Databases, open source from Google (googleapis/mcp-toolbox), which connects agents to BigQuery and Looker.

For SMEs with existing GCP infrastructure, this specifically means: you embed a Claude Code agent into your existing governance and cost structure without additional key management, instead of building a parallel billing world.

For decision-makers: what does this mean for development teams?

The bottleneck in software development is shifting, away from writing code and toward review, verification, and coordination (thesis from the closing talk).

If coding is no longer the limiting factor, the bottlenecks shift to where there was previously capacity: who reviews generated code? Who coordinates between team members and agents working in parallel? How is knowledge passed on when someone is already working productively with agents in their first month?

Internally at Anthropic, these points are shifting (explicitly marked as internal practice, not as a universally valid recommendation):

• Code review no longer happens across the board, but at human discretion, depending on the risk of the change.
• Planning happens just in time instead of as a long roadmap that becomes outdated after months anyway.
• Fundamental technical debates increasingly play out across several competing, actually generated pull requests instead of at the whiteboard: the decision is made on the finished code, including its impact on all callers, not on the most persuasive meeting argument.
• A weekly spreadsheet status update has given way to a dedicated standup skill that compiles the status automatically.

Do without pure code volume as a success metric: "X percent of the code generated by AI" says little about quality or usefulness. Instead, measure onboarding time, PR cycle time to merge, and the share of AI-assisted commits as a context signal.

These metrics are not an end in themselves, but show whether review, CI, and deployment keep pace with throughput. So first check whether your review and verification process keeps up with what Claude Code delivers today, before investing in more agent tooling.

Frequently asked questions

How do I convert old prompts to ultrathink?

Systematically search your prompt libraries and templates for the phrase "think hard" and replace it with "ultrathink". Reason: according to the current Claude Code documentation, only "ultrathink" is a recognized trigger word for extended thinking, "think hard" is now treated as ordinary running text and no longer triggers additional reasoning. The conference video still named "think hard" as the trigger; that was correct at the time of recording, but is now outdated.

Is this worthwhile for a small team, or only for large development organizations?

The basics, eval-driven prompt debugging, CLAUDE.md hygiene, rewind, effort levels, lean skills instead of bloated prompts, work regardless of team size and cost nothing extra. The agent platform (Managed Agents, Routines, Memory Stores, Multi-agent Sessions) is tied to Pro, Max, Team, or Enterprise accounts and carries beta or research preview status. For a five-person team, it is usually worth starting with the basics first, and adding the platform building blocks later when there is a concrete need.

When do I need an MCP server instead of a custom tool?

According to the speaker heuristic, use MCP as soon as several clients or several agents need to use the same standardized tool set, for example when the same ticketing system tool is used by the support agent and by the developers' Claude Code setup. For a single agent project, built-in primitives such as Bash, file system, and web search, plus simple custom tools if needed, are usually enough.

Do I need my own server infrastructure for Routines?

No. Routines run as complete Claude Code sessions on Anthropic's own cloud infrastructure and start via a schedule, an API call, or GitHub events. The feature currently carries research preview status and is available for Pro, Max, Team, and Enterprise accounts.

What should I start with tomorrow?

First build a small eval suite with control, edge, and competence boundary cases for your most important prompt, without evals, every prompt change stays guesswork. At the same time, check your CLAUDE.md for currency, and have a bloated agent triaged by Claude itself based on the eval failures.

Sources

The starting point of this article was a video by @ajitcodes on X (https://x.com/ajitcodes/status/2076501882319810994) with session recordings from the Code with Claude conference. All statements were checked and supplemented against the following primary sources:

• Code with Claude London, official conference page
• Anthropic: Claude Opus 4.7
• Anthropic: Claude Sonnet 4.6
• Claude Code documentation: Interactive Mode
• Claude Code documentation: Memory (CLAUDE.md)
• Claude Code documentation: Commands
• Claude documentation: Extended Thinking
• Claude Code documentation: Model Config
• Claude Code documentation: Best Practices
• Claude documentation: Agent Skills Overview
• Anthropic Engineering: Equipping Agents for the Real World with Agent Skills
• Anthropic Engineering: Code Execution with MCP
• Claude documentation: Managed Agents Overview
• Claude documentation: Multi-agent Sessions
• Claude documentation: Memory Stores
• Claude documentation: Dreams
• Claude Code documentation: Routines
• GitHub: Microsoft Playwright MCP
• Claude Code documentation: Google Vertex AI
• Google Cloud documentation: Partner Models
• GitHub: Google MCP Toolbox for Databases

Beta and research preview features can change at any time; all information according to the provider's documentation, without guarantee.