Prompt and Context Design for Finance AI on Claude

You can have perfect tools, a flawless verifier, and clean MCP wiring, and still ship a finance agent that quietly misbehaves — because the wrong things ended up in its context. Prompt and context design is the lever that decides whether Claude reasons over fresh, relevant, authorized material or drifts on stale data and half-remembered rules. In regulated finance, this is not a stylistic concern; what you include and exclude from the context window directly shapes whether an answer is correct, compliant, and defensible. This post is about making those inclusion decisions deliberately.

Context design is the practice of deciding which instructions, facts, and history occupy a model's context window for a given step, and which are deliberately excluded, in order to maximize accuracy and minimize unwanted behavior. For a finance agent the guiding question is blunt: does this piece of context help Claude produce a sourced, in-policy answer right now? If not, it doesn't belong.

What always belongs: the contract, the active evidence, the live rules

Three things earn a permanent place in context. First, the behavioral contract — the rules that say facts come from tools, claims must be cited, and the agent declines rather than guesses. This is short and stable and should anchor every turn. Second, the evidence the current answer depends on: the specific tool results, each with its source_id, that the present question requires. Third, the precise regulation or policy snippets that apply to this question — not the whole manual, just the clauses in play.

Notice that all three are scoped to the current step. The contract is general but small; the evidence and rules are narrow and specific. This combination gives Claude exactly what it needs to compose a grounded answer and nothing that would invite it to wander. When the question changes, the evidence and rules in context should change with it, while the contract stays put.

What to keep out: stale facts, raw data dumps, and credentials

The exclusions matter as much as the inclusions. Keep stale facts out — a balance from three turns ago that the user has since changed is a trap, so evict resolved evidence and re-fetch when a fresh value is needed. Keep raw data dumps out — pasting an entire transaction history or a full rules table into context buries the relevant line and tempts the model to pattern-match the wrong row. And keep credentials, tokens, and internal system identifiers out entirely; the model never needs them, and anything in context is something that can leak into an output.

A useful habit is to ask, for every block you're about to include, "what could go wrong if the model over-attends to this?" Old data invites stale answers; bulk data invites the wrong pick; secrets invite leaks. If a block carries that kind of downside without a clear upside for the current step, leave it out and fetch precisely what you need through a tool instead.

flowchart TD
  A["New user question"] --> B{"Need fresh facts?"}
  B -->|Yes| C["Fetch via tool, add to context"]
  B -->|No| D["Reuse verified evidence in context"]
  C --> E["Trim: drop resolved + stale blocks"]
  D --> E
  E --> F["Context = contract + live evidence + relevant rules"]
  F --> G["Claude composes grounded answer"]
  G --> H{"Verifier: supported & in policy?"}
  H -->|No| C
  H -->|Yes| I["Deliver"]

Designing the system prompt for a regulated voice

Beyond what facts to include, the prompt sets the agent's voice — and in finance, voice is a compliance surface. Instruct Claude to explain rather than advise unless advice is explicitly in scope and accompanied by required disclosures, to use plain language a customer can act on, and to flag uncertainty openly. A sentence like "based on the contribution limit returned for your account, you have room to add up to X this year" is grounded and careful; "you should max out your contributions" is an unsanctioned recommendation. The prompt should make the careful framing the default.

Be explicit about refusal behavior too. The prompt should tell Claude that when a question falls outside its tools or its mandate — tax advice it isn't authorized to give, a request about someone else's account — the right move is a clear, polite decline and an offer to route to a human. A well-designed refusal is not a failure; it's the system correctly recognizing the edge of its competence, which in regulated finance is exactly the judgment you want.

Managing context across a long conversation

Finance conversations meander — a customer asks about a balance, then a transfer, then a fee, then circles back. Naively letting all of that pile up in context degrades accuracy turn by turn. The discipline is to maintain a running, pruned context: keep the contract, keep the conclusions reached so far with their evidence_id links, and evict the raw evidence once a sub-question is settled. If an earlier fact becomes relevant again, re-fetch it rather than trusting a stale copy.

This turns the long context window from a liability into an asset. Claude's capacity to hold a lot is useful precisely because you can keep the full chain of verified conclusions available for a coherent, consistent conversation — while still refusing to let raw, aging data accumulate. The result is an agent that remembers what it has established without being anchored to facts that have since moved. Treat context as a curated working set, not an ever-growing transcript.

Frequently asked questions

If Claude has a huge context window, why not just include everything?

Because attention is finite even when capacity is large. Dumping everything in dilutes the signal, raises the chance the model picks a stale or irrelevant fact, and increases leak risk for anything sensitive. A curated context of the contract, live evidence, and relevant rules consistently produces more accurate, more defensible answers than a maximal one.

How do I decide which regulation text to include?

Retrieve it through a tool keyed to the specific question and tax year, and include only the clauses that bear on the current answer, each with a source identifier. Including the whole regulation invites the model to apply the wrong provision; including the targeted clause keeps the reasoning narrow and the citation precise.

What's the simplest way to prevent the agent from giving unsanctioned advice?

Make "explain, don't advise" the prompt default, require disclosures for any in-scope recommendation, and back it with a verifier check that flags recommendation language lacking the mandated disclosure. The prompt sets the intent; the verifier and policy gate enforce it, so a single prompt slip doesn't become a compliance incident.

Curated context, now for spoken conversations

CallSphere brings this same disciplined context design to voice and chat agents — keeping each call grounded in fresh, authorized facts and the right disclosures, never stale data. Listen to it 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.