Overview
FraudSentinel is a three-agent fraud investigation workflow built solo on LangGraph. It flags suspicious transactions and produces a verdict a human reviewer can actually act on — why something was flagged, not just a black-box risk score.
The agents are coordinated through shared workflow state rather than operating as independent services, and the system deliberately keeps the final risk decision out of the LLM's hands.
The Problem
Fraud detection systems tend to fail in one of two directions: an opaque score a reviewer can't interrogate, or an LLM given unrestricted authority to call a transaction fraudulent — which makes the decision hard to reproduce or audit. Neither is good enough for a decision with real financial consequences.
The problem FraudSentinel set out to solve was building a multi-stage investigation — one where an LLM could reason about and investigate a transaction, but the final risk decision stayed predictable and traceable back to the evidence that produced it.
Architecture
A transaction enters the workflow and is first screened by the Detector, which identifies suspicious signals warranting further investigation — it has no authority to declare a verdict itself. If flagged, the Investigator gathers broader context, pulling relevant stored information via Supabase/pgvector to build a fuller picture beyond the initial signal. The Decision stage then receives everything accumulated so far and produces the final verdict — but the risk score itself is calculated by deterministic, rule-based logic kept separate from the LLM's reasoning.
The three stages share state through LangGraph, with checkpointing so information from one stage is available to the next without each agent reconstructing the investigation from scratch.
Approach & My Role
I designed and built FraudSentinel end to end as a solo project. The core engineering decision was architectural: separate the workflow into distinct stages with clear responsibilities — detection, investigation, decision — and route the actual risk calculation through deterministic logic rather than the LLM, so the final verdict is reproducible and auditable.
Beyond the three-agent flow, I built in the reliability characteristics a multi-stage workflow needs to be trustworthy: async concurrent checks where investigation steps are independent, idempotency handling, and retry logic for transient failures.
Technical Decisions
Keeping risk scoring deterministic and separate from the LLM
The Investigator and Detector can reason about and interpret a transaction, but the Decision stage's risk calculation is rule-based, not model-generated. This was a deliberate boundary: LLM agents provide analysis and investigation, deterministic logic provides the auditable risk decision. A fraud verdict needs to be explainable and reproducible in a way that unconstrained LLM output isn't.
Coordinating three specialized agents through shared state, not one large agent
Rather than one agent handling detection through decision, the workflow is split into three narrower, more testable stages, coordinated through LangGraph's shared state and checkpointing. Each stage has one clear responsibility, and the Detector in particular is explicitly denied final authority — it can only flag, never conclude.
Designing for concurrency, idempotency, and retries from the start
Once a workflow has multiple stages, shared state, and the possibility of concurrent investigation checks, reliability isn't something to bolt on afterward — a failed or repeated operation has to not silently produce an inconsistent result. This shaped the architecture from the beginning rather than being retrofitted.
Challenges
The main challenge was maintaining a clean boundary between LLM-based investigation/reasoning and deterministic risk scoring. It would have been easy to let the LLM's interpretation directly influence the final fraud score, but that would make the decision harder to reproduce and audit — so the workflow had to be designed so agents could gather and reason about evidence while the final risk calculation stayed controlled by deterministic rules.
A related challenge was making the multi-agent workflow itself reliable: because the three stages share state and some investigation checks can run concurrently, I had to think carefully about state consistency, retries, and idempotency so a failed or repeated operation wouldn't produce inconsistent results. The core difficulty was balancing the flexibility of agentic reasoning against the predictability a fraud-detection workflow actually needs.
Results
FraudSentinel successfully demonstrated the intended end-to-end workflow — transaction → detection → contextual investigation → final decision — combining agent-based investigation with deterministic risk scoring. The result worth emphasizing is the separation itself: the LLM agents analyze the transaction and gather context, while the final risk assessment remains deterministic, predictable, and traceable back to the evidence that produced it, rather than depending on an LLM's free-form judgment.
Lessons Learned
Building FraudSentinel taught me that adding more agents doesn't automatically make a system better — each agent needs a clearly defined responsibility and a reason to exist. The biggest lesson was the importance of a hard boundary between probabilistic LLM reasoning and deterministic application logic: the LLM is valuable for interpreting context and investigating, but decisions that need to be reproducible and auditable should stay under explicit rules.
As a solo builder, I also learned that reliability concerns need to be designed in early rather than bolted on later — once a workflow has multiple stages, shared state, retries, and concurrency, things like idempotency and state consistency become core architecture, not implementation details. If I built it again, I'd define the agent boundaries and the deterministic decision boundary even earlier, and keep each agent as narrow and testable as possible. The broader lesson: agentic architecture should be justified by the problem, not used simply because multiple agents are possible.
Tech Stack
GitHub & Demo
Private project — code isn't publicly shared.