Practice Interview Questions

"An agent loop has five primitives: a goal, a bounded context (system prompt + knowledge + history), a tool catalog, the loop itself (model proposes an action → harness executes → result fed back), and a stop condition. The model is stateless; everything stateful — memory, retries, audit logging — lives in the harness. The most common failure mode is a missing stop condition: an agent that 'tries hard' to do something structurally impossible will burn tokens and hallucinate. I design the bail-to-human gate before I design the happy path."

"My default is single-agent. I add agents when there's a clean skill boundary — for example, a close orchestrator planner agent that dispatches recon, accrual, and FX worker agents. The cost of multi-agent is coordination overhead and a fuzzier audit trail; the win is scoped prompts that eval cleanly and parallel execution. I'd argue for the single-agent version first; if its context blows up or its tool catalog crosses a clear boundary, then I split."

"MCP is an open protocol from Anthropic that standardizes how an agent gets tools, read-only resources, and prompt templates from external systems. The primitives are tools, resources, prompts; transports are stdio and HTTP/SSE. For this role it matters because I'd build one MCP server per finance system — netsuite-mcp, blackline-mcp, kyriba-mcp, fireblocks-mcp, lukka-mcp — and every agent reuses them. Crucially, access control and audit logging live in the MCP server, not in the agent prompt. That makes the controls auditable in a way SOX walkthroughs accept."

"Anthropic prompt caching gives roughly 90% discount on cached input tokens. In finance the wins are huge because most calls reuse the same preamble — chart of accounts, controls catalog, posting rules, recent comparatives. For a close that runs 5,000 recon calls, caching the 30K-token preamble takes cost down by close to an order of magnitude versus uncached. I put the stable preamble above the cache breakpoint, the per-call inputs below."

"NetSuite is the ERP and book of record — the General Ledger. BlackLine is the close-and-reconciliation engine — recon workflow, certifications, JE approval routing. Kyriba is the treasury management system — cash positioning, bank connectivity, FX, payments. Fireblocks is the crypto custody platform — MPC wallets, signing, policy engine. Lukka is the crypto subledger — cost basis, lot tracking, fair value, on-chain reconciliation. Mental model: Fireblocks holds the crypto, Lukka accounts for it, Kyriba positions the fiat, NetSuite books both, BlackLine reconciles everything back."

"SuiteTalk REST and SuiteQL for reads — token-based auth, pagination, rate-limit-aware retries. Writes are different: I expose only a 'propose JE' tool that writes to a staging table or to a BlackLine JE-approval queue, never directly to a posted GL period. Every write carries an idempotency key derived from entity + period + account + content hash. The agent never has a 'post-to-GL' tool — that step is a human approval routed through BlackLine workflow."

"BlackLine's deterministic matching handles the bulk auto-match. The agent works on the residual — the 5-15% of items BlackLine's rules can't match, where fuzzy description matching, cross-period timing reasoning, or evidence retrieval matter. BlackLine also remains the system of workflow record for recon certification and JE routing; the agent submits proposals into BlackLine, not around it. The boundary is decided up front to avoid double-matching bugs."

"Raw on-chain data is unaccounted: every UTXO and account move, including internal-wallet transfers that aren't taxable events. Lukka's job is to turn that into accounting-grade ledgers — lots, cost basis, FIFO/HIFO/spec-ID disposals, fair value at the right timestamp under FASB ASU 2023-08, gain/loss splits. Building that ourselves means staffing chain-specific engineers and accounting policy decisions for every event class. So the agent reconciles Lukka outputs to NetSuite — it doesn't redo Lukka's work."

"The Process Owner is the human accountable for the business outcome of the agent — typically a Controller, Treasurer, or recon owner. They sign off on the risk tier, approve the design doc, set the eval baseline, hold the kill switch, and re-approve quarterly. They're the named human in the SOX control narrative. I build the agent; they own its output the same way they'd own a junior accountant's. That's the difference between a production agent and a demo."

"Four tiers. Tier 1 is read-only: agent reads, summarizes, drafts; no mutation. Tier 2 is write-to-staging: agent proposes; human approves before staging hits production. Tier 3 is write-to-production-with-gate: agent writes only after explicit human approval, with full change-management. Tier 4 — autonomous to production — I default to disallowed in SOX scope; needs CFO + Internal Audit + Controller exception. Tier classification is the second sentence I say when sketching any design."

"It's a change-managed event. The model id and version pin are part of the production agent's controlled configuration. Bumping it goes through the regression suite at baseline thresholds, gets reviewed in the design doc, gets Process Owner approval — and if the agent is Tier 3, SOX Lead approval. The deploy artifact pins code, prompt, model id, tool catalog, MCP server versions together so rollback is one operation. 'We tried the new model because it's better' is not an answer auditors accept."

"Run id, parent run id for sub-agents, agent class, agent version, model id and pin, prompt hash, tool catalog hash, step id and type, tool name, inputs hash, redacted inputs (data-class-aware), outputs, decision — proposed/approved/rejected/escalated/halted — approver user, approver role, approval timestamp, latency, tokens in/out, cost, Process Owner, risk tier, entity, period, idempotency key, result, error. Append-only, retention 7 years for SOX. Indexed by run id, agent class, entity, period, approver — because the auditor's literal question 'show me every proposed JE rejected in March' should be one query."

"Hallucinated numbers — the agent claims a balance or matches a transaction it never actually retrieved. Dangerous because it looks plausible and humans skim. Defenses: don't trust any number in the output that didn't come from a tool result — validate the output's numbers against the tool-call log. Validate every cited id against the data universe. Don't let the LLM compute totals — expose a sum/subtract tool or do math in Python. And an anti-fabrication clause in the system prompt: missing values return null and a flag, never inferred."

"Double-posting. The naive 'retry on timeout' will book the JE twice. Defense in depth: deterministic idempotency key on every write (sha of entity, period, account, action, inputs hash); downstream system enforces uniqueness on the key; before a blind retry, query by key — if the operation completed server-side despite the timeout, don't retry. Finance has no DELETE; double-posting becomes a reversing-entry incident with a Controller signature and a post-mortem."

"Halt and escalate. Always fail in the direction of doing less, never more. Confidence below threshold — halt. Variance above threshold — halt. Period mismatch between sources — halt. Tool returned an unexpected field — halt. Halting to a human is always cheaper than guessing and then explaining a SOX issue."

"[Pull from real story.] The shape: I noticed that the agent's override rate had climbed from 3% to 11% over two weeks. I paused the agent class, queried the audit log to bound exposure, walked through the diffs with the Process Owner, and we found the upstream feed had silently added a new transaction type the agent had no rule for. We added the case to the golden set, wrote a deterministic rule for the new type, regressed, re-enabled. The point: I caught it because we were measuring override rate, and I paused without ego."

"Curated, versioned, varied. Start with 50-100 historical recons the Controller approved — those are ground truth. De-identify per data classification. Capture intermediate tool-call traces, not just final outputs. Include adversarial cases: malformed inputs, fabricated transactions, missing fields — where the correct answer is 'halt.' Include known-wrong cases — the 5% of historical breaks. Version it: golden v1, v2, tied to model and prompt versions, archived for 7 years."

"False-confidence rate — the rate at which the agent reports confidence above 0.9 and is wrong. Accuracy alone hides this. Bail rate plus accuracy plus false-confidence is the triple you actually need: bail rate calibrates the escalation gate; false-confidence catches the dangerous-and-quiet failures. Most teams measure 'percent correct' and miss the bimodal distribution where the agent's wrong answers are confidently wrong."

"Appropriate for narrative quality — variance commentary, audit summaries, structural format adherence. Not appropriate for numerical correctness — compute it. Not appropriate for citation existence — look it up. Not appropriate for SOX-relevant policy decisions — code the rules. The pattern: deterministic checks for numbers and rules; LLM-judge only for text quality. The judge itself becomes a controlled prompt under change management."

"The control reads: no change to a production finance agent deploys without passing the regression suite at baseline thresholds. The evidence is the archived regression run artifact, retained 7 years, signed off by the Process Owner. External auditors walk the control quarterly. That's how an eval program is also the change-management substrate — without it, you don't have a production agent; you have a demo wearing a lab coat."

"I'd decompose the close into 5 clusters — pre-close checklist, reconciliations, adjusting entries, consolidation, review and reporting. Risk-tier them: checklist and review are Tier 1; recons are Tier 1-2; adjusting entries are Tier 2-3; consolidation is deterministic and the agent narrates. I'd pick a planner-worker pattern: a close-orchestrator agent dispatches recon workers and a variance-commentary worker, each with its own Process Owner and tool catalog. All integrations through MCP — netsuite-mcp, blackline-mcp, kyriba-mcp, fireblocks-mcp, lukka-mcp. Every proposed JE flows to BlackLine for human approval. Every tool call, every approval, every output lands in an append-only audit log indexed by run, entity, period, approver. Roll out in sequence: status tracker first, then bank rec, then intercompany, then variance commentary, then proposed accruals — none deployed without two cycles of green evals."

"Tier 1, Process Owner is the Treasurer. Inputs: Kyriba aggregated balances, bank webhooks, Fireblocks vault snapshots, threshold policy. Tools: fetch_positions, fetch_history, fetch_policy_thresholds, send_alert. The agent polls plus subscribes to Kyriba and Fireblocks events. Anomaly logic is mostly deterministic — threshold rules plus rolling z-score for size — with the LLM doing the explanation step: 'cash in entity X is $50M below trailing 30-day median; driven by these three transactions.' Bail: data source stale beyond N minutes; conflicting signals between Kyriba and bank webhook. Sweep proposals are Tier 2 with explicit Treasurer approval in Slack. Latency budget: ingest to alert under 5 minutes; I'd monitor the actual p95."

"Weeks 1-3: discovery. Sit with Controllers, Treasury, FP&A. Map current flows. Risk-tier candidate workflows. Identify the first 2-3 highest-leverage, lowest-risk builds. Weeks 4-8: ship the platform foundations — one MCP server, the audit-log schema, the eval harness — plus the first agent, typically a Tier-1 close-status tracker or treasury morning brief. Weeks 9-12: governance docs signed off, the second build — usually bank rec assistant — in UAT with the Process Owner. By day 90 there should be one production agent in active use, one in UAT, the platform pieces in place, and a credible roadmap for the next two quarters."

"Three filters. One: judgment-heavy decisions that require accountability the agent can't carry — final close sign-off, controls override, SAR-style escalations. Two: rare, high-stakes events where the eval set can't be representative. Three: workflows where the manual control is genuinely the value-add — Controllers running variance commentary is partly how they spot anomalies; pure automation would lose the signal. The principle: automate the grind, augment the judgment, never replace the accountability."

"Hash on (amount, date) on the smaller side, scan the larger side, pop matches. O(n+m) time, O(min) space. Amounts are Decimal, never float, constructed from strings. Edge cases: duplicates handled by lists in the hash buckets, popping one-for-one; currency goes into the composite key if mixed; timezone-normalize dates to ISO date strings. Production recon adds tolerance and fuzzy description matching on the residual — but that's a follow-up after exact-match. See chapter 11 for the full code."

"Float is binary; some decimal fractions are inexact. 0.1 + 0.2 == 0.30000000000000004. Across millions of transactions, those rounding errors compound and cause failed reconciliations. Decimal in Python — constructed from strings, with explicit precision and ROUND_HALF_EVEN (banker's rounding) — gives exact decimal arithmetic. Persist money as strings or as fixed-precision integers; never as a float."

"Append-only table with run_id, parent_run_id, agent_class, agent_version, model_id, model_version_pin, prompt_hash, tool_catalog_hash, step info, tool name, inputs hash, redacted inputs, outputs, decision, approver, approval timestamp, latency, tokens, cost, Process Owner, risk tier, entity, period, idempotency key, result, error. Indexed by (agent_class, period), (run_id, ts), (approver), partitioned monthly. The auditor's question 'every rejected proposed JE in March' is one query."

"Deterministic idempotency key — sha256 of (entity, period, account, action, content hash). Pass it as Idempotency-Key header (or external-id for NetSuite). Downstream system enforces uniqueness. On a retry after timeout, first query by the key; if the operation succeeded server-side despite the timeout, don't retry. The key cannot depend on a request id or timestamp — those vary across retries — it must depend on intent."

"Two reasons. One: I find applying AI to SOX-regulated finance more interesting than general-purpose agent work — the constraints force good architecture. The fact that finance won't let you ship without audit logging, evals, and human-in-the-loop is exactly what makes the engineering worth doing. Two: the company combines that with crypto-native finance — on-chain reconciliation, Lukka, custody-as-finance — which is a strictly harder version of the same problem and where the architectural decisions made now will compound for years."

"[Be honest, name one or two real gaps.] For me: I have not personally sat through a SOX walkthrough of an AI-driven control — I understand the shape, I've built the audit-log substrate, and I'd be ramping on the actual walkthrough discipline in my first 90 days. What I do bring: production agentic systems with HITL gates, a clear platform-thinking instinct, decimal-correct finance math, and a strong default toward halt-not-post."

"[Real story.] Shape: stakeholder wanted Tier-3 autonomous behavior because the manual approvals were slow. I named the SOX exposure, proposed a Tier-2 staging approach with a 1-hour SLA on Process Owner approvals to remove the actual bottleneck, and a path to Tier 3 in a quarter if eval thresholds held. They accepted because I gave them the speed they wanted without the regulatory risk. The point: saying no is rarely 'no, full stop'; it's 'no, here's the path to your real goal.'"

"What's the highest-stakes finance workflow currently being considered for agentic automation, and what gates are non-negotiable? How is Finance currently evaluating whether an AI-drafted reconciliation or accrual is good enough before a human signs it? When external auditors walk through an automated control, what does the replay/evidence story look like today? Where do n8n vs. Python vs. MCP cleanly divide responsibilities in your existing builds, and where is the boundary still fuzzy? And — what does the Automate Everything CoE's governance actually look like in practice? Who has veto power on a Finance build?"