docs/multi-agent-pattern-comparison.md

Multi-Agent Pattern Comparison

This document compares the monolithic "Agent" pattern previously used in the Fraud Model Explainability Assistant with the newly implemented "Workflow" pattern.

Overview

The transition from a single, monolithic agent to a structured workflow represents a shift from implicit, LLM-driven control flow to explicit, code-driven orchestration. This is particularly valuable for high-stakes domains like fraud analysis where auditability and reliability are paramount.

Architecture Comparison

Feature	Monolithic Agent (Legacy)	Workflow Pattern (New)
Control Flow	Implicit: The LLM decides the loop (Reason -> Act -> Observe) entirely.	Explicit: Python code defines the steps (Plan -> Execute -> Synthesize). The LLM is a component called within steps.
Determinism	Low: The agent might skip steps, loop indefinitely, or halluncinate tool calls depending on the prompt.	High: The process is guaranteed to follow the defined path. It will always plan first, then execute, then respond.
Auditability	Difficult: Logs are a mix of thought chains and tool outputs. Hard to programmatically verify if a specific check was performed.	High: The WorkflowState object captures exactly what intent was classified, which tools were planned, and the result of each.
Error Handling	Fragile: If a tool fails, the agent might get confused or try to "talk its way out" of the error.	Robust: Errors are caught at the step level. The workflow can implement specific fallback logic (e.g., if a tool fails, log it and proceed with partial data).
Latency	Variable: Depends on how many "thoughts" the agent has.	Predictable: Evaluating intent and generating a response are fixed cognitive steps.
Human-in-the-Loop	Complex: Hard to interrupt the ReAct loop to ask for confirmation.	Native: Easy to insert a "wait for approval" step between Planning and Execution.

Why the Workflow Pattern Wins for Fraud Analysis

1. Regulatory Compliance: We need to prove that every high-risk application undergoes specific checks (e.g., Fair Lending). A workflow guarantees this step happens; an agent does not.
2. Debugging: When an answer is wrong, we can pinpoint exactly where it failed:
   • Did the Router misclassify the intent?
   • Did the Tool return the wrong data?
   • Did the Response Generator hallucinate?
3. Integration: The workflow is easier to integrate into a larger system (e.g., a credit decisioning pipeline) because it has a predictable input/output contract.