AAPICODE.IO
TopicsAI Engineering
AI EngineeringAdvanced 6 min readUpdated 2026-05

A Production Architecture for Agentic Lending

Stop trying to build one omniscient agent. Decompose the loan lifecycle into 5 specialized, governed agents — each with a clear job, clear boundaries, and clear escalation paths.

Agentic AILendingArchitectureComplianceReg ZHuman-in-the-Loop

Powerful, and unforgiving

One hallucinated APR, one unexplained denial, one fair lending violation — and you are in regulatory territory no model card can save you from. The way out is architectural.

Glossary (60 seconds)

  • **Reg Z** — the federal rule that governs how lenders disclose APR, fees, and credit terms. Math errors here are not "bugs", they are violations.
  • **SHAP** — a method that explains *why* an ML model produced a given score, factor by factor. The audit-friendly version of "the model said so".
  • **Human-in-the-Loop (HITL)** — a person in the workflow who can approve, deny, or override agent decisions, with the full context handed to them.
  • **DAG** — directed acyclic graph; the legal sequence of steps a loan flows through. The orchestrator owns it; agents do not.

The 5 agents — at a glance

  1. 1**Orchestrator** — stateful coordinator (NOT an LLM) that routes work across the loan lifecycle DAG.
  2. 2**Data Ingestion Agent** — pulls and validates bureau, income, and KYC data; detects staleness and conflicts across sources.
  3. 3**Decisioning Agent** — ML ensemble + rules engine; emits a SHAP explanation for every decision.
  4. 4**Compliance Agent** — deterministic Reg Z and fair lending validation; no LLM in the calculation path.
  5. 5**Human-in-the-Loop Gateway** — escalates low-confidence decisions and exceptions with full context and a structured response form.

How the pieces connect

flowchart LR
    Applicant["Loan application"] --> ORCH["Orchestrator (stateful, deterministic)"]
    ORCH --> DI["Data Ingestion Agent"]
    DI --> Bureaus[("Bureaus / Income / KYC")]
    DI --> ORCH
    ORCH --> DEC["Decisioning Agent (ML + rules + SHAP)"]
    DEC --> ORCH
    ORCH --> COMP["Compliance Agent (Reg Z, Fair Lending)"]
    COMP --> ORCH
    ORCH -->|low confidence or exception| HITL["Human-in-the-Loop Gateway"]
    HITL --> ORCH
    ORCH --> Disclosures["Disclosures + Funding"]

Why the orchestrator is NOT an LLM

The orchestrator owns state, retries, timeouts, and the legal sequence of steps. None of those are good fits for a probabilistic model.

Boundary table — what each agent must NOT do

Forbidden moves are how you keep the audit story honest. Memorize this table.

AgentAllowedForbidden
OrchestratorRouting, retries, state, audit logGenerating decisions, computing APR, calling LLMs in the critical path
Data IngestionPull bureau / income / KYC, normalize, detect conflictsMaking credit policy decisions, silently choosing which bureau "wins"
DecisioningScore with ML + rules, emit SHAP, propose a decisionCalculating APR, drafting disclosures, finalizing approval without compliance
ComplianceDeterministic Reg Z math, fair lending checks, disclosure generationHosting an LLM in the APR calculation path; accepting "model said so" without proof
HITL GatewaySurface full context to a reviewer, capture structured responseAuto-overriding compliance, masking the reason an exception was raised

Confidence + reason — on every step

Every agent emits two things: a **confidence score** and a **reason**. The orchestrator turns those into one of three actions:

  • **Auto-approve** — confidence above threshold, no exception flags.
  • **Auto-decline** — confidence above threshold, deterministic reason that meets adverse action requirements.
  • **Escalate to human** — anything in between, with the full context bundle attached.

Continue the series

Modernization note

Part 2 of 3 in the LinkedIn series on Agentic AI for lending. Reformatted with TL;DR, glossary, an architecture diagram, an allowed/forbidden boundary table, and a recap.

Continue reading