Getbaq · Self-initiated · 2026
Designing an AI agent that follows through on refunds
A self-initiated working prototype. The Flipkart, ₹3,499 case shown throughout is an illustrative prototype scenario, not a real customer or a real recovery.
Overview
The hard part wasn’t making it act. It was deciding what it should never do.
Cases, not conversations. Getbaq explores an AI agent that turns a messy refund or complaint into a case with confirmed facts, a sourced rule, a calculated deadline, and a next action the user can review. The prototype separates AI interpretation from checks done by code, and keeps consequential actions under the user’s control. Try the live prototype ↗
Messy input
Paste a message, describe what happened, or share a screenshot
Verified case
Confirm the facts; inspect the rule, source, deadline and status
Approved action
The agent prepares the next step; anything consequential waits for approval
The problem
A refund isn’t a writing problem. It’s a follow‑through problem.
1They pay ₹3,499 for a mixer grinder on 2 Aug.
2The jar arrives rusted, so they ask for a replacement.
3It’s rejected: the photo check failed.
4Three calls. “5 to 7 working days,” every time.
5Which rule applies? When is it due? They can’t tell.
6Weeks pass. The money stays with the company.
The complaint is only one step: people still have to gather evidence, find the right rule, calculate the deadline, follow up, and decide when to escalate.
- Evidence
- Rule
- Deadline
- Complaint
- Follow-up
- Escalation
ChatGPT can write the complaint. Getbaq is designed to run the case.
Why an agent
The user shouldn’t have to become the workflow.
- Find the order
- Find the policy
- Understand the rule
- Calculate the deadline
- Write the complaint
- Send it
- Remember to follow up
- Give me what you have
- I understand
- I investigate
- I verify
- I prepare
- You approve
- I track
- Read the last message
- Write a reply
- Understand the evidence
- Prepare the action
- Keep the case state
- Know the next step
The design question
How much should the agent do?
Not every step needs the same care. I used two things to decide where the user stays in control: how much a step matters, and whether it can be undone.
Not every action deserves the same autonomy.
As consequence and irreversibility increase, control shifts from the agent to the user.
High consequence
Low consequence
High consequenceCan be undone
Show it. Let them correct it.
The facts it read, the rule it picked, the deadline.
High consequenceCan’t be undone
Your tap. Always.
Sending the complaint. Escalating to 1915.
Low consequenceCan be undone
Do it. Show it.
Reading a message or screenshot. Drafting the letter.
Low consequenceCan’t be undone
Do it. Tell them.
Marking a missed deadline and moving the case to its next step.
Defining the boundaries
AI reads. Code counts. You decide.
A confident answer isn’t proof. When a date can be calculated, code calculates it from a verified rule. When an action speaks in the user’s name, the user stays in control.
AI
AI reads.
- Understand
- Interpret
- Summarize
- Draft
Code
Code counts.
- Calculate
- Validate
- Enforce
You
You decide.
- Confirm
- Edit
- Approve
- Send
- Escalate
Decision 01
Move calculations out of the model.
A confidently wrong deadline is worse than no agent.
Calculation lives in code. The date is a computed result, backed by a verified rule.
AI
Finds the ruleE-Commerce Rules · 4(4)
“…redress the complaint within one month of receiving it.”
Code
Calculates the deadlinecomputeDeadline(
"2026-08-04",
{ days: 30 }
)
→ "2026-09-03"
What the user sees
Shows where it came fromFlipkart must fix this by
3 Sep 2026
Calculated
Decision 02
Make the evidence inspectable.
A standalone “High confidence” label asks the user to trust the agent. Showing each important claim beside its source and its verification state lets them check it instead.
Flipkart must fix this by 3 Sep 2026
Rule 4(4), Consumer Protection (E-Commerce) Rules 2020: redress within one month.
Verified ruleDate calculated by codeFlipkart · ₹3,499 · paid 2 Aug 2026
The user’s own message, played back for a tap.
Confirmed by the userA rule that isn’t on the verified sheet
The model may still name it, but code does not accept it.
Confidence forced to lowNo Approve button
Decision 03
Approval before consequence.
The agent can act. It can’t speak for the user. Anything that goes out in their name waits for their approval, however much they come to trust the agent.
The complaint is sent.
Flipkart’s grievance officer.
The user’s name and contact, the order reference if known, and the letter. Nothing else.
Approve & send, Edit, or Not now. Nothing is sent until they tap.
Undo only appears after Approve & send, for a slipped tap.
Testing against failure
Testing against a real model exposed five failures.
I found these testing my own prototype against a real model, Gemini Flash, before anyone else used it. They are prototype findings, not production incidents or customer-impact numbers. Each needed a system fix, not a reworded prompt. Every fix is covered by tests; whether the model now avoids these mistakes needs the scored evaluation, which hasn’t completed a clean run.
01Wrong deadlineRule sheet
“Every failed payment gets
5 daysto be refunded.”UPI gets one working day (T+1), per RBI. A separate UPI rule now, and code computes the date.
Why it mattered UPI users would have waited four days they didn’t have.
02Merged rulesRule sheet
“Every airline refund is due in
one deadline.”Card bookings: 7 days. Travel-site bookings: 14 working days. Separate rules, each with its own source.
Why it mattered Cases were flagged late a week early.
03TimezoneCode
“Your deadline
has passed.”It hadn’t. Dates were read in the wrong timezone; every date now uses one fixed timezone.
Why it mattered Near midnight, a deadline showed as missed.
04Invented yearModel
“Payment made on
2 Aug 2023.”The user only wrote “2 Aug”. A year is now kept only if the user wrote one.
Why it mattered A wrong year makes a wrong deadline.
05Wrong recipientRule sheet
“Dear
merchant support, my UPI payment failed…”The RBI rule applies to the user’s bank. Getbaq now asks for the bank and addresses the letter there.
Why it mattered The complaint would go somewhere that can’t act on it.
Each quote is illustrative wording of the failure, not a recorded output.
Key insights
Reliability is a system problem.
Four of the five mistakes came from rules, dates and routing, not from the model.
Confidence is checked, not taken on trust.
The model rates its own, with a reason, and code forces it to low whenever the rule it cites isn’t a verified one.
From user testing
The answer wasn’t always answering the question.
In user testing, a recurring piece of feedback was that answers didn’t always match what was asked. A question about IndiGo’s cancellation policy could get a reply that missed it. A fluent answer isn’t a useful one if it doesn’t address the need.
From user feedbackAnswer missed the questionReading step
“What is IndiGo’s cancellation policy?”
They asked about a policy and got a refund questionnaire. Each message is now read first for what the person wants, and code picks the reply from that.
Why it mattered The user stops trusting the next answer too.
The reading step sorts a message, with the conversation so far, into money back, a general question, a company named on its own, or something Getbaq doesn’t do. So a policy question gets an answer, not a refund form. The card is an illustrative summary, not a recorded transcript; user feedback led to the change, and the revised answers haven’t been re-tested with users yet.
Designing for failure
The real product starts where the AI has to stop.
An agent that acts on its own has to know when not to. So I had to ask:
How does an agent act for someone without ever guessing?
Considerations
What if it isn’t sure?
No rule fits well enough to trust. It says so, shows its reasoning, and there is no Approve button.
What if a fact is missing?
It asks for every missing fact in one card, and says why each is needed.
What if there’s no address it can trust?
It won’t guess the recipient. It hands them the letter to send themselves and keeps tracking the deadline.
What if it isn’t a refund complaint?
It points elsewhere, to e-Jagriti, a lawyer or Cyber Crime (1930), rather than forcing a case.
OTPs, PINs and passwords never reach the model.
They’re stripped from the message before the model reads it, whatever the stakes. This is a rule, so it sits outside the matrix.
Explore every state in the live app
The case experience
Getbaq: the agent that runs your refund case…
The work lives in a persistent case, not a long conversation. It organises what the user sends, surfaces missing facts, links the rule to its source, calculates the deadline with code, and keeps the next action visible.
…powered by the case: one record that remembers the rule, the deadline and every reply.
A conversation starts the case. The case carries it.
Deadline
Calculated by code from the verified rule, with days left.
Facts
What the user confirmed: company, amount, dates.
Rule
The one rule that applies, with its source.
Status
Where the case is, and what happens next.
Core flows
Tell it what happened
In their own words, or paste what they already have. No forms, no categories to pick.
Confirm what it understood
Company, amount and date, played back for a tap. It asks only for what’s missing.
See the rule, and the deadline
The deadline first, then the rule and its source, and how sure the agent is, with a reason.
Sign the letter
The first time, it asks for the name and the email or phone their account uses, so the company can find the order. Nothing else.
Review, then approve
Who it goes to, what will be shared and the letter itself. Nothing is sent until they tap.
Track it, and escalate
A date the company must reply by. If it goes quiet, the 1915 complaint is ready when they next open the case, and still needs their tap.
The agent workflow
From a messy message to the next action.
Every case moves through the same eight stages. The trace shows who does each one, and which stages exist in the prototype today.
01Input
“flipkart rejected my replacement, jar has rust”
You
Built
02Understand
Flipkart · ₹3,499 · paid 2 Aug. Played back for a tap.
AI
Built
03Verify
Rule 4(4) is on the verified rule sheet.
Code
Built
04Calculate
4 Aug + 30 days = 3 Sep 2026. Computed, not guessed.
Code
Built
05Draft
A letter to Flipkart’s grievance officer.
AI
Built
06Approve
Approve & send, Edit, or Not now.
You
Built
Sending is simulated
07Track
Flipkart must reply by 3 Sep 2026.
Code
Planned
08Escalate
The 1915 complaint, written and waiting for their tap.
You
Planned
Illustrative prototype case, not a real recovery. Built means it works in the prototype. Simulated means it is shown but not wired to the real world. Planned means designed, not built: follow-ups while the app is closed, escalation workflows and real-world integrations.
Behind the decisions
The research, and the ideas I dropped.
Detail for anyone who wants it. The story above stands without it.
Research
I couldn’t recruit in time, so I changed the method, not the questions.
I planned 5–8 interviews with people holding a stuck refund. Recruiting didn’t come through in time, so I answered the same questions from public evidence: Reddit and X complaints, app reviews, consumer forums, news and government data. Every finding carries a confidence label.
The questions I kept
How many times did you follow up? What made you stop?
The give-up moment, which is the product’s job to removeDid you know about the 1915 helpline?
The awareness assumptionDid you paste it into ChatGPT?
Whether ChatGPT is the real competitorIf someone followed up for you, what would you not want them to do?
The trust boundary
Most people with a serious problem got no help from the company, and few seem to know the channel that works.
- 66%
- of people with a major service problem got no help from the company. LocalCircles, 2026
- +6.9 pts
- more likely to get relief when a complaint was AI-assisted. Nature Human Behaviour, 2026
What companies reply. “5 to 7 working days.” “We are very sorry sir.” Tickets closed with nothing fixed.
High confidenceWhether they know 1915. Mostly not. Those who find it often get refunds in days.
MediumWhat they won’t let an agent do. Share an OTP or bank details. Send anything false or rude.
Low: inferred, not surveyed
Exploring directions
Three ideas I dropped.
Pure chat
Decisions disappear into the conversation.
Conversation, plus action cards, plus a persistent case
The conversation keeps the ambiguity; decisions live on cards and in the case.
Rejected
42 messages earlier
flipkart rejected my replacement
I can help! What was the order date?
2 aug i think
Chosen
Flipkart ₹3,499
Reply by 3 Sep 2026
Send it
Making the user sort the evidence
They’d still be doing the organising.
One box for anything; the agent structures it
Sorting evidence is the agent’s job.
Rejected
Company
Amount
Upload a screenshot
Chosen
What happened?
flipkart rejected my replacement, jar has rust…
Paste, forward or type
An autonomy dial
Trust shouldn’t decide who bears the consequence.
Permission follows the consequence
Anything that can’t be undone always waits for the user.
Rejected
Autonomy
Ask meDo it all
Chosen
Can be undoneJust do it
Can’t be undoneUser’s tap
Prototyping and testing
Three versions of the input, then a real model.
A form made people classify their evidence before getting help. Upload-first was less formal, but they still sorted their own material. The third version lets them start with what they have, and the agent structures it. Then I tested the agent against a real model, Gemini Flash.
- The user had to decide what kind of evidence they were giving.
- Fewer decisions up front, but they still sorted their own input.
- Paste whatever you have; sorting it is the agent’s job.
Scope & limitations
What’s tested, and what isn’t proven yet.
Everything with one right answer is tested: 214 passing tests across 20 files. The model’s judgment needs a scored evaluation: 30 sourced cases are ready, but the runs so far stopped at the model’s free daily limit, so there’s no score yet. These are different kinds of evidence.
Deterministic system
214tests, all passing
✓lib/deadlines.test.ts (35 tests)✓lib/requiredFacts.test.ts (28 tests)✓lib/state.test.ts (24 tests)✓lib/validate.test.ts (12 tests)✓lib/otp.test.ts (8 tests)✓lib/tone.test.ts (5 tests)…and 14 more filesTest Files 20 passed (20)Tests 214 passed (214)
Model evaluationNot yet completed
30sourced test cases, from real public complaints
Case C03Trap
“Flipkart order from 2019 still shows pending, cash on delivery, never came.”
Expected rule: null. No money was paid, so there’s no refund to chase.
- Built
- Working prototype on a real model. AI interpretation and summarising of evidence, rule and evidence artifacts checked by code, an approval flow with undo, six failure states, a case-oriented interaction model and Google sign-in.
- Simulated or planned
- Sending is simulated. Sending from the user’s own Gmail, follow-ups and escalation workflows while the app is closed, and real-world integrations are planned.
- Not yet proven
- Real-world refund recovery. Model accuracy with real users (no clean scored run yet). Long-term user trust. Post-launch behaviour and willingness to pay.
Reflection
A useful agent needs boundaries, not just capabilities.
Next, I’d score the model across representative questions and policy edge cases, then test whether people can find the evidence behind an answer, explain the next step and spot what’s uncertain. That work hasn’t been done yet.
- 01Relevance comes first.
An answer has to address the question before it can help with the next step.
- 02Failure is product material.
Missing facts, conflicting rules and uncertain dates need designed states.
- 03Boundaries are interface decisions.
The split between AI, code and user control shapes the product.
Cases, not conversations. Evidence, not prompts. Actions, not answers. Resolution, not response generation.
Getbaq is a working prototype, not a shipped product. Its next proof is whether people can use and trust it in real refund cases.