Back
An AI investigator for an Indian LPG gas distribution support desk
An AI agent for an Indian LPG distribution support desk that investigates complex tickets, shows how it reached each conclusion, and hands risky cases to a human. This case study covers the full journey, from a one-line brief to a working prototype, including the product strategy, UX decisions, and agent design.
My Role
Product Designer + Builder
Project Type
AI Agent
Stack
Figma, Claude Code, Vercel, GitHub, React, Vite, ESLint
Timeline
1 week
The Problem
The core conflict between LPG distributors and customers in India centers on a systemic lack of ground-level accountability, overcharging, and arbitrary delivery delays. Local distributors frequently exploit their regional monopolies by demanding illicit "home delivery charges" above the official invoice price, or forcing consumers to purchase unneeded accessories like gas stoves and safety pipes before authorizing a connection.
Customers often find themselves trapped in weeks of administrative inertia when attempting critical account updates—such as transferring a gas connection to a family member or updating a residential address—as distributors delay paperwork, remain unresponsive to follow-ups, and force citizens through endless loops of offline bureaucracy that defeat the vision of a digitized utility network.
Execution
I started with only a one-line brief. The first step was turning it into a PRD, then choosing the leanest path to a working product. I was new to building with AI, so I asked for beginner-level, step-by-step instructions and broke the work into days, so each stage ended with something that ran.
Phase 1: Think & Define
Expanded the brief into a full PRD (Claude)
Narrowed the scope from a generic SaaS or e-commerce support agent to Indian LPG distribution
Planned a lean, cost-efficient build
Outcome: a PRD and a build plan
Phase 2: Design and Set Up (Front- End)
Created the React and Vite project (“casebook”) and confirmed it runs locally
Connected the project to GitHub for version control from the start
Designed the screens and prepared the content for them
Outcome: a running, version-controlled project with defined screens and content
Phase 3: Build the Agent’s Toolkit (Back-End)
Wrote the policy for the support agent. [What does it cover, for example refunds, delivery delays or escalation rules?]
Created mock data and the read tools that fetch it.
Added a safety check and stubs for the actions the agent can take.
Outcome: all of it worked and was pushed to GitHub, so the foundation was ready before the interface and the live agent.
Phase 4: Build and Iterate
Turned the home screen into React
Built and polished the Home, Investigation and Safety screens
Merged root cause and findings into one section, added a collapsible reasoning trace and matched the bubble styling across screens
Outcome: a consistent, working interface
Went live at https://casebook-zeta.vercel.app/
What I Changed, and Why
Contextual Navigation for Home, Investigation and Safety
Operators need to move from the ticket queue into investigations and safety workflows with clear case context. Dedicated views and ticket-specific actions give each workflow its own space while keeping navigation simple and intuitive.
Merging 'root cause' and 'findings'
These started as two sections that said nearly the same thing. Combining them removed repetition and gave the operator one clear answer to read first, with the supporting evidence directly underneath.
A collapsible trace
The reasoning trace is essential for trust, but it is noisy. I made it collapsible: closed by default for speed, open on demand for audit and handover.
A dedicated Safety screen
Instead of burying risk as a tag, safety is its own surface. A gas-leak style complaint is visibly different from a routine one, and the agent's refusal to auto-act is presented as a feature, not a failure.
Future Scope
1.
Stakeholder alignment before any pixel
The most valuable decisions were about what the agent must not do on its own.
2.
Internal tools deserve the same design rigour as public products
A trace is only useful if it is designed to be skimmed and opened at the right moment.
3.
Accessibility is not a phase — it's a filter
Choosing one real domain made every screen and rule more specific and more convincing than a generic demo would.
4.
Dual-surface design requires one shared language
Going from a one-line brief to a running, version-controlled app, while new to AI, made me a better collaborator with engineers.
Continue seeing my work…
