Reusable Agent Patterns for Claude and MCP in Production

Once you have shipped a couple of agents, you start noticing the same shapes recurring. The agents that survive contact with production share a handful of structural patterns; the ones that break tend to violate the same few of them. This post is a field guide to those reusable patterns — for prompts, for tools, and for context — written from the perspective of someone who has watched which ones hold and which ones quietly rot. None of them are exotic. The skill is in applying them consistently.

A pattern, in this sense, is a recurring code-level structure that solves a recurring agent problem. We will move from the smallest unit — a single tool — outward to the prompt and the context window, because that is the order in which reliability compounds. Get the tools right and the prompt gets simpler; get the context right and the whole agent gets cheaper and sharper.

The single-responsibility tool

The most durable tool pattern is also the most boring: one tool, one effect, one obvious name. A tool called update_order that can change status, address, items, and shipping is a trap — the model has to guess which combination of arguments is valid, and you have to validate a combinatorial mess. Split it: change_shipping_address, cancel_order, update_order_items. Each has a tight schema, an unambiguous purpose, and a description Claude can act on without inference. Verbs in tool names, nouns in arguments.

Pair this with the read-then-write pattern. Mutating tools should usually require the agent to have just read the current state, and the write should include a precondition — an expected version, status, or timestamp — that the server checks. This is optimistic concurrency applied to agents: cancel_order(id, expected_status="open") fails cleanly if the order changed underneath the agent, rather than acting on a stale view. It turns a race condition into a recoverable error the model can reason about.

The error-as-teaching pattern

Tool results are not just data; they are feedback that shapes the next decision. The pattern is to make every error result actionable and specific. Instead of error: bad request, return { "ok": false, "reason": "address_missing_postal_code", "hint": "ask the customer for their ZIP" }. The reason lets the model categorize the failure; the hint nudges it toward recovery. Over a run, this is the difference between an agent that gracefully asks a clarifying question and one that retries the same broken call three times.

flowchart TD
  A["Static system rules"] --> B["Compose prompt"]
  C["Tool schemas from MCP"] --> B
  D["Compacted task ledger"] --> B
  B --> E["Claude reasons"]
  E --> F{"Read or write?"}
  F -->|Read| G["Append result, summarize if large"]
  F -->|Write| H["Check precondition + idempotency key"]
  G --> D
  H --> D

The diagram above shows the recurring loop these patterns assemble into: static rules, live tool schemas, and a compacted ledger feed the prompt; the model reasons; reads and writes take different protected paths; and results flow back into the ledger rather than piling up raw in the context. Every pattern in this post is a refinement of one of those arrows.

Layered prompt structure

The reusable prompt pattern is to layer it into stable and volatile parts. The stable layer — the agent's role, hard rules, and escalation policy — never changes within a session and should be written once, carefully, and reused verbatim. The volatile layer — the current task, the user's latest message, the compacted state — changes every turn. Keeping these physically separate makes the prompt easier to reason about and, with prompt caching, dramatically cheaper, because the stable prefix is cached while only the tail varies.

Within the stable layer, lead with the non-negotiables. State the hard constraints before the nuance: "You may never issue a refund over $500 without escalation" belongs near the top, phrased as an absolute. Models follow instructions better when the critical rules are unambiguous and front-loaded, and when each rule is independently checkable rather than buried in a paragraph of context.

The plan-then-act pattern

For multi-step tasks, a reliable pattern is to have the agent produce a short explicit plan before touching any tools, then execute it. This is not ceremony — the plan becomes an artifact you can validate. The harness can inspect the plan, reject it if it proposes a forbidden action, and use it to track progress. It also improves the model's own reasoning: committing to a plan reduces the chance the agent wanders or forgets a step halfway through a long run.

The complementary pattern is the checkpoint. After each meaningful step, record what was done in the task ledger and summarize it tersely. If the run fails, you resume from the last checkpoint instead of replaying everything. Plan-then-act gives you a forward map; checkpoints give you a backward trail. Together they make long agent runs both directable and recoverable.

Context as a budget, not a bucket

The most expensive anti-pattern is treating the context window as a place to dump everything and hope the model finds what it needs. Even with a 1M-token window in Claude Code, attention is finite and tokens cost money. The pattern that scales is to treat context as a budget you actively manage: keep a compact running summary, evict verbose tool output once its conclusion is captured, and pull large reference material on demand through a tool rather than pre-loading it.

A clean way to operationalize this is the retrieve-don't-preload pattern. Rather than stuffing a knowledge base into the system prompt, expose a search_docs tool and let the agent fetch only what the current step needs. The model pulls three relevant snippets instead of carrying three hundred irrelevant ones. The context stays sharp, the cost stays low, and the agent's answers stay grounded in exactly the material it actually used.

Frequently asked questions

Should one tool ever do more than one thing?

Rarely. Single-responsibility tools are easier for Claude to select correctly and far easier to validate and secure. If a tool needs a mode flag that changes its behavior substantially, that is usually a sign it should be two tools with distinct names and schemas.

How does the read-then-write pattern prevent stale actions?

The write call carries a precondition — an expected status or version — that the server checks before acting. If the underlying record changed since the agent read it, the write fails cleanly with a specific reason instead of acting on a stale view. The model can then re-read and decide again.

Why separate the prompt into stable and volatile layers?

It clarifies the agent's design and unlocks prompt caching: the stable prefix — role, rules, schemas — is cached and reused, while only the changing tail is reprocessed each turn. That lowers cost and latency and keeps the agent's core behavior consistent across the session.

When should I preload context versus retrieve it?

Preload only the small, always-relevant material. For anything large or situational, expose a retrieval tool and let the agent pull what the current step needs. This keeps the context budget focused, reduces cost, and grounds answers in the specific material actually used.

The same patterns, on your phone lines

CallSphere applies these reusable patterns to voice and chat agents — single-responsibility tools, layered prompts, and tightly budgeted context so every call is handled crisply and every action is grounded in real data. 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.