AfterBuy — Agents for Humans submission
Track: Everyday Agents
Tagline: Purchase problems, resolved with one informed decision.
Inspiration
A broken purchase creates a chain of small jobs: find the receipt, check the return window, compare policies, locate warranty terms, choose a remedy, submit, and keep the confirmation. Email and reminders preserve the work; the consumer still has to finish it. AfterBuy keeps the purchase alive through resolution.
What it does
AfterBuy is for online shoppers handling returns, refunds and warranty claims. It gathers purchase evidence, calculates eligibility, prepares supported remedies, and brings the user a clear decision with the exact terms. Following approval, a functioning local merchant sandbox returns a durable confirmation. Conflicting policies, missing evidence, stale approvals and failed operations stop safely.
The Quiet Ledger separates what needs a decision, work in progress and completed outcomes. This submission focuses on Purchase → Return / Refund / Warranty.
How we built it
React and TypeScript present the workflow. Python/FastAPI and SQLite hold purchase memory, evidence, approvals and events. A real Strands Agent chooses sequential, bounded purchase lookup, policy retrieval, eligibility and remedy-planning tools. Its typed decision is checked against recorded tool evidence. The model cannot approve an action. Deterministic code owns dates, risk, case/action/terms binding, state transitions and idempotency. A separate durable sandbox receiver makes the confirmation an actual stored side effect rather than generated success prose.
Amazon Bedrock powered authenticated development runs. The repository provides explicit provider configuration and a credential-free offline demonstration mode. No AWS account information or credentials are included in the public export.
Challenges and what we learned
The difficult boundary is the transition from language to authority. A valid model response can still select the wrong purchase or stop too early. We fixed a sole-purchase fallback that could substitute an unrelated item, and keep approval outside the agent. The latest authenticated generic return request still stopped at clarification rather than reaching the expected decision. The final internal review therefore remains FAIL / not release-ready; this prototype does not claim reliable completion for all natural-language requests.
Accomplishments
The local warranty workflow runs from imported receipt to explicit approval and stored sandbox confirmation. Policy conflicts preserve both sources and block execution. A prior authenticated Strands warranty run also reached confirmation; the video labels that historical evidence separately from the current offline UI. The clean public export includes runnable source, synthetic fixtures, setup, architecture, MIT licensing and a selection of existing regression tests.
Demo and evidence boundary
The video is an edited, narrated walkthrough of actual captured UI states. The September 14 flow uses the frozen runtime in deterministic offline mode. The September 5 Bedrock image is historical and from an earlier snapshot. It is not presented as a new cloud run or certification of the final snapshot.
There is no production merchant integration, payment execution, public hosted service, or verified external-user impact study. Cloud reliability is an explicit remaining limitation. No new live campaigns were started for submission.
What's next
A future development cycle would address the documented generic-request matching failure and validate it before extending merchant integrations. This submission freezes the existing MVP and does not imply those improvements are complete.
Built with
Python, FastAPI, SQLite, Strands Agents SDK, Amazon Bedrock, React, TypeScript, Vite.
Built With
- amazon-bedrock
- fastapi
- python
- react
- sqlite
- strands-agents
- typescript
- vite
Log in or sign up for Devpost to join the conversation.