Reusable Agent Patterns: Prompts, Tools, Context

Most teams write their first agent ad hoc, then write their fifth one the same chaotic way, and wonder why none of them feel solid. The fix is not more cleverness — it is a small library of reusable patterns for the three things every agent is made of: prompts, tools, and context. Get these structural habits right and your agents become predictable, debuggable, and easy to extend. This post collects the patterns I reach for on nearly every Claude agent, with enough specificity that you can apply them tomorrow rather than nod and forget.

Pattern 1: Layer the prompt into stable and volatile sections

A well-structured agent prompt has a stable core and a volatile tail. The stable core — role, hard constraints, output contract, tool-use policy — never changes within a run and ideally rarely changes at all. The volatile tail — the current task, retrieved facts, recent tool results — changes every turn. Keeping these physically separated in your prompt assembly pays off twice: it makes the prompt easier to reason about, and it lets you mark the stable core for prompt caching so you are not re-billing for tokens that never change.

Within the stable core, lead with the role and the single most important constraint, because position matters. A constraint buried in paragraph six gets less weight than the same constraint stated first. Write constraints as imperatives the model can check itself against — "never call refund without first calling verify_identity" — rather than soft suggestions. The more your policy reads like a checklist, the more reliably Claude follows it.

Pattern 2: Design tools around intent, not around your API

The biggest tool-design mistake is exposing your internal API one-to-one. Your database has twelve endpoints; that does not mean the agent needs twelve tools. Design tools around the decisions the agent makes, not around your service boundaries. A single resolve_ticket tool that takes a disposition and handles the downstream writes is far easier for Claude to use correctly than five granular CRUD tools it has to orchestrate itself. Coarse, intent-shaped tools mean fewer steps, fewer chances to err, and cheaper runs.

flowchart TD
  A["Agent decision needed"] --> B{"Maps to one clear intent?"}
  B -->|Yes| C["Expose one intent-shaped tool"]
  B -->|No| D["Split by independent decision"]
  C --> E["Schema with rich descriptions"]
  D --> E
  E --> F["Validate args before side effects"]
  F --> G["Return structured result + explicit errors"]

Each tool's schema is documentation the model reads on every turn, so invest in the descriptions. State preconditions ("call only after identity is verified"), the meaning of each parameter, and the exact shape of what comes back. When two tools could plausibly apply to the same step, their descriptions must draw a bright line between them, or Claude will occasionally pick the wrong one and you will spend an afternoon debugging a prompt you should have written clearly the first time.

Pattern 3: Treat context as a budget you actively spend

Context engineering is the practice of deciding, on each turn, exactly what information enters the model's window and in what form. Treat the window as a budget: every token you spend on stale history is a token not spent on the task at hand. The reusable habit here is a context assembler that pulls fresh each turn — system core, the current goal, the last few relevant results, and any retrieved facts — rather than blindly appending everything that has ever happened. Old, irrelevant turns get summarized or dropped.

A concrete version of this is the rolling-summary pattern: after every few steps, ask the agent (or a cheap side call to Haiku) to compress the conversation so far into a short state summary, then carry the summary instead of the raw transcript. You keep continuity without carrying dead weight. The win compounds on long tasks, where a naive append strategy would have you re-sending tens of thousands of stale tokens on every single turn.

Pattern 4: Make the output contract machine-checkable

An agent that returns free-form prose is hard to build on. Define an explicit output contract — a final tool call like submit_result with a typed schema, or a required JSON shape — and validate it before you trust the run. This gives you a clean seam between the agent and whatever consumes its output, and it turns "did the agent succeed?" from a vibe into a boolean. When validation fails, feed the failure back into the loop as a tool result so Claude can correct itself rather than failing the whole run.

The contract also disciplines the model's reasoning. When the agent knows it must eventually produce a specific structured result, it tends to gather exactly the inputs that result requires and stop, instead of wandering. Defining the destination shapes the journey.

Pattern 5: Externalize procedure into Skills

When the same multi-step procedure shows up across tasks — "how we format an incident report," "our refund policy ladder" — do not paste it into every prompt. Package it as an Agent Skill: a folder of instructions, and optionally scripts and reference files, that Claude loads dynamically when the task is relevant. This keeps your base prompt small, lets the procedure evolve in one place, and means the model only pays for that context on the turns it actually needs it. Skills are progressive disclosure for agent knowledge.

The pattern pairs naturally with tools and MCP: tools give the agent the ability to act, while skills teach it the procedure and judgment for using those abilities well. Keeping the two separate — capability versus know-how — is what lets you reuse a tool across many skills and reuse a skill across many agents.

Pattern 6: Build a tiny eval harness before you scale

The pattern that saves the most pain long-term is the cheapest to start: a handful of representative cases with assertions on observable outcomes, run on every prompt change. Agents are stochastic, so a change that looks like an improvement can quietly regress an edge case. A small eval suite turns prompt iteration from superstition into engineering — you change something, you run the cases, you see what moved. Without it, every prompt edit is a gamble you cannot price.

Frequently asked questions

What is context engineering in an agentic system?

Context engineering is the deliberate practice of curating exactly what information goes into the model's window on each turn — system instructions, the current goal, relevant results, and retrieved facts — while summarizing or dropping the rest. It treats the context window as a finite budget to spend on signal, not a log to append to.

How coarse should my agent tools be?

Coarse enough to match a single decision the agent makes. Favor intent-shaped tools like resolve_ticket over thin CRUD wrappers, because they take fewer steps and offer fewer chances to err. Split a tool only when it covers two genuinely independent decisions that the agent should be able to make separately.

When should I move instructions from a prompt into a Skill?

Move a procedure into a Skill when it is reused across tasks, is too long to justify carrying in every prompt, or evolves on its own schedule. Skills load only when relevant, so they keep your base prompt lean while letting shared know-how live and change in one place.

Bringing agentic AI to your phone lines

CallSphere puts these exact patterns — layered prompts, intent-shaped tools, and tight context budgets — to work on voice and chat, so its assistants handle every call and message, use tools mid-conversation, and book work without a human in the loop. See 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.