Skip to content
← All work

Case study 01 — QueueStorm Investigator

A support copilot for digital finance that can't make promises it shouldn't.

Investigates customer complaints against transaction history and returns a structured, routable decision. Rules decide; the model only writes.

Status
Hackathon build
Year
2026
Context
SUST CSE Carnival 2026 — Codex Community Hackathon (team entry)
Links
Source on GitHub ↗

Anatomy

  • Deterministic code
  • Model output
  • Guardrail
  • Data
  1. 01 · In / out
    Ticket + transactionsBangla, English or Banglish
  2. 02 · Guard
    Request validationPydantic v2 schemas
  3. 03 · Code
    Reasoning engineMatch, dedupe, route, set severity
  4. 04 · Model
    LLM draftingAgent summary + customer reply only
  5. 05 · Guard
    Safety post-processorNo PIN/OTP asks, no refund promises
  6. 06 · In / out
    Structured decisionVerdict, department, human-review flag

The problem

In digital finance, support agents triage complaints like “I sent 5,000 taka to the wrong number” by hand: find the transaction, check whether the story matches it, set severity, route it. A language model can read the complaint well — but letting it decide refunds or escalations in a money product is a liability, and a single reply asking for an OTP is a phishing incident.

What was built

  • 01A FastAPI service with one endpoint, POST /analyze-ticket, returning a typed decision: matched transaction, evidence verdict, case type, severity, department, human-review flag, confidence and reason codes.
  • 02A deterministic reasoning engine in Python for everything that has to be correct: transaction matching with Bangla-digit normalisation, duplicate-payment detection, established-recipient patterns, routing and severity.
  • 03An LLM layer, called through OpenRouter, that is limited to drafting the agent summary and the customer reply.
  • 04A safety post-processor that overwrites any draft that requests credentials, promises a refund or reversal, or points to unofficial support channels — plus prompt-injection checks on the incoming complaint.
  • 05A pytest suite covering malformed input, Bangla and Banglish complaints, duplicate payments, merchant disputes, phishing reports and injection attempts; shipped as a multi-stage Docker image.

Key decisions

  1. The model never decides.

    Verdict, routing and severity come from rules that can be unit-tested and audited. The LLM only writes prose, so a bad generation costs tone, not money.

  2. Guardrails run after generation.

    Prompt instructions ask the model to behave; the post-processor makes sure it did. Unsafe drafts are replaced with safe templates before they leave the service.

  3. It works without the model.

    With no API key or an unreachable provider, the service falls back to rule-based templates and still returns a complete, valid decision.

  4. Built for how customers actually write.

    Complaints arrive in Bangla, English and mixed Banglish with Bangla numerals. Input is normalised before matching, so amounts and phone numbers line up with transaction records.

Honest limits

  • Evaluated against the hackathon's sample cases, not live support traffic.
  • Transaction histories longer than about 100 entries are truncated to fit the context window.
  • Offline-mode replies are safe but templated, so they read less naturally.

Stack

  • Python
  • FastAPI
  • Pydantic v2
  • OpenRouter
  • Gemini 2.5 Flash
  • pytest
  • Docker

Need something like this?

AI copilots & agents for operations →

Assistants that read the request, pull the data, propose the next step — and hand anything risky to a human.

Next case study

Axo →

An AI product architect that turns an idea into a blueprint and build-ready prompts.

Have a workflow that should run itself?

Tell me what it is, what data it touches and what “done” looks like. You'll get a straight answer on whether AI is the right tool — and what it would take.

Start a project

Free 30-minute intro call. Replies within 24h.