Applied Patterns
Concrete agentic patterns for production finance. Each agent specified as: inputs → tools → output → HITL gate → audit log. These are the patterns you should be able to draw end-to-end on a whiteboard.
The standard agent shape
Every agent in this chapter follows the same spec template. Use it in your interview answers — it signals platform thinking.
| Field | What goes here |
|---|---|
| Goal | One-sentence objective. |
| Process Owner | Named human role (Controller, Treasurer, Internal Audit Lead). |
| Risk tier | 1 (read), 2 (write to staging), 3 (write to prod with gate). |
| Inputs | Trigger + data dependencies. |
| Tools | Bounded list of MCP-backed tools. |
| Output | Structured object delivered downstream. |
| HITL gate | What halts and asks a human, and when. |
| Audit log fields | The specific fields written per run. |
| Bail conditions | Stop conditions that escalate without finishing. |
1 — Reconciliation agent
The workhorse. Reconciles a balance-sheet account between NetSuite (book) and a source system (bank, custody, exchange, intercompany).
| Goal | Reconcile account X as of date D between NetSuite and source S; produce a matched/unmatched report and propose reconciling items. |
| Process Owner | Account recon owner (typically a Senior Accountant or Controller). |
| Risk tier | Tier 2 — proposes reconciling items to BlackLine; never auto-posts JEs. |
| Inputs | account_code, as_of_date, entity_id; chart-of-accounts context (cached); prior-period recon (retrieved); tolerance policy. |
| Tools | fetch_gl_balance, fetch_gl_detail, fetch_source_balance, fetch_source_detail, match_items (deterministic), propose_reconciling_item, flag_for_human. |
| Output | ReconciliationResult{status, gl_balance, source_balance, variance, matched_items[], unmatched_items[], proposed_items[], confidence, needs_human} |
| HITL gate | Any proposed JE → BlackLine workflow → Process Owner approves → posted to NetSuite. Variance > threshold or confidence < threshold → halt, escalate. |
| Audit log | run_id, model_version, prompt_hash, inputs_hash, tool_call_sequence, decisions, latency, cost, approver, approval_ts. |
| Bail conditions | Source-system unreachable; GL period closed; variance > $X or > Y% of account. |
The core matching loop
Matching is deterministic, not LLM-driven. The LLM's job is around the matching:
- Pull GL detail (all transactions in account for period).
- Pull source detail (bank statement, custody ledger, exchange trade log).
- Deterministic match: exact match on amount + date ± tolerance, then on reference id, then fuzzy on description.
- LLM step on the unmatched residual: "given these N unmatched GL entries and M unmatched source items, propose plausible pairings, missing entries, or timing differences."
- LLM proposes reconciling items with evidence citations.
- Human reviews proposals in BlackLine; approved items become JEs.
If you let the LLM "do the whole recon," it will confidently match transactions that don't actually match. Deterministic-first, LLM-on-the-residual is the senior pattern. State this explicitly in interviews.
2 — Treasury monitor
A daily (or intraday) agent that watches cash and crypto positions, flags thresholds, drafts the treasurer's morning brief.
| Goal | Produce the daily treasury brief; flag any threshold breach within 5 minutes. |
| Process Owner | Treasurer. |
| Risk tier | Tier 1 (monitoring). Never moves money. Sweep proposals are Tier 2 with explicit treasurer approval. |
| Inputs | Kyriba balances, bank webhooks, Fireblocks vaults, FX rates, policy thresholds, historical sweep patterns. |
| Tools | fetch_cash_positions, fetch_crypto_balances, fetch_fx_rates, list_active_sweep_policies, propose_sweep, send_alert. |
| Output | Markdown brief (delivered Slack/email) + structured alerts. |
| HITL gate | Sweep proposals: treasurer approves in Slack (n8n approve node) → Kyriba executes. |
| Audit log | Same as standard + every alert sent with the threshold rule that fired. |
| Bail | Data source stale > threshold; conflicting signals between Kyriba and bank webhook. |
Why this is a great first ship
Tier 1, high visibility, treasurer is the immediate user. If you ship one production agent in your first 90 days, this is the safest candidate. Show the treasurer their morning brief was 5 minutes faster and contained one anomaly callout they'd have missed — you've earned trust for the next, riskier build.
3 — Audit-prep agent
External audit and quarterly internal audit eat finance time. This agent prepares evidence packages on request.
| Goal | Given an audit request ("provide all journal entries posted in March > $500K with supporting evidence"), assemble the evidence package. |
| Process Owner | Internal Audit Lead or Controller. |
| Risk tier | Tier 1 (read-only). Output reviewed by human before delivery to auditor. |
| Inputs | Audit request (natural language); NetSuite, BlackLine, document repository. |
| Tools | search_journal_entries, fetch_je_detail, fetch_supporting_docs, fetch_approval_chain, fetch_recon_for_account, compile_package. |
| Output | PDF/zip package + a structured manifest of what's included and the query that produced it. |
| HITL gate | Controller reviews and approves the package before it leaves the company. |
| Audit log | Standard + the original request text + the search queries the agent ran. |
| Bail | Request ambiguous → ask clarifying questions back to requester; do not guess. |
The killer feature: the agent's own runs are themselves in the audit log. When an auditor asks "how did you produce this package?" you can replay the agent's actions.
4 — Controls-validation agent
SOX requires evidence that controls operated effectively. This agent samples transactions, evaluates them against the control narrative, and produces the testing workpaper.
| Goal | For control C (e.g., "all JEs > $X require two-level approval"), sample N transactions for the period, verify the control operated, produce the workpaper. |
| Process Owner | SOX Lead / Internal Audit. |
| Risk tier | Tier 1. |
| Inputs | Control narrative, sampling methodology, period, transaction universe. |
| Tools | sample_transactions (stratified), fetch_transaction_detail, fetch_approval_chain, evaluate_against_control, generate_workpaper. |
| Output | Structured workpaper: sample, evidence per item, exceptions, pass/fail. |
| HITL gate | SOX Lead reviews workpaper; signs off; archives for external auditor. |
| Audit log | Standard + the sampling random seed (for reproducibility). |
| Bail | Exception rate > threshold → escalate immediately; auditor needs to know. |
The reproducibility (random seed) detail is high-signal — it tells auditors they can rerun your sample and get the same selection.
5 — Close-checklist orchestrator
The planner-style agent that runs the close. Not a doer; a coordinator. It tracks the 80-task close list, nudges owners, summarizes blockers, and dispatches the recon agents.
| Goal | Run the close calendar; coordinate sub-agents; produce CFO-readable status. |
| Process Owner | Controller. |
| Risk tier | Tier 1 itself (orchestration). Sub-agents have their own tiers. |
| Inputs | Close calendar (from BlackLine), prior-period actuals, current-period status. |
| Tools | fetch_close_tasks, fetch_task_status, nudge_owner (Slack/email), spawn_recon_agent, summarize_status. |
| Output | Daily close status brief + Slack nudges. |
| HITL gate | None at orchestration tier; sub-agents have their own. |
This is the cleanest first instance of the platform pattern: one agent coordinating other agents, each with its own Process Owner.
6 — Variance commentary agent
At close, every account with material movement period-over-period gets a commentary ("Revenue is up $4.2M vs. prior month driven by..."). This is grinding work; LLMs are very good at it.
| Goal | For each account where variance exceeds threshold, draft a candidate flux commentary citing transactions. |
| Process Owner | Account recon owner. |
| Risk tier | Tier 1 — drafts; humans edit and approve. |
| Inputs | Current and prior-N period balances, top transactions driving the variance, prior-period commentary (for tone consistency). |
| Tools | fetch_period_balances, fetch_top_drivers, fetch_prior_commentary, draft_commentary. |
| Output | Draft markdown per account, with explicit citations. |
| HITL gate | Recon owner reviews and edits before close. |
Add an anti-fabrication rule in the system prompt: "Every numeric claim must cite a transaction id or a balance fetched via tool. Do not invent reasons. If you cannot identify a driver, say so."
Composing agents — the platform view
These agents are not islands. A real close looks like:
T-3: Close orchestrator starts the calendar.
T-2: Pre-close checklist nudges. Treasury monitor flags cash positions.
T-1: Recon agents fan out across 40 accounts.
Variance commentary drafts as recons complete.
T+0: Controller reviews proposed JEs. Approves the recurring accruals.
Approves variance commentary.
T+1: Audit-prep agent assembles the close package for external auditor sample.
Controls-validation agent samples March JEs > $500K and produces workpaper.
T+2: Close signed off.
The audit log spans all of this. Every agent's run is queryable: "show me all proposed JEs that were rejected by the controller in the last 6 closes" becomes a one-line query — and that's exactly the kind of question an auditor will ask.
Things to prototype before interview day
If you have 1-2 evenings, build one of these. It will dramatically sharpen your answers.
- Tiny recon agent: two CSVs (a "GL" and a "bank statement" with deliberate breaks), Claude API, three tools (load_gl, load_bank, propose_match). Have it output a structured ReconciliationResult.
- Treasury monitor: a mock balances JSON, a Claude call that produces a morning brief, an n8n flow that wraps it in a Slack post.
- MCP server skeleton: a stdio MCP server that exposes two tools (
fetch_balance,list_accounts) against a SQLite fixture.
Each is 60-120 minutes. The shared payoff: you can say in your interview "I built this last week, here's what I learned" — and that beats any amount of theoretical answer.