---
title: "Reusable Claude Agent Patterns for Finance Workflows"
description: "Code-level Claude patterns for finance agents: narrow tools, cite-or-refuse prompts, lean context, plan-then-execute, and typed, auditable output."
canonical: https://callsphere.ai/blog/reusable-claude-agent-patterns-for-finance-workflows
category: "Agentic AI"
tags: ["agentic ai", "claude", "prompt engineering", "tool use", "finance automation", "claude cowork", "patterns"]
author: "CallSphere Team"
published: 2026-03-08T08:46:22.000Z
updated: 2026-06-07T01:28:22.948Z
---

# Reusable Claude Agent Patterns for Finance Workflows

> Code-level Claude patterns for finance agents: narrow tools, cite-or-refuse prompts, lean context, plan-then-execute, and typed, auditable output.

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.

```mermaid
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](https://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.*

---

Source: https://callsphere.ai/blog/reusable-claude-agent-patterns-for-finance-workflows