Case study · AI · Agents

Agentic AI Workflow Orchestrator

An AI operations agent for a fictional card processor. It plans, queries a read-only database and policy documents, checks its own numbers, and refuses to take actions nobody asked for, even when a document tells it to.

LangGraphPythonLLMsSQL
Screenshot of the Agentic AI Workflow Orchestrator demo
91.9%on a SQL-verified benchmark
0unauthorized actions under prompt injection
91.9%Benchmark accuracy
1.4 s per questionMedian latency

The problem

Tool-using LLM agents are useful and risky in equal measure: they can query data and take actions, and they will read untrusted text along the way. A planted instruction in a document shouldn't be able to make the agent do anything.

The goal was an agent whose answers are checked against ground truth computed from SQL, and whose safety comes from hard controls rather than hoping the model behaves.

Architecture

How data moves through the system, left to right.

Plandecide which tools to callLangGraph node
Act ⇄ toolsSQL, policy search, calculator, FX≤ 8 calls
Guardrailsscreen tool output, gate side effectsrole-based
Verifycheck every number vs. tool resultsone retry
Answerwith full replayable tracedemo page

Key decisions

Read-only by construction

SQLite opened mode=ro&immutable=1 with an authorizer that only allows SELECT/READ; single statements, 2-second timeout, capped result size.

Side-effect gate

create_ticket runs only if the user's own question asks for a ticket, and only for the analyst role. The model can't decide to do it because a document said so.

Injection screening

Tool output is data. Sentences addressing an AI ("ignore previous instructions") are stripped before the model sees them, and logged.

Benchmark with computed answers

37 questions in 7 categories; expected answers come from SQL, so scoring is automatic and CI can rerun it.

Free-tier friendly

Runs on Groq's free API with retries, a response cache keyed by the full request, and fallback models for the live demo.

Results

MeasureResult
Benchmark accuracy91.9% (34/37 questions)
Median latency1.4 s per question
Unauthorized actions under planted attacks0
Injected sentences stripped18
Tools5 (1 with a side effect, gated)
Guardrails6 layers between model and data

Synthetic database seeded deterministically: 120 merchants, 45,698 transactions and 324 chargebacks. CI rebuilds it and fails if it differs. With 37 questions, differences of a few points are within noise.

What I learned & what's next

  • Pattern-based injection screening catches common phrasings, not every attack. The side-effect gate and role checks are what actually stop an unrequested ticket.
  • The verifier is the same model checking itself: good at catching unsupported numbers, weaker at catching wrong reasoning.
  • Separating API time from rate-limit waits was essential; otherwise free-tier throttling looks like a slow agent.