Claude agent design patterns: tools, prompts, and context

Anyone can get a Claude agent working on a demo. Keeping it reliable as it grows from three tools to thirty, from one workflow to twelve, is a different discipline — and it is mostly about structure. The teams whose agents stay maintainable have converged on a small set of reusable patterns for shaping tools, prompts, and context. None of them are exotic. They are the agentic equivalent of good function design: clear contracts, single responsibilities, and information delivered exactly where it is needed. This post collects the patterns that survive contact with production.

Pattern 1: Tools as verbs with narrow contracts

The most leveraged pattern is also the simplest: design each tool as a single verb with a narrow, unambiguous contract. create_invoice, not handle_billing. A tool that does one thing has a description the model can't misread and a schema with no ambiguous fields. When you find yourself wanting a tool that does several things depending on a mode flag, that is a signal to split it — the model reasons far better about three crisp tools than one tool with a branching personality.

The corollary is that the tool description is prompt real estate, and you should write it that way. State when to use the tool and when not to: "Use refund_order only after confirming the order is eligible with check_refund_eligibility. Do not call this for orders older than 90 days." You are encoding policy into the tool surface, where the model reads it at the exact moment of decision rather than hoping it remembers a rule from the system prompt a thousand tokens ago.

Pattern 2: Structure the prompt as role, rules, and contract

A reliable agent prompt has three layers, and keeping them separate keeps the prompt maintainable. The role establishes who the agent is and its scope. The rules are the non-negotiable constraints, written as imperatives. The contract specifies the exact output shape. Mixing these — burying a hard rule inside a paragraph about tone — is how rules get ignored, because the model weights emphatic, well-positioned instructions more heavily than ones lost in prose.

flowchart TD
  A["Incoming task"] --> B["System prompt: role + rules + output contract"]
  B --> C["Model selects tool by reading tool descriptions"]
  C --> D{"Precondition met?"}
  D -->|No| E["Call precondition tool first"]
  E --> C
  D -->|Yes| F["Execute action tool"]
  F --> G["Validate output against contract"]
  G --> H["Return structured result"]

Put the rules where they get read. Constraints that absolutely must hold belong both in the system prompt and, for tool-specific rules, in the relevant tool description — redundancy is cheap insurance against a constraint being missed. And make the output contract concrete: not "return a summary" but "return JSON with keys summary, urgency, and next_action." A precise contract is what lets downstream code consume the agent's output deterministically.

Pattern 3: Just-in-time context over preloading

The instinct to give the model everything up front is the source of most context bloat. The better pattern is just-in-time context: keep the initial window lean and let the agent pull detail through tools as the task demands. A code agent does not need every file in the repo in context; it needs a tool to read files and the judgment to read the right ones. This keeps each turn cheap and keeps the model's attention on relevant material rather than a haystack you assembled in advance.

Pair this with a compaction pattern for long-running agents. When history grows, summarize completed steps into a compact note and drop the verbose intermediate tool results that no longer matter. The agent keeps the conclusions — "migration applied, tests green" — without re-paying for the hundred lines of test output that produced them. Just-in-time loading and aggressive compaction together are how an agent runs for fifty turns without its context degrading into noise.

Pattern 4: Isolation via subagents for noisy work

Some subtasks generate a lot of intermediate junk — a wide search, a sprawling investigation, parsing a large document. The pattern is to isolate that work in a subagent with its own context window so the noise never touches the main conversation. The subagent does the messy exploration and returns only the distilled answer. The parent agent stays clean, which means it stays reliable, because reliability degrades as irrelevant tokens accumulate.

Apply this judgment carefully, because isolation costs tokens — each subagent re-pays for its own context, and multi-agent runs commonly use several times more tokens than a single agent. The pattern earns its cost when a subtask is both noisy and separable. When work is tightly coupled and sequential, a single agent threading through it is cheaper and just as reliable.

Pattern 5: Skills for repeatable know-how

When you notice the same instructions appearing in prompt after prompt — how to format a report, the steps to run a deploy, the conventions of an internal API — that knowledge wants to be a skill. An Agent Skill is a folder of instructions and resources Claude loads dynamically when a task makes it relevant, which means the know-how lives in context only when needed instead of permanently bloating every prompt. This is the agentic version of extracting a repeated block into a shared function.

Skills also keep your prompts honest. A bloated system prompt that tries to cover every scenario is hard to maintain and dilutes the model's attention on any single task. Factoring scenario-specific guidance into skills lets the base prompt stay short and general while specialized knowledge arrives on demand, exactly when the task calls for it.

Pattern 6: Validate at the boundary, not in the model

Never trust the model to enforce a constraint that code can enforce deterministically. If the output must be valid JSON matching a schema, validate it in code after the model returns and feed validation failures back as a new turn so the model can correct itself. If a tool must never run against production, gate it with a hook, not a polite request in the prompt. The pattern is to draw a clear line between what the model decides and what code guarantees — the model supplies judgment, your code supplies the invariants.

Frequently asked questions

Should rules go in the system prompt or the tool description?

Both, depending on scope. Global rules belong in the system prompt; rules about when and how to use a specific tool belong in that tool's description, where the model reads them at the moment of decision. Duplicating a critical rule in both places is cheap insurance.

How do I stop my agent's context from degrading over long runs?

Combine just-in-time loading with compaction. Pull detail through tools only when needed instead of preloading, and periodically summarize completed steps so verbose intermediate results drop out of context while their conclusions remain.

When should know-how become a skill instead of prompt text?

When the same guidance recurs across tasks and only applies to some of them. Factoring it into a skill keeps your base prompt lean and loads the specialized knowledge dynamically, only when a relevant task appears.

Why validate output in code if the prompt already specifies a contract?

Because a prompt is a strong suggestion, not a guarantee. Code validation turns the contract into an invariant: malformed output is caught and fed back for correction, so downstream systems can consume the agent's results with confidence.

Bringing agentic AI to your phone lines

CallSphere builds its voice and chat agents on exactly these patterns — narrow tools, layered prompts, just-in-time context, and code-enforced contracts — so they answer reliably and book work without going off-script. See the patterns at 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.