Reusable Claude agent patterns: prompts, tools, context

Once you have shipped two or three Claude agents, you notice something: you keep solving the same problems in slightly different ways, and the differences are mostly accidental. The teams that move fastest are the ones that turn those repeated solutions into patterns — named, reusable structures for prompts, tools, and context that they apply consistently across every agent they build. This post collects the code-level patterns I reach for on every AI-native build, the kind you can lift directly into your own codebase and stop reinventing.

Pattern 1: The layered system prompt

Treat your system prompt as a layered document, not a paragraph. The reliable structure is four stacked sections: identity (who the agent is and its single job), capabilities (what tools it has and when to use them), rules (hard constraints and refusals), and style (tone and output format). Keeping these as distinct sections — even with explicit headings inside the prompt — makes the document editable: you can tune the rules without disturbing the identity, and you can diff changes cleanly in version control.

The deeper reason this layering works is that it maps to how the model uses the information. Identity anchors behavior, rules constrain it, capabilities route it, and style shapes the surface. When all four are tangled into prose, a change to one accidentally shifts the others. As a code-level habit, store each layer as a named constant and compose them, so the same identity block can be reused across related agents while only the capabilities and rules differ.

Pattern 2: Tools as a stable, well-described interface

The single highest-leverage pattern in agent engineering is writing tool descriptions as if they were the most important prose in your system — because they are. Claude chooses tools from their descriptions, so a tool is really a small contract: a verb, the situations it applies to, and precisely typed inputs. The pattern is to keep tool names action-oriented (create_ticket, not ticket), descriptions situation-oriented ("use this when the customer reports a problem you cannot resolve directly"), and schemas strict, with enums and required fields doing the constraining.

flowchart TD
  A["Incoming task"] --> B["Layered system prompt"]
  B --> C["Tool registry: names + descriptions + schemas"]
  C --> D{"Which tool fits?"}
  D -->|Read| E["Idempotent query tool"]
  D -->|Write| F["Guarded action tool + validation"]
  E --> G["Result normalized into context"]
  F --> G
  G --> H["Model composes answer or next step"]

A second tool pattern that pays off forever: separate read tools from write tools and make read tools idempotent and write tools guarded. A read tool can be called freely as the agent explores; a write tool should validate inputs again on your side and refuse anything outside policy regardless of what the model asked. This split keeps the agent's exploration cheap and safe while putting a hard gate in front of anything that changes the world.

Pattern 3: Context as a budgeted assembly, not a dump

The context window is a budget, and the pattern is to spend it on purpose. I structure context assembly as a function that returns the message array in a fixed order: the stable cached prefix (system prompt and tool definitions), then durable memory relevant to this user, then retrieved knowledge scoped to the task, then the live conversation. The ordering is deliberate — the stable prefix sits up front so prompt caching can reuse it, cutting both cost and latency on every repeated call.

The discipline within the pattern is ruthless relevance. Retrieve the three documents that matter, not the thirty that match a keyword. Summarize long histories rather than replaying them verbatim. Every token you add competes for the model's attention, and past a point more context produces worse answers, not better ones. The mental model that keeps you honest: you are writing a briefing for a sharp colleague who will read exactly once before acting — include what they need to decide, leave out what would only distract.

Pattern 4: Structured output with a verification step

When an agent's output feeds another system — a database write, an API call, a downstream agent — ask for structured output and then verify it before you trust it. The pattern is to define the exact shape you need, request it explicitly in the prompt, and parse-and-validate the result against a schema. If validation fails, feed the error back to the model and let it correct itself; a single self-correction turn fixes the large majority of malformed outputs without human intervention.

This verify-and-retry loop is one of the most reusable patterns in the whole toolkit. It turns the model from something you hope produces clean output into a component with a contract you enforce. The same shape works for tool arguments, for JSON payloads, and for any case where the next step in your pipeline needs guarantees the raw generation cannot give you.

Pattern 5: Subagents as context-isolated workers

When a task is naturally parallel — investigate several sources, process several files independently — the pattern is to spawn subagents, each with its own fresh context window, and have the orchestrator collect compact summaries. The reusable insight is that subagents are not just for speed; they are for context economy. Each subagent does focused work in isolation and returns a distilled result, so the orchestrator's window stays clean. Use this pattern deliberately, because multi-agent runs spend several times the tokens of a single agent — reach for it when the parallelism is real, not by default.

Pattern 6: Skills for reusable expertise

The newest reusable building block is the Agent Skill — a folder of instructions, scripts, and resources that Claude loads dynamically when a task calls for it. The pattern is to package recurring expertise (how your company formats invoices, how to run a particular workflow) as a skill rather than cramming it into every system prompt. The agent pulls the skill into context only when relevant, which keeps the baseline prompt lean while making deep, specific know-how available on demand. Skills pair naturally with MCP: MCP connects the tools, skills teach the agent how to use them well.

Frequently asked questions

How detailed should a tool description be?

Detailed enough that a competent stranger could decide when to call it from the description alone. State what it does, the situations it applies to, what each parameter means, and any constraint. Vague descriptions are the leading cause of agents calling the wrong tool.

What is the difference between a skill and an MCP server?

An MCP server connects Claude to external tools and data through a standard interface; a skill is a bundle of instructions and resources that teaches Claude how and when to use those tools well. You typically use them together — servers for capability, skills for know-how.

Should I always use structured output?

Use it whenever the output feeds another system that needs guarantees. For free-form conversation, plain text is fine. The moment a downstream step parses the result, switch to structured output with a verification-and-retry step.

When are subagents worth the extra tokens?

When the work is genuinely parallel and context-isolated — multiple independent sources or files. If the task is sequential or shares heavy context, a single well-fed agent is cheaper and easier to debug.

The same patterns, running on the phone

CallSphere builds on exactly these patterns — layered prompts, guarded tools, budgeted context, and skills — to run Claude agents over voice and chat that book work and resolve issues live. See the reusable patterns in production 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.