Prompt and Context Design for Claude Agents That Last

The hardest skill in building agents on Claude is not prompting — it is deciding what the model should and should not see on any given turn. Teams obsess over the perfect system prompt and then quietly poison it by shoveling in every document, every past message, and every tool definition they own. The model's attention is a finite resource, and context engineering is the discipline of spending it well. This post is about that discipline: the principle of least context, what earns a place in the window, what to evict, and how to keep an agent sharp over long-running tasks.

Context engineering, defined

Context engineering is the practice of deciding, on every model turn, the minimal set of information that lets the model make the right next decision — and deliberately excluding everything else. It is the agentic-era successor to prompt engineering: prompting is about phrasing a request well, while context engineering is about curating the entire working set the model reasons over. As agents run for many turns and accumulate history, this curation, not the cleverness of any single instruction, is what determines whether they stay accurate.

The core principle is least context: include only what changes the next decision, and leave out everything that doesn't. More context is not more help. Irrelevant material dilutes attention, raises cost, increases latency, and gives the model more opportunities to latch onto the wrong detail. Every token in the window should be earning its place by influencing the action the agent is about to take.

What earns a place in the window

Four things reliably deserve to be in context. The stable instructions — the agent's identity, hard constraints, and the rules of the road. The currently relevant tools — not your entire catalog, just the ones plausibly useful for this task right now. The task-pertinent facts — the specific records, IDs, and retrieved passages this step needs. And a compact running state — a summary of what's been done and decided, rather than the raw transcript of every prior turn.

flowchart TD
  A["New turn"] --> B["Stable instructions"]
  B --> C["Select relevant tools only"]
  C --> D["Retrieve task-pertinent facts"]
  D --> E["Summarize prior turns into state"]
  E --> F{"Within token budget?"}
  F -->|No| G["Evict stale tool output"]
  G --> E
  F -->|Yes| H["Send curated context to Claude"]

The flow above is the key discipline: context is rendered fresh each turn from underlying state, not accumulated blindly. The edge from G back to E is where you reclaim space — old tool results that have been incorporated into the running state can be dropped from the literal history. The model doesn't need the raw 200-line API response from six turns ago; it needs the one fact you extracted from it.

What to leave out, and why

Leave out tools the agent won't plausibly use this turn — a long tool list both costs tokens and tempts the model into irrelevant actions. Leave out raw, unsummarized tool dumps once you've extracted what matters. Leave out entire documents when a retrieved passage will do. Leave out polite-but-empty conversational filler from history. And leave out instructions that don't bear on the current decision; a refund policy is noise on a turn that's just looking up an address.

There is one subtle exclusion worth naming: don't put facts in context that the model must not be the authority on. If a number has to be exactly right, the agent should compute or retrieve it deterministically at commit time, not carry a possibly-stale copy in its prompt and trust it. Context should inform decisions, not serve as the system of record. Keeping that line clear prevents a whole class of quiet correctness bugs.

Managing context over long tasks

Long-running agents are where context discipline pays the biggest dividends. As turns pile up, naive accumulation eventually blows the budget or buries the relevant signal. The fix is periodic compaction: at intervals, summarize the conversation so far into a compact state object — decisions made, facts established, open questions — and continue from that summary instead of the full transcript. You trade a little fidelity for a lot of headroom and a sharper, cheaper agent.

Pair compaction with externalized memory. Anything the agent might need later but doesn't need now belongs in a store it can query on demand — a scratchpad, a vector index, a structured task record — not in the live window. The agent pulls a fact back in precisely when a turn requires it. Even with very large context windows now available, this just-in-time approach beats stuffing everything in, because a focused window consistently produces better decisions than a crowded one. Big context is a safety margin, not a license to be sloppy.

Designing the prompt that frames it all

Within the curated context, structure the prompt so the model finds what it needs. Put durable instructions where they're stable and cacheable, and place the most decision-relevant material near where the action happens. Be explicit about the output you want and the constraints that bound it. State negative constraints — what not to do — as clearly as positive ones, because models follow "never promise X" better when it's spelled out than when it's merely implied. And keep the language plain; a context that reads clearly to a careful human reads clearly to Claude.

Frequently asked questions

Isn't a bigger context window the solution to all of this?

No. A larger window raises the ceiling but doesn't change the principle: a focused context produces better decisions than a crowded one, and irrelevant tokens still cost money and dilute attention. Use the headroom as a safety margin, not an excuse to skip curation.

How is context engineering different from prompt engineering?

Prompt engineering is about phrasing a single request well. Context engineering is about curating the entire working set the model reasons over across many turns — which tools, which facts, which history. In agents, the second matters more.

When should I compact the conversation?

When history grows large relative to your budget, or when old turns no longer influence current decisions. Summarize prior turns into a compact state object and continue from that, keeping decisions and established facts while dropping raw, superseded detail.

Should I ever include the same instruction twice?

Yes, for critical constraints. Restating a hard rule near the tool it governs keeps it sharp even in long contexts, where a rule stated only once at the top loses force as the window fills. Redundancy on the things that must not break is worth the tokens.

Sharp context, live on every call

CallSphere applies this same context discipline to voice and chat agents — least context, just-in-time facts, and periodic compaction — so an AI stays accurate and on task through a real conversation while it looks things up and books work. Experience it 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.