How We Automated 1,000+ Parking Violations Per Week in 30 Days
Written By: Chakravarthy Varaga · March 10, 2026
The Problem
A US parking management company was receiving over 1,000 parking violation tickets per week through Zendesk. Each ticket was a PDF — sometimes multiple pages, sometimes scanned images — containing vehicle details, violation codes, fine amounts, and payment receipts mixed together.
Their staff was manually downloading each PDF, reading through it, and entering the data into spreadsheets. The process took days. Error rates were high. And the team couldn't scale — they were growing 4x in ticket volume but headcount couldn't keep up.
We had 30 days to get something into production.
What We Built: A Four-Agent System
Instead of a monolithic script, we deployed four named AI agents — each with a defined scope, tool set, and confidence threshold. Here's what each one does:
Agent 1: Email Classifier Agent
The first agent ingests each incoming Zendesk ticket and classifies it by document type before anything else runs. Is this a PDF invoice? A scanned image? A multi-violation ticket? A payment receipt (not a violation at all)? It assigns a document type label and a confidence score, then passes to the next agent in the chain — or flags it for human review immediately if the document type is ambiguous.
This classification step was the fix for one of our biggest day-one failures: payment receipt PDFs were being confidently and incorrectly treated as new violations by the extraction model. The classifier runs first now, always.
Agent 2: Document Understanding Agent
This agent applies multimodal LLM inference to the classified document. It reads the full content — PDFs, scanned images, and mixed-format attachments — and extracts structured fields: vehicle plate, violation code, fine amount, date, jurisdiction, and line items. The prompt was engineered to handle the variable formats across different city issuing authorities.
The agent outputs a structured JSON object per ticket, including per-field confidence scores. This is what feeds the routing decision.
Agent 3: Data Router Agent
The router evaluates the extraction confidence score against a configurable threshold. Above the threshold, the ticket moves to the auto-process queue. Below it — or if any mandatory field is missing — it routes to the human review queue. This single agent is what made 95%+ automation possible while keeping error rates near zero. The threshold itself is a business parameter, not a hardcoded value, so operations can tune it as the model's accuracy improves.
Agent 4: Validation & Harness Agent
The final agent validates what the extraction produced. It checks extracted totals against line items, detects multi-violation tickets (where our initial model failed on day one), and runs an automated evaluation harness against known-good patterns from historical data. On pass, it triggers the payment gateway automatically. On failure, it logs structured error context for review — not a silent failure, a documented one.
Human Review UI (First-Class Component)
This isn't an agent, but it's a first-class part of the system. Reviewers see the original document on the left, the extracted structured data on the right, with inline editing. Average review time: 45 seconds. Corrections made here feed back into the evaluation harness, improving the model's calibration over time.
What Broke on Day One
Three things broke immediately that weren't visible in the test data:
1. Multi-violation documents. Some tickets contained 3–4 violations from a single vehicle across different dates. The Document Understanding Agent was initially extracting only the first violation per document. We rebuilt the extraction schema to handle arrays of violations per document — and updated the Validation Agent's reconciliation logic accordingly.
2. Scanned handwritten amendments. About 8% of tickets had handwritten corrections on top of printed text that the OCR layer couldn't reconcile. We added a pre-classification step inside the Email Classifier Agent: documents with handwriting markers are routed directly to the human queue, bypassing automated extraction.
3. Payment receipt PDFs mixed into the ticket queue. The Document Understanding Agent was confidently but incorrectly treating payment receipts as new violations. Adding the Email Classifier Agent as the first step eliminated this entirely — receipts never reach the extraction layer now.
The Results
- Processing time: days → minutes
- 1,000+ tickets per week handled automatically
- 95%+ reduction in manual data entry
- 4x growth in ticket volume absorbed with the same headcount
- Real-time dashboard visibility into the full backlog
What This Tells You About Agentic AI in Production
The agent-per-concern design was the key architectural decision. Each agent has a single job, a defined confidence threshold, and a clear handoff to the next. When something breaks — and something always breaks in production — you know exactly which agent failed, why, and what to fix.
The three failures on day one were not edge cases — they were predictable from the nature of the data. The lesson is that agentic workflows in production always need a human-in-the-loop layer, not as a fallback, but as a first-class component. The Data Router Agent makes the routing decision; the human review UI handles the edge cases; the Validation Agent closes the loop. Design the human queue before you design the automation.
The second lesson is that the business rules layer matters as much as the AI layer. The Validation Agent checks what the LLM extracted — you can have excellent extraction accuracy and still produce garbage outputs if the validation rules aren't tight. Build the rules from real production edge cases, not from ideal-case assumptions.
We delivered this in 30 days because we'd shipped agentic systems like it before. The architecture wasn't novel — it was proven. The challenge was calibrating each agent to this client's specific data shape and edge cases.
