HyperPersona
hyperpersona-web.vercel.app- hackathon
- 2026
- Team of four
- Bedrock
- Event SDK
- Top 0.1%
We built HyperPersona in a week as a team of four at Cognizant's Technoverse 2.0, and it placed in the top 0.1% of 22,000+.
It learns why a shopper buys, not just what. The browser streams consented events, agents on Bedrock turn them into facts, and a recommender ranks those facts, drafts an offer and checks every claim against its sources before showing it. I built the storefront and everything the browser sends, and shaped the architecture with the team.
- Type
- hackathon
- Role
- The storefront and everything the browser sends
- When
- One week, May 2026
- Team
- Four of us
- Stack
- React 19, TypeScript, FastAPI, DynamoDB, OpenSearch Serverless, Bedrock, Redis
- Links
- hyperpersona-web.vercel.app
My part
The storefront
The React 19 shop the engine personalises, from the catalogue to the product pages.
An event SDK
Nothing lost to a crash or a closed tab: events stored first, sent in batches, flushed on the way out.
How it worksConsent on every event
Each event carries what the shopper agreed to share, checked in the browser and again on the server. Only what both allow is kept.
Search that knows when to stop
A relevance cutoff, so a search for “towel” stopped returning 48 shirts, on OpenSearch Serverless, which I moved us to.
A noise gate
Six low-signal event types never reach the model, so it learns from intent, not page views.
The architecture, with the team
How events travel from the browser to Bedrock and back, decided together.
The agents, the fact ranking and the chain-of-verification are Divyansh Sharma's; the shop backend and CI are Anamika Aggarwal's.
How it fits together
Events that survive the tab closing
Recommendations are only as good as the signals that reach them, and a browser loses signals all the time: tabs close, pages reload, phones drop off the network. So every view and click is saved in the browser first and sent in small batches, and whatever is left leaves as the page closes. Nothing is lost to a reload, and nothing arrives twice.
Underneath: events wait in IndexedDB with an idempotency key, go every 3 s or at 50, and the last batch rides out with keepalive, trimmed under the browser’s ~64 KB budget.