Planner-Executor vs. Graph-Based Orchestration (LangGraph) in Banking

When moving Large Language Models (LLMs) from experimental chatbots to mission-critical enterprise applications, the orchestration layer becomes the most critical architectural decision. In highly regulated industries like banking, the choice isn't just about what the AI can do; it's about control, auditability, and determinism.

Two dominant paradigms have emerged for building complex AI agents: Planner-Executor architectures and Graph-based orchestration (popularized by frameworks like LangGraph).

To understand the real-world trade-offs, we will explore these architectures through the lens of a high-stakes, real-time banking use case: Automated Commercial Loan Underwriting and Origination.

The Use Case: Commercial Loan Underwriting

Imagine a system designed to assist commercial loan underwriters. When a mid-sized business applies for a $5 million loan, the AI must:

1. Ingest and parse financial statements, tax returns, and business plans.

2. Pull real-time news and sentiment analysis regarding the business and its industry.

3. Calculate financial ratios (Debt-Service Coverage Ratio, Liquidity, etc.).

4. Cross-reference the application against internal bank credit policies and regulatory compliance (e.g., KYC/AML).

5. Generate a comprehensive credit memo and risk recommendation.

This is a multi-step, multi-tool, high-stakes workflow. How we orchestrate it dictates the success of the project.

Architecture 1: The Planner-Executor Paradigm

In a Planner-Executor architecture, the workflow is driven dynamically by the LLM.

• The Planner receives the user's goal and breaks it down into a sequence of sub-tasks.

• The Executor carries out these tasks using tools (calculators, databases, search).

• If the Executor encounters an issue or gathers new information, it reports back to the Planner, which re-plans the next steps.

How it looks in Loan Underwriting:

The Planner is prompted: "Underwrite this loan for Acme Corp." The Planner generates a plan: [1. Extract financials, 2. Search news, 3. Calculate DSCR]. The Executor runs step 1. It realizes the PDF is scanned and unreadable. It reports back to the Planner. The Planner re-plans: [1. Use OCR tool on PDF, 2. Extract financials...].

The Trade-offs

Pros:

• High Flexibility: It handles edge cases beautifully. If a loan application is missing a standard document but includes an unconventional alternative, the Planner can dynamically adapt and figure out how to use it.

• Low Upfront Design: You don't need to map out every possible business logic branch beforehand.

Cons (The Banking Dealbreakers):

• The "Hallucination Loop": If the Planner gets confused, it can spiral into an infinite loop of re-planning, burning through API tokens and latency budgets.

• Lack of Determinism: The Planner might decide to skip the AML compliance check because it "thought" the news search was more important. In banking, skipping compliance is a fireable (and legally actionable) offense.

• Poor Auditability: Regulators require a strict audit trail of why a decision was made. Tracing a dynamic, re-planning LLM thought process is a compliance nightmare.

Architecture 2: Graph-Based Orchestration (LangGraph)

Graph-based orchestration treats the AI workflow as a State Machine or a Directed Graph. Instead of letting the LLM decide the flow, the developer explicitly defines the Nodes (actions/tools) and Edges (conditional or unconditional routing logic). State is explicitly managed and passed between nodes.

How it looks in Loan Underwriting (using LangGraph):

You build a StateGraph.

• Node A (Data Ingestion): Extracts data. Edge: If data is missing, route to Human Interrupt. If complete, route to Node B.

• Node B (Risk Analysis): Calculates ratios.

• Node C (Compliance Check): Runs AML/KYC. Edge: If fail, route to Rejection Node. If pass, route to Node D.

• Node D (Memo Generation): Writes the final report.

LangGraph manages the State (the accumulated loan data) and passes it through the graph. It also features built-in persistence and human-in-the-loop (HITL) interrupts.

The Trade-offs

Pros:

• Strict Determinism & Compliance: The flow is hardcoded. The AI cannot skip the Compliance Check (Node C) because the graph edges physically do not allow it. This makes regulatory auditing straightforward.

• Native Human-in-the-Loop: LangGraph allows you to pause the graph at Node D, send the draft memo to a human underwriter via a UI, wait for their approval, and resume the exact state.

• Cost and Latency Control: Because the routing is handled by lightweight Python code (edges) rather than LLM calls, you drastically reduce token usage and latency.

Cons:

• Rigidity: If the bank launches a brand new "Green Energy Micro-Loan" with a completely different underwriting criteria, you have to rewrite the graph. It doesn't adapt to novel scenarios out-of-the-box.

• Complex Upfront Design: Mapping out every conditional edge for a complex banking workflow requires deep domain expertise and significant upfront engineering.

Output

Head-to-Head Comparison for Enterprise Banking

Feature	Planner-Executor	Graph-Based (LangGraph)	Winner in Banking
Workflow Control	LLM decides the next step dynamically.	Developer defines strict nodes and edges.	Graph (Regulators demand control)
Handling Edge Cases	Excellent. Can dynamically pivot.	Poor. Requires pre-defined conditional edges.	Planner-Executor
Auditability	Difficult. Requires parsing LLM thought logs.	Excellent. State transitions are explicitly logged.	Graph
Human-in-the-Loop	Hard to implement natively.	Native via interrupt and state persistence.	Graph
Token Cost & Latency	High. Every re-plan costs an LLM call.	Low. Routing is handled by deterministic code.	Graph
Error Recovery	LLM can try to self-correct.	Requires explicit error-handling edges.	Tie (Depends on implementation)

The Verdict: The "Hierarchical" Hybrid Approach

In a strict banking environment, pure Planner-Executor is generally too risky for the macro-workflow due to compliance and determinism requirements. Graph-based orchestration (LangGraph) is the superior choice for the macro-architecture.

However, completely abandoning the flexibility of the Planner-Executor means your agents will fail when faced with messy, real-world data.

The Real-World Solution: Graph as the Macro, Planner-Executor as the Micro

The most robust enterprise architectures combine both. You use LangGraph to enforce the macro-compliance workflow, but you embed Planner-Executor agents inside specific nodes where flexibility is required.

How to implement this in the Loan Underwriting Use Case

1. The Macro Graph (LangGraph): You build a strict LangGraph. It enforces that Data Ingestion -> Risk Analysis -> Compliance -> Final Approval happen in that exact order. You use LangGraph's checkpointer to save the state at every step for auditability.

2. The Micro Planner (Inside the Data Ingestion Node): Inside the "Data Ingestion" node, the data is messy. One applicant sends a 100-page PDF, another sends three separate Excel files. Here, you deploy a Planner-Executor agent. The Planner looks at the uploaded files and dynamically decides: "I need to use the PDF parser on file A, the Excel tool on file B, and the OCR tool on page 4 of file A."

3. The Handoff: Once the micro Planner-Executor finishes gathering the clean data, it returns the structured data to the LangGraph state. The LangGraph then deterministically routes the clean data to the Risk Analysis node.

Summary

By using LangGraph for the macro-orchestration, the bank satisfies regulators, ensures strict compliance, and enables seamless human-in-the-loop approvals. By nesting Planner-Executor agents inside specific nodes, the engineering team retains the flexibility needed to handle the messy, unpredictable nature of real-world customer documents.

In enterprise AI, the goal isn't to choose between flexibility and control; it's to architect a system where flexibility is safely contained within the boundaries of strict control.