Agentic Workflow Architecture

Why this is the primary deep dive

The JD literally says: "Design the long-term architecture for an AI-native finance operating system. Define how agentic systems interact with financial infrastructure, data pipelines, and control and reporting frameworks." The applied-design round will almost certainly hand you a workflow ("design an agentic close" / "design a treasury monitor") and ask you to architect it on a whiteboard. This chapter is the muscle for that.

Single-agent vs. multi-agent

The first design question on any whiteboard problem is: does this need more than one agent? Most people over-reach to multi-agent because it sounds sophisticated. In finance, a single agent with a focused tool catalog is usually the right starting point.

Core orchestration patterns

The seven patterns you should be able to name and place:

1. Sequential chain: A → B → C. Each step is deterministic; AI in one or more steps. Good for close-checklist execution.
2. Router: classifier picks one of N downstream paths. Good for triage ("is this a bank txn, intercompany, or crypto recon?").
3. Tool-using single agent: agent loop with N tools, runs until done or stop condition. Default for bounded workflows.
4. Planner / worker: planner decomposes a goal into a task list; workers execute each task. Good for close orchestration.
5. Critic / reviewer: a second LLM call evaluates the first call's output before it leaves the system. Useful as an additional eval gate on Tier 2/3 outputs.
6. Human-in-the-loop: pauses on approval gates. Mandatory in SOX-regulated tiers.
7. Parallel fan-out / gather: many independent subtasks run in parallel, results aggregated. Good for "run N reconciliations for 50 entities simultaneously."

Planner / worker in detail

The planner/worker pattern is the workhorse for multi-step finance workflows. The planner is an LLM call that produces a structured plan; workers are subsequent LLM calls (or deterministic functions) that execute each plan step.

PLANNER_PROMPT = """You are a finance close orchestrator. Given a goal,
produce a JSON plan of steps. Each step must specify:
- step_id (e.g. "S1")
- type: one of [fetch, reconcile, propose_je, summarize, request_approval]
- inputs: required inputs
- depends_on: list of upstream step_ids
- risk_tier: 1|2|3
- requires_human: bool

Do not invent capabilities. Use only the tools in the catalog.
If a step would post to the GL, set requires_human: true.
"""

# Worker dispatch
def execute_plan(plan: list[dict]):
    results = {}
    for step in topo_sort(plan):
        if step["requires_human"]:
            results[step["step_id"]] = await_human_approval(step)
        else:
            results[step["step_id"]] = workers[step["type"]](step, results)
        audit_log(step, results[step["step_id"]])
    return results

Why this is finance-friendly

• The plan is inspectable before any tool fires — humans can review it, auditors can read it.
• Risk tier is encoded per step, not per agent.
• The dependency graph means failures are local and rollback is bounded.
• The same plan can be replayed for audit reconstruction.

Tool use & function calling

Recap from 03: tools are declared by name + description + JSON schema. The model picks one and emits arguments; your harness executes; results return. Finance-specific design rules:

• Granularity: tools should be verbs at a single level of abstraction. fetch_trial_balance(entity, period) ✔. do_close(entity) ✘ (too coarse — opaque to audit).
• Read/write split: prefix tools fetch_, list_, get_ for read; propose_, stage_ for write-to-staging; commit_ for production write (rarely exposed).
• Idempotency: every write tool requires an idempotency_key.
• Scope tokens: every tool call carries the agent's identity, the Process Owner, and the workflow run id.
• Tool count: aim for < 20 tools per agent. Beyond that, accuracy of tool selection degrades — split agents or use a router.

MCP — the shared tool fabric

The Model Context Protocol is Anthropic's open standard for how an agent connects to tools, resources, and prompts. It matters here because every finance integration you build for one agent should be reusable by every other agent and human. MCP gives you that.

MCP primitives

• Tools — callable functions ("fetch GL balance for entity E period P").
• Resources — read-only data the model can consult ("the May trial balance for entity E").
• Prompts — reusable templates ("standard intercompany recon prompt").

Transports

• stdio — local subprocess. Good for dev, local tools.
• HTTP + SSE — remote MCP servers, scalable.

Finance use of MCP, concretely

Build one MCP server per system, exposed to every agent:

• netsuite-mcp — tools for GL queries, JE staging, vendor lookups; resources for chart of accounts.
• blackline-mcp — tools for recon status, matching rules, certification state.
• kyriba-mcp — tools for cash positions, sweeps, FX rates.
• fireblocks-mcp — tools for vault balances, transaction lookups.
• lukka-mcp — tools for crypto subledger queries, fair-value snapshots.

Build it once. Every future agent uses it. That's the platform foundation in section 5 of the JD.

n8n vs. code-first orchestration

One of the most common interview questions for this role: "When do you reach for n8n vs. writing Python?" The honest answer:

The pattern: n8n calls Python; Python calls Claude; Claude calls MCP tools. n8n owns the workflow narrative; Python owns the substance.

Designing an agentic close workflow — end to end

The whiteboard problem you should be able to draw cold. Goal: automate the month-end close for one entity, with humans gating high-risk steps.

1. Decompose the close

A typical close has ~80 tasks. Group them:

• Pre-close: cutoffs, accruals checklist, FX rates locked.
• Reconciliations: bank, custody, on-chain, intercompany, AR, AP.
• Adjusting entries: accruals, deferrals, reclassifications.
• Consolidation: roll up entities; intercompany eliminations.
• Review & sign-off: variance analytics, Controller review, CFO sign-off.
• Reporting: financial statements, board package.

2. Risk-tier each cluster

3. Architecture (planner/worker + MCP)

                      ┌────────────────────────┐
                      │  Close Orchestrator    │
                      │  (planner agent)       │
                      └─────────┬──────────────┘
                                │ plan
              ┌─────────────────┼─────────────────┐
              │                 │                 │
        ┌─────▼─────┐    ┌──────▼──────┐    ┌─────▼─────┐
        │ Recon     │    │ Adjusting   │    │ Reporting │
        │ workers   │    │ Entry agent │    │ agent     │
        └─────┬─────┘    └──────┬──────┘    └─────┬─────┘
              │                 │                 │
              └──────── MCP fabric ────────────────┘
                          │
        ┌──────┬──────┬───┴───┬──────┬────────┐
      NetSuite Black- Kyriba Fire-  Lukka   Banks
              Line          blocks
  

4. HITL gates (the non-negotiables)

• Every proposed JE → Controller approves in Slack/n8n inbox before staging to NetSuite.
• Variance > threshold on any account → halt and escalate.
• Confidence < threshold on any recon → halt and escalate.
• Consolidation eliminations → human review before sign-off.

5. Audit log (the spine)

Every plan, every tool call, every approval, every output is logged to an append-only store with: run_id, step_id, model_version, prompt_hash, inputs_hash, outputs, latency, cost, approver_user, approval_ts. Retention: 7 years (SOX). See chapter 09 for the schema.

6. Eval & rollout

Don't ship this all at once. Sequence:

1. Pre-close status tracker (Tier 1). Ship in week 6.
2. Bank rec assistant (Tier 1 → 2). Ship in week 10.
3. Intercompany rec (Tier 2). Ship in month 4.
4. Variance commentary draft (Tier 1). Ship in month 5.
5. JE proposal for recurring accruals (Tier 2-3). Ship in month 6+, only after evals are green for two cycles.

Whiteboard answer template — 20-minute version

When you get an "architect an agentic workflow" question, walk this template aloud:

1. Clarify scope (2 min) — which entities, which period cadence, which systems, what's the must-have output?
2. Risk tier the workflow (2 min) — read-only? write-to-staging? production write? Who's the Process Owner?
3. Decompose (3 min) — what are the 4-8 distinct steps? Which need an LLM vs. deterministic code?
4. Pick a pattern (1 min) — single-agent, planner/worker, router. Defend the choice.
5. Sketch tools & MCP (4 min) — what tools does the agent need? Which MCP server hosts each? Read vs. write split.
6. Sketch HITL gates (2 min) — where does a human approve? Where does the agent bail to a human?
7. Audit & rollback (2 min) — what's logged, what's the rollback story.
8. Evals & rollout (2 min) — golden dataset, success metric, rollout sequence.
9. Failure modes (2 min) — name three concrete things that go wrong and how the design handles them.

That's the senior shape. Most candidates jump to "I'd use Claude with these three tools" without ever risk-tiering or naming a Process Owner. Don't be most candidates.

Anti-patterns to call out