Reusable Claude Agent Patterns for Finance Workflows

The first finance plugin you ship works. The fifth one is a mess — unless you've found the patterns that repeat across reconciliation, flux analysis, accruals, and reporting, and factored them out. After building several of these, the same handful of structural moves keep showing up: how you shape a tool, how you frame a prompt, how you decide what enters context, and how you keep the agent honest about numbers. This post is a catalog of those reusable patterns, with the actual code shapes you'd copy into a new finance plugin.

Key takeaways

• Prefer narrow, parameterized tools over one open-ended query tool — they're more reliable and easier to audit.
• Use the "cite or refuse" prompt pattern so the agent never reports a figure it can't tie to a tool result.
• Keep procedure in skills and facts in tools; the system prompt holds only role and guardrails.
• Apply the plan-then-execute pattern so the agent commits to steps before touching data.
• Structure outputs as typed tables the downstream system can ingest, not free prose.

Pattern 1: Narrow tools beat one big query tool

The tempting first design is a single run_sql(query) tool. It feels flexible, but it pushes all the correctness burden onto the model and makes every call hard to review. The pattern that scales is a set of narrow, intent-named tools — get_trial_balance, get_account_detail, get_prior_period — each with strict schemas. The model picks an intent; the server owns the SQL.

{
  "name": "get_account_detail",
  "description": "Line-item transactions for one account in a period.",
  "input_schema": {
    "type": "object",
    "properties": {
      "account_code": { "type": "string" },
      "period": { "type": "string", "pattern": "^[0-9]{4}-[0-9]{2}$" },
      "limit": { "type": "integer", "maximum": 500 }
    },
    "required": ["account_code", "period"]
  }
}

The limit cap is a quiet but vital pattern: it stops the agent from pulling a million rows into context when it only needs to spot a variance driver.

Pattern 2: Cite or refuse

Finance can't tolerate a confident hallucinated number. The cite-or-refuse pattern lives in the sub-agent's instructions and is short: every figure in the output must be traceable to a specific tool result, and if it isn't, the agent says so rather than guessing. This single rule converts the agent from a plausible-sounding assistant into one whose numbers you can check.

You report only figures returned by a tool call this session.
For each number, name the tool and the row it came from.
If a figure is not available from a tool, write "not available"
and do NOT estimate it.

The flow this enforces — and where it diverges to a safe refusal — is worth drawing out.

flowchart TD
  A["Agent needs a figure"] --> B{"From a tool result?"}
  B -->|Yes| C["Cite tool + row"]
  B -->|No| D{"Can a tool fetch it?"}
  D -->|Yes| E["Call the tool"] --> C
  D -->|No| F["Write 'not available'"]
  C --> G["Include in report"]
  F --> G

Pattern 3: Plan, then execute

For anything multi-step — a close, an accrual run — have the agent emit a short plan before it touches data, then execute it. The plan is cheap to review and catches scope errors early. In practice this is a two-phase prompt: phase one asks for an ordered step list referencing tools by name; phase two runs the steps. A reviewer (or a gate) can approve the plan before any write tool fires.

Pattern 4: Right-sizing what goes into context

The hardest pattern is contextual discipline. Procedure belongs in skills, loaded on demand. Facts belong in tools, fetched fresh. The system prompt should be small: role, tone, guardrails. Anything you can fetch, fetch — don't paste last month's trial balance into the prompt where it goes stale and consumes tokens.

Content	Where it goes	Why
Close procedure	Skill	Loaded only when relevant
Trial balance data	Tool result	Always fresh, never stale
Role + guardrails	System prompt	Always-on, kept tiny
Materiality thresholds	Skill resource	Cited policy, versioned

Pattern 5: Typed output, not prose

A finance agent's output usually feeds another system — a review queue, a workpaper, a dashboard. Have it emit a structured table or JSON with a fixed shape, then attach the narrative separately. This makes the result machine-ingestible and diffable against prior runs, which is how you catch regressions.

Common pitfalls

• One tool to rule them all. A single open query tool seems efficient but makes every call a correctness gamble. Decompose into intent-named tools.
• Trusting prose numbers. Without cite-or-refuse, the agent will smooth over gaps with invented figures. Make traceability mandatory.
• Stale context. Pasting data into prompts means it rots between runs. Fetch via tools so every run sees current data.
• Skipping the plan. Letting the agent improvise a multi-step close end to end removes your cheapest review checkpoint.
• Unbounded result sets. No limit on detail queries floods context and degrades reasoning. Cap row counts at the schema.

Apply these patterns in 6 steps

1. Replace any open query tool with two or three intent-named, schema-bound tools.
2. Add a row limit to every detail-level tool.
3. Drop the cite-or-refuse rule into each finance sub-agent's instructions.
4. Move all procedure out of the system prompt and into skills.
5. Add a plan-then-execute phase for any workflow with more than three steps.
6. Make the agent emit a typed table or JSON, with narrative as a separate field.

Frequently asked questions

Won't narrow tools mean writing lots of tools?

You write a handful and reuse them across plugins. A dozen well-named finance tools cover most workflows, and each is far easier to test and audit than one query tool that can do anything.

Does cite-or-refuse make the agent less helpful?

It makes it less confidently wrong. For finance, an honest "not available" is far more useful than a fabricated number, and it surfaces exactly where your tool coverage has gaps.

How do I keep skills from drifting out of sync with policy?

Version the skill resources like code and reference the same materiality and policy files your team already maintains. The skill cites them, so when policy changes you update one source.

Bringing agentic AI to your phone lines

These structural patterns — narrow tools, cite-or-refuse, lean context — are exactly how CallSphere keeps its agentic voice and chat assistants accurate while they answer calls, look up records live, and book work 24/7. 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.