Claude Agent Patterns: Prompts, Tools, and Context (Claude For Enterprise)

After you have shipped a few Claude agents, you start noticing the same shapes recurring. The reliable ones share a structure; the flaky ones share a set of anti-patterns. The model is rarely the bottleneck — the way you organize the prompt, define the tools, and assemble the context is. This post collects the reusable, code-level patterns that hold up when an agent runs thousands of times a day instead of once in a demo.

These are not theoretical. Each pattern below is something you can apply to your next agent this afternoon: how to lay out a system prompt so it stays editable, how to write tool definitions the model actually uses correctly, and how to feed context without drowning the model. The goal is consistency — an agent whose behavior you can predict and change deliberately.

Key takeaways

• Structure the system prompt in fixed sections: role, constraints, tools-overview, and output contract — so edits are surgical, not risky rewrites.
• Write tool definitions for the model's eyes: descriptive names, one clear purpose, and schemas tight enough to reject bad input.
• Assemble context in layers (stable, retrieved, transient) and keep the stable layer cacheable.
• Prefer a few well-named tools over many overlapping ones; ambiguity is what makes agents pick wrong.
• Make outputs verifiable — ask for structured results you can validate before acting.

Pattern 1 — The sectioned system prompt

Treat the system prompt as a small document with stable sections rather than a wall of text. A reliable layout is: a one-line role, a short list of hard constraints, a brief description of when to use which tool, and an explicit output contract. When you need to change behavior, you edit one section, and you can diff prompts like code. This structure also keeps the early, stable portion identical across requests, which is exactly what prompt caching needs to give you a discount.

The constraints section is where you state the non-negotiables in plain language — but remember these are guidance for the model, not security controls. "Never reveal another customer's data" belongs here as intent, and also as an enforced check at your tool boundary. The prompt sets behavior; the boundary sets guarantees.

A subtle benefit of sectioning is that it makes prompts testable. When the layout is fixed, you can write an eval that swaps just the constraints section and measures the behavior change, or A/B two output contracts without touching anything else. A monolithic prompt forces you to re-validate the whole thing on every tweak; a sectioned one lets you reason about one variable at a time. Over a long-lived agent that you will edit dozens of times, this discipline pays for itself many times over.

Pattern 2 — Tool definitions the model uses correctly

A tool definition is a contract written for the model. The most common cause of wrong tool calls is not model weakness — it is vague definitions. Give each tool a verb-first name, a one-sentence description of exactly when to use it, and a schema with the minimum fields. If two tools could plausibly answer the same request, the model will sometimes pick the wrong one; merge them or sharpen their descriptions.

{
  "name": "lookup_customer",
  "description": "Fetch a customer's profile and order history by customer_id. Use when the user references a specific account or order.",
  "input_schema": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string", "description": "Internal UUID, never an email"}
    },
    "required": ["customer_id"]
  }
}

Notice the description tells the model when to use the tool, and the field description rules out a common mistake (passing an email). Small clarifications like this remove whole classes of misfires.

flowchart TD
  A["Incoming task"] --> B["Stable layer: role + constraints"]
  B --> C["Retrieved layer: relevant docs/records"]
  C --> D["Transient layer: this turn's message"]
  D --> E{"Claude selects tool"}
  E -->|Clear match| F["Single correct tool call"]
  E -->|Ambiguous| G["Sharpen names/descriptions"]
  G --> B
  F --> H["Validate structured output"]

Pattern 3 — Layered context assembly

Context is not one blob; it is layers with different lifetimes. The stable layer (role, constraints, tool catalog) barely changes and should be byte-identical across requests so it can be cached. The retrieved layer is task-specific data you fetch per request — the relevant doc, the customer record. The transient layer is the current message and recent turns. Assembling context in this order keeps the expensive stable portion reusable and the variable portion small.

A common citable principle: in agent design, context engineering is the practice of deciding what information enters the model's context window on each turn, in what order, and what is deliberately left out. More context is not better; relevant context is. An agent buried in marginally-related documents reasons worse, not better.

Pattern 4 — Skills for procedural knowledge

When an agent needs to know how to do something occasionally — generate a specific report format, follow a compliance checklist — that knowledge does not belong permanently in the system prompt. Put it in a Skill: a folder of instructions and resources Claude loads dynamically only when the task is relevant. This keeps the base context lean and lets you version procedural knowledge separately from the agent's core identity. The pattern is: stable prompt for who the agent is, Skills for the playbooks it sometimes runs.

Pattern 5 — Verifiable outputs

An agent that returns prose is hard to act on safely; an agent that returns structured, validated output is not. When the next step is a tool call or a database write, ask Claude for a structured result and validate it against a schema before you do anything with it. If validation fails, feed the error back and let the model correct itself. This turns "hope the model formatted it right" into a checked contract, and it is the single cheapest reliability win in agent design.

The validate-and-retry loop deserves a small budget of its own. Allow one or two correction attempts on a schema failure, then fail loudly rather than retrying forever. In practice a clear validation error — "field amount_cents must be an integer, got '29.99'" — gets corrected on the first retry the vast majority of the time, because the model is reacting to a precise, machine-generated message rather than a vague human one. Pair this with logging of which validations fail most often; those are signals that a tool schema or its description needs sharpening upstream.

Apply these patterns in 5 steps

1. Refactor your system prompt into the four fixed sections and freeze the stable portion for caching.
2. Audit your tool definitions: verb-first names, one purpose each, minimal schemas, when-to-use descriptions.
3. Split context into stable, retrieved, and transient layers and assemble in that order.
4. Move occasional procedures out of the prompt and into Skills.
5. Make the final output structured and validate it before acting; loop on validation failure.

Common pitfalls

• Mega-prompts. Cramming every rule and example into one prompt makes editing risky and reasoning worse. Section it and move procedures to Skills.
• Overlapping tools. Five tools that could each handle a request guarantee occasional wrong picks. Consolidate and clarify.
• Dumping retrieval results raw. Twenty loosely-relevant chunks hurt more than three precise ones. Rank and trim.
• Free-text outputs feeding actions. Parsing prose into a tool call is fragile. Demand structured output and validate it.
• Breaking the cacheable prefix. Injecting a timestamp or per-request token early in the prompt silently kills your cache hit. Keep variability late.

Frequently asked questions

How many tools is too many for one agent?

There is no hard limit, but when descriptions start overlapping the model picks wrong more often. If you find yourself disambiguating tools in the prompt, that is a sign to merge or split them by clear purpose.

Should examples go in the prompt or a Skill?

A couple of canonical examples can live in the prompt. Larger example sets and step-by-step procedures belong in a Skill so they load only when relevant and do not bloat every request.

How do I keep prompt caching working?

Keep the stable layer — role, constraints, tool catalog — byte-identical across requests and place all per-request variability later in the context. Any change early in the prefix invalidates the cached portion.

What makes an output "verifiable"?

It conforms to a schema you can check programmatically before acting. Structured fields with types let you reject malformed results and ask the model to retry, instead of guessing whether prose meant what you hoped.

Bringing agentic AI to your phone lines

CallSphere applies these prompt, tool, and context patterns to voice and chat agents that stay reliable across thousands of live conversations a day. Hear the difference structure makes 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.