Static 還是 Dynamic？一個框架，決定你的 AI 自動化架構Static or Dynamic? A Framework for Choosing Your AI Automation Architecture

The answer turned out to be more complicated than I expected. I assumed the experiment would be straightforward: dynamic workflow has retry logic, so accuracy would be higher. It was — but not for the reason I thought.

This article runs the same credit card billing dataset through both a static version (direct Ollama calls) and a dynamic version (LangGraph StateGraph), and reports the real-world difference between them, including the finding that changed my conclusion.

What is a Dynamic Workflow?

Static DAG (Directed Acyclic Graph): every step is hardcoded, executed in sequence. n8n, Make, Zapier — all this model. Logic is explicit, errors are traceable.

Dynamic Workflow: the graph has conditional edges that loop back. The AI decides the next step based on current state — accept the result, retry, or call a different tool. LangGraph wraps this into a StateGraph: each node reads state and outputs state, and edge routing is determined by a function.

These aren't better or worse. They solve different problems. The term went mainstream in late 2025 because three things happened simultaneously: Anthropic Claude Agent SDK went GA, LangGraph 1.0 released, and n8n shipped an AI Agent node.

Experiment Design: Same Data, Two Architectures

Input: 12 months of HSBC credit card statements (same dataset as the n8n billing article), 40 representative transactions sampled across months and categories.

Task: Classify each transaction into one of 8 spending categories (dining, subscriptions, groceries, transport, shopping, utilities, healthcare, entertainment).

Version A — Static: Direct Python loop, one Ollama call per transaction, accepts the first answer regardless of confidence.

Version B — Dynamic: LangGraph StateGraph, classify → verify → retry_inc → classify (loops back only when confidence < 0.7 and retries < 2).

Both versions use gemma4:e2b via local Ollama on an M1 MacBook 16GB. Data never leaves the machine.

⚠️ Gotcha: gemma4:e2b is a thinking model. Setting num_predict: 20 caused 405 consecutive empty responses — the thinking tokens consumed the entire token budget. The correct setting is num_predict: 2000, at roughly 8–10 seconds per transaction.

Static Version: 132 Lines, Straightforward

The core is a single loop: read transaction, build prompt, call Ollama, parse response, save. No state management, no retry logic.

The last line of the prompt: "If unsure, answer '其他' (other)."

That sentence caused problems. The gas station chain 中油 appeared 4 times. Static gave three different answers:

Same merchant chain, four appearances, three different answers. This isn't a model capability problem — it's the "if unsure, answer other" escape hatch giving the model an inconsistent way out on borderline inputs.

Dynamic Version: 237 Lines, Four Nodes

The StateGraph defines 4 nodes:

• classify: calls Ollama, estimates confidence (exact category match = 0.9, otherwise = 0.55)
• verify: confidence < 0.7 and retries < 2 → retry path; otherwise accept
• retry_inc: increments retry counter, returns to classify (second attempt includes original full merchant text)
• END: accepts final classification, writes result

The Dynamic prompt dropped the "if unsure, answer other" instruction and replaced it with a direct command to pick one of the 8 categories.

Experiment result: the retry mechanism never fired across all 40 transactions. Every model response hit a category name exactly (confidence 0.9), and the verify node waved it through.

But accuracy still jumped from 77.3% to 100%.

Results: Where Did the Improvement Come From?

All 5 corrections trace to the same cause: the Dynamic prompt removed the "if unsure, answer other" escape hatch, forcing the model to commit to one of the 8 categories. All three 中油 appearances correctly landed on "transport." KKBOX and the Netflix foreign transaction fee both went to "subscriptions."

Key insight: LangGraph's node-based design forces you to think carefully about each node's instructions. This design side effect may be more valuable than the retry mechanism itself — even when retries never fire.

Decision Framework: Which One to Choose

Start with this question: is your problem "the model gave the wrong answer," or "the model gave an uncertain answer"?

• "Wrong answer" (中油 classified as grocery store) → fix the prompt first, no LangGraph needed
• "Uncertain answer" (model responds with "maybe A or B") → retry is useful, consider Dynamic

Choose Static when:

• Input format is fixed (statements, forms, structured data)
• Classification boundaries are clear — good prompt design solves it
• Maintainability matters, errors need to be traceable

Choose Dynamic when:

• Input is free text, model responses may be irregular (not exact label matches)
• Multi-step tool calls are needed (look up merchant info → re-classify)
• Task boundary is genuinely fuzzy and self-correction logic is required
• You expect to add more nodes later (multi-model routing, external APIs)

Don't use Dynamic when:

• You just want the flow to "feel more AI"
• The real problem is a poorly written prompt (fix the prompt first)
• You don't have a working static version as a baseline yet

The architectural cost of Dynamic is real: 237 lines vs 132, +80% code complexity, +0.6s per transaction. If one prompt change solves the problem, change the prompt.