Claude Agent Patterns for Finance Commentary at Scale

The first version of a Claude finance agent usually works in a demo and falls apart in production. The reason is rarely the model — it's the structure around it. Prompts grow into sprawling walls of instruction, tools overlap, and context becomes a junk drawer of everything someone thought might help. This post collects the reusable patterns that keep a narrative agent maintainable as it goes from one statement to dozens, written from the perspective of having debugged the messy version.

Pattern: the facts table as a hard contract

The foundational pattern is to define a single structured object that represents everything the model is allowed to know about a number, and to forbid the model from referencing anything outside it. Each fact carries the canonical account, the actual, the comparatives, the computed variances, and a stable identifier. The prompt then says, in effect, "you may only cite values present in the FACTS block, and you must reference them by id." This one constraint eliminates the most dangerous class of error — confidently wrong numbers — because the model has nothing to invent from.

Make the fact object self-describing. Include units, signs, and the comparison basis so the model never has to guess whether a 0.14 means 14% or fourteen basis points. Ambiguity in the input is where grounded systems quietly go wrong; spelling everything out in the fact removes the temptation for the model to fill a gap with a plausible interpretation.

Pattern: one tool, one job, tight schemas

Resist building a single "finance tool" that does ten things based on an action parameter. Each tool should do one thing with a narrow, typed schema: get_prior_commentary(account, periods), get_budget_assumption(account), lookup_headcount(department). Narrow tools are easier for Claude to use correctly, easier to test, and easier to reason about when something goes wrong. A fat tool with a string action field invites the model to call it with combinations you never tested.

flowchart TD
  A["Facts block (ids + values)"] --> B["System prompt: role + rules"]
  B --> C["Per-line user prompt"]
  C --> D{"Needs prior context?"}
  D -->|Yes| E["Call get_prior_commentary"]
  D -->|No| F["Draft from facts only"]
  E --> F
  F --> G["Cite numbers by id"]
  G --> H["Verifier maps ids back to facts"]

Pattern: structure the prompt as role, rules, facts, task

A maintainable prompt has four clearly separated zones. The role establishes voice — a careful financial analyst writing for an audit committee. The rules are the invariants: cite numbers by id, attribute causes only to provided context, hedge unknowns, keep commentary proportional to materiality. The facts are the structured block. The task is the single narrow ask for this call. Keeping these zones distinct means you can change the voice without touching the rules, or tighten a rule without rewriting the task.

Put the rules in the system prompt and the facts and task in the user turn. This separation maps cleanly onto how Claude weighs instructions and makes prompt caching effective — the stable system prompt and rules can be cached across every line in the statement, while only the small per-line facts and task change. On a statement with thirty material lines, that caching meaningfully cuts both latency and cost.

Pattern: cite by id, verify by mapping back

Asking the model to reference each number by its fact id turns verification from fuzzy string matching into a clean lookup. The draft contains markers like [F12: +14%]; the verifier walks those markers, confirms F12 exists, and confirms +14% matches F12's stored variance. Mismatches are unambiguous. After verification you strip the markers for the human-readable version, but during generation they're the thread that ties prose to evidence.

This pattern composes with retrieval. When a causal claim leans on a prior note, have the model cite that note's id too. The verifier then checks not just that numbers are right but that every "driven by" points at a real retrieved document. It's the difference between a narrative that sounds grounded and one that provably is.

Pattern: context selection over context stuffing

A large context window is a tool, not a strategy. The pattern that scales is selecting the minimum sufficient context per call: this line's fact, its two or three most relevant prior notes, its budget assumption. Stuffing in the entire prior-quarter MD&A and the full chart of accounts measurably degrades focus and raises cost. Build retrieval that keys off the canonical account so the context for the compensation line contains compensation history and nothing about freight.

A useful discipline: log the exact context for every call and periodically review what was included versus what the model actually used. Teams almost always find they're including more than they need. Trimming context is one of the highest-leverage tuning moves available, improving quality and cost simultaneously.

Pattern: deterministic envelope, generative core

The most durable pattern is architectural: wrap the generative model in deterministic code on both sides. Before Claude: normalize, compute, select context, gate on materiality. After Claude: extract, verify, assemble. The model's job is narrow and well-defined — explain these facts in this voice. Everything brittle and high-stakes lives in code you can unit-test. This is what lets you upgrade from Sonnet to Opus, or swap a prompt, without fear: the envelope holds the system's correctness, and the core only affects how well it writes.

Treat the prompts themselves as versioned artifacts with their own tests. A small eval set of past statements with known-good commentary lets you catch regressions when you edit a rule. The pattern is to never change a production prompt without rerunning the eval — the same discipline you'd apply to any other code path that touches financial reporting.

Frequently asked questions

How granular should the facts table be?

Granular enough that the model never has to compute or infer a number — include actuals, all comparatives, computed variances, units, and signs. If the model would otherwise have to derive a value, that value belongs in the fact as a precomputed field.

Why cite numbers by id rather than letting the prose read naturally?

Ids make verification a deterministic lookup instead of brittle string matching, and they let you trace causal claims to source documents. You strip the ids for the final human-facing version, so readers never see them.

Does prompt caching really matter here?

Yes. Keeping the role and rules stable in the system prompt lets them be cached across every line of a statement, so only the small per-line facts change. On a long statement that cuts both cost and latency noticeably.

How do I keep prompts from rotting over time?

Version them, keep an eval set of past statements with approved commentary, and rerun the eval on every prompt change. Treat prompt edits with the same caution as code changes to a financial control.

Bringing agentic AI to your phone lines

These patterns — tight tools, grounded facts, selective context, a deterministic envelope — travel well beyond finance. CallSphere applies the same structure to voice and chat agents that handle every call and message, call tools mid-conversation, and book work at any hour. Explore it 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.