Claude Agent Patterns for Finance: Prompts, Tools, Context

After you've shipped a couple of Claude agents in a financial setting, you start to notice the same structural moves paying off again and again — and the same shortcuts coming back to bite you. This post collects the reusable patterns I reach for when structuring the prompt, the tool surface, and the context for a financial-services agent. None of them are about a clever wording trick; they're about how you organize the system so it stays correct as it grows.

The framing I find useful: a prompt is a contract, a tool is a capability, and context is evidence. Treat each as a first-class artifact with its own shape and rules, and the agent becomes far easier to reason about, test, and change.

Pattern 1: The layered system prompt

Resist writing one giant blob of instructions. Instead, compose the system prompt from labeled layers: an identity block (who the agent is and its scope), a constraints block (the hard rules — never quote rates not returned by a tool, never disclose another customer's data), a tool-use block (when and how to call each tool), and a format block (how to present money, dates, and disclosures). Keeping these as distinct, labeled sections makes them independently editable and reviewable — your compliance team can sign off on the constraints block without parsing prompt minutiae around formatting.

A practical refinement: put the constraints block last and make it terse and imperative. Models weight recent, clearly-stated instructions strongly, and a short list of "never" rules at the end is easier to audit than the same rules buried mid-prompt. When a new regulatory requirement lands, you add one line to one block rather than reworking a wall of text.

Pattern 2: Tools as a verb-shaped capability surface

Design your tools around the verbs of the domain, not around your database tables. "Get account summary," "list recent transactions," "initiate transfer," "open dispute" map to what a customer wants done. Each tool gets a tight schema with required fields, enums for constrained choices, and explicit units. The schema is your strongest prompt: a well-typed amount field with a currency enum prevents a whole class of model mistakes that no amount of prose can.

flowchart TD
  A["Layered system prompt"] --> B["Agent loop"]
  B --> C{"Select tool by verb"}
  C -->|read| D["get_account_summary"]
  C -->|write| E["initiate_transfer (typed schema)"]
  D --> F["Evidence into context"]
  E --> F
  F --> G["Compose answer with citations"]
  G --> H["Tool returns & audit"]

Split read and write tools deliberately, and make write tools harder to invoke — more required fields, an idempotency key, a confirmation flag. The asymmetry is intentional: you want the model to reach for read tools freely and write tools only when conditions are clearly met. A good test of your tool surface is whether a reviewer can predict, from the schemas alone, every action the agent can take. If they can't, your tools are too broad.

Pattern 3: Context as cited evidence

A reliable financial agent answers from evidence it just retrieved, not from training-data recall. The pattern that enforces this: when a tool returns data, place it in context with a clear marker, and instruct the model to ground its answer in those returned values and say so. "Your dining spend last month was $412" should trace directly to a number the summary tool returned this turn. If the model can't find a basis in the retrieved evidence, it should ask to run a tool rather than guess.

This pattern pays off most during incident review. When every figure the agent states maps to a tool return in the same turn, you can reconstruct exactly why it said what it said. It also reduces hallucination structurally: the model isn't being asked to remember balances, only to reason over evidence in front of it.

Pattern 4: Refusal and escalation as designed behaviors

In finance, knowing when not to act is as valuable as acting. Build explicit refusal paths into the prompt and tool surface: when a request falls outside entitlements, when data is missing, when the customer asks for something that needs a licensed human (specific tax or investment advice). Rather than letting the model improvise these, give it a structured escalation tool — escalate_to_human with a reason code — so escalations are first-class, logged events you can measure and tune.

The reusable insight is that escalation is a feature, not a failure. An agent that cleanly hands off the 5% of cases it shouldn't touch is more valuable, and more compliant, than one that confidently handles 100% and gets some of the hard ones wrong.

Pattern 5: Deterministic wrappers around probabilistic reasoning

Wrap the model's output in deterministic validation before anything consequential happens. If the agent proposes a transfer, a code-level validator re-checks the amount, accounts, and limits against the session entitlements — independently of whatever the model decided. Think of the model as proposing and your code as disposing. This wrapper pattern is what lets you use a probabilistic system in a domain that demands deterministic guarantees on the actions that matter.

The same pattern applies to formatting and disclosures. Rather than trusting the model to always append the right regulatory disclosure, a post-processing step can attach required disclosures based on the action taken. The model handles language and reasoning; deterministic code handles the things that must be exactly right every time.

Pattern 6: Versioning prompts, tools, and evals together

Treat the prompt, the tool schemas, and the eval set as a single versioned unit. When you change a constraint or add a tool, you bump a version and re-run the evals before release. This keeps the three artifacts coherent — a new tool without an eval for it, or a prompt change without a regression check, is how subtle behavior drift sneaks into a system handling money. Tie the version into the audit log so you can later answer "which agent version made this decision."

Frequently asked questions

What makes a good tool schema for a financial agent?

Tight types, required fields, enums for constrained choices, explicit units and currency, and an idempotency key on writes. A strong schema prevents whole classes of mistakes before the model can make them and lets a reviewer predict the agent's full action surface from the schemas alone.

How do you stop the agent from hallucinating balances?

Structure context as cited evidence: have tools return the data, mark it clearly, and instruct the model to ground every figure in those returns and ask for a tool when it can't. The model reasons over retrieved evidence rather than recalling numbers from training data.

Should refusal logic live in the prompt or in code?

Both, at different layers. The prompt teaches the model when to decline or escalate via a structured escalation tool, while code-level gates enforce entitlements and limits regardless of the model's choice. Refusal and escalation should be logged, first-class events you can measure.

Why version prompts and tools with the eval set?

Because they're one system. Changing a constraint or adding a tool without re-running evals invites silent behavior drift in a context where drift moves money. Versioning the three together, and recording the version in the audit log, keeps behavior coherent and traceable.

Patterns that carry over to voice and chat

CallSphere applies these same prompt, tool, and context patterns to voice and chat agents — verb-shaped tools, cited evidence, and deterministic guardrails behind every spoken answer. Hear it in action 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.