Prompt and Context Design for Claude Agents That Work (Harnessing Claudes Intelligence)

Two engineers build the same Claude agent with the same model and the same tools. One agent is sharp, fast, and cheap; the other is vague, slow, and expensive. The difference is almost never the model — it is what each engineer decided to put in front of it. Context design is the highest-leverage skill in agent engineering precisely because it is the one variable you fully control on every single turn. This post is about that skill: what belongs in a Claude agent's context, what to ruthlessly leave out, and the reasoning behind each call.

Context is a budget you spend, not a box you fill

The most common mistake is treating the context window as storage. Claude's latest models support up to a 1M-token window, and the instinct is to use it — dump the whole history, every document, every tool. Resist this. Context design is the discipline of assembling, on each turn, the smallest set of information that lets the model take the best next action. Every token you add competes for the model's attention, and irrelevant tokens do not merely waste money — they actively degrade decisions by burying the signal the model needs. The goal is the highest signal-to-noise ratio you can manage, not the fullest window.

This reframes everything downstream. Instead of asking "what could the model possibly want?" you ask "what does this specific step need?" The first question fills the window with maybes; the second keeps it sharp. A lean, relevant context is both cheaper and more accurate, which is the rare case where the frugal choice is also the better one.

The four things that almost always belong

Some content earns its place on nearly every turn. First, the stable instruction layer: the agent's role, its hard constraints, its tool-use policy, and the exact shape of a valid output. Keep this fixed and at the top so it can be cached, which makes repeated calls cheaper and faster. Second, the immediate task — the user's actual request or the current sub-goal — stated plainly. Third, the tool schemas the agent is allowed to use right now, and only those. Fourth, the working set: the unresolved tool results and decisions from earlier turns that the current step actually depends on.

Notice what this list is: durable rules, the present goal, the available actions, and live working memory. Everything else is a candidate for exclusion until proven necessary. If you cannot articulate why a piece of content helps the model take a better next action, it probably does not belong on this turn.

flowchart TD
  A["New turn begins"] --> B["Add cached instruction layer"]
  B --> C["Add current task"]
  C --> D["Add allowed tool schemas only"]
  D --> E{"Relevant docs needed?"}
  E -->|Yes| F["Retrieve just-in-time, top results"]
  E -->|No| G["Skip retrieval"]
  F --> H["Add live working set"]
  G --> H
  H --> I["Send minimal context to Claude"]

What to leave out, and why

Knowing what to exclude is harder than knowing what to include, so here are the usual offenders. Leave out resolved sub-tasks — once an order is looked up and the answer captured, the full back-and-forth that produced it is noise; keep the one-line outcome and drop the trail. Leave out tools the current step cannot use; advertising fifteen tools when three apply just invites the model to pick wrong. Leave out entire documents when a paragraph will do; retrieval should hand the model the relevant passage, not the manual.

Leave out anything secret — keys, tokens, internal credentials — because anything in context can surface in a log, a trace, or an output, and a prompt-injection attack specifically tries to exfiltrate it. And leave out stale facts: if a value might have changed, do not carry an old copy across turns; re-fetch it. The unifying principle is that every excluded token is one fewer distraction and one fewer liability. Pruning is not just cost control; it is accuracy work.

Just-in-time retrieval beats pre-loading

A defining pattern of good context design is pulling information when the step needs it rather than front-loading it. Instead of stuffing a knowledge base into the system prompt, let the agent retrieve the few most relevant passages for the question in front of it. This keeps the baseline context small and ensures what is present is actually about the current task. Skills extend the same idea to instructions: an Agent Skill is a folder of guidance and scripts Claude loads only when the task signals it is relevant, so a refund workflow or a SQL style guide enters context exactly when needed and stays out otherwise.

Just-in-time assembly also ages better. Pre-loaded context goes stale the moment underlying data changes; retrieved-on-demand context reflects the current state of the world. For agents that run against live systems, this freshness is not a nicety — it is the difference between a correct answer and a confidently wrong one.

Managing long-running context without losing the thread

Long sessions break naive context design because history grows without bound. The reliable pattern is structured rolling summarization: when the conversation crosses a threshold, replace older turns with a compact summary that preserves established facts, open questions, and decisions while discarding the play-by-play. Keep the summary structured — short lists of "known facts" and "open items" survive compression far better than prose, which tends to lose the precise details that matter.

For anything that must be exact — an order number, a balance, an appointment time — do not rely on summarized context at all. Hold those values in your application state and inject them as fresh, authoritative facts when a step needs them. The division of labor is clean: the model reasons over context, your code remembers the precise state. Mixing the two — trusting the model to carry an exact identifier across thirty turns — is how subtle, maddening bugs get in.

Test context design like code

Context decisions are testable, so test them. Build an eval set from real tasks and measure how changes to what you include affect both accuracy and token cost. You will often find that removing content improves results — a sign you were drowning the model in noise. Capture a trace of the assembled context for every run so that when an agent misbehaves, you can read exactly what it saw; nine times out of ten the bug is a stale value or an irrelevant document, not a reasoning failure. When you change the context recipe or upgrade to a model like Opus 4.8, replay the evals and confirm you improved the signal rather than just rearranging it.

Frequently asked questions

If the window is huge, why not just include everything?

Because attention is finite even when the window is not. Irrelevant tokens bury the signal the model needs and raise cost on every call. A smaller, sharper context produces better decisions than a full one — the window size is a ceiling, not a target.

What is the difference between context design and retrieval?

Retrieval is one technique within context design. Context design is the whole decision of what the model sees each turn — instructions, task, tools, and working memory; retrieval is the just-in-time mechanism for pulling in the right documents as part of that assembly.

How do I keep exact values correct over a long session?

Store them in your application state, not the conversation. Inject precise identifiers and amounts as fresh authoritative facts when a step needs them, and let summarization handle only the reasoning context. The model reasons; your code remembers.

Where do Agent Skills fit into context design?

Skills implement progressive disclosure. Rather than loading every instruction up front, Claude pulls a skill's content into context only when the task signals it is relevant, keeping the baseline lean while making specialized guidance available on demand.

Context design, applied to every call

CallSphere brings disciplined context design to voice and chat agents — feeding each one only the live facts, tools, and instructions a moment in the conversation requires, so it answers accurately and acts in real time. Hear it work at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.