The SE7EN Deadly sAInts
...and our unexpected win after 'giving up' right before the demo
Where did we start?
Our team started with two unrelated, if not diametrically opposite, ideas. One side wanted to analyse the past, while the other wanted to focus on the future. So obviously, we handled this disagreement by doing what any sensible group would — we decided to work on both ideas for the 1st day ^_^
Two ideas for one hackathon?
Idea#1: We analyse all past customer conversations to derive feature-specific insights.
Why? If we can intelligently parse past customer conversations and read their sentiments, we can get feature-specific insights like customer satisfaction, ease-of-use, etc.
Idea#2: We build a browser-aware AI agent that makes all repetitive tasks obsolete in the future.
Why? If we can build an agent that can interact with the browser and run some repetitive tasks for us, we can automate all validation workflows
So, at the end of Day 1, why did we choose not to go for the past?
Inherent survivorship bias if we only analyse customer conversations
Dependence on data exports from our CS platforms
And why did we decide to work on the future?
Our team already had context on a subset of the problem
It felt like a more impactful problem to solve
So, finally, we started mapping out our AI agent.
📸 The Big Picture
If we can enable AI to “use” the browser, we can forge into existence an overpowered supercharged “support” buddy.
Today, our support teams handle some repetitive tasks/sub-tasks. One of which is having to modify/heal storefront-visible aspects of Swym features like Wishlist Plus.
Merchant issues often map to predictable/repeatable/algorithmic logic and DOM-level modifications.
Vision: Give an AI agent Swym context and browser tools.
Outcome: The agent autonomously troubleshoots and self-heals Swym features.
🧩 The Problem
Scaling problem: Current automations for storefront features, (for example, injecting icons/buttons for Swym Features like Wishlist) are dependent on predefined theme-dependent configuration. Only way to expand, and scale is to manually identify (which takes time, and eats into support bandwidth) appropriate selectors for each theme and add them to the configuration.
Enterprise problem: Bigger stores – our Enterprise clients, typically use custom themes, which means their themes cannot be covered by any “predefined” configurations.
3rd-party problem: In some cases, even our predefined configs for recognized themes may fail because of 3rd party page-builders/search-filters/modified theme architecture.
The 🦋 Effects
Support Overload: Support spends considerable bandwidth on storefront issues for Swym features.
Poor Onboarding: Interrupts the merchant's onboarding and impacts TTL. Not the experience we want to ideally deliver.
🎯 Enter Swym DOMinator
For this hackathon, we limited the scope to our Autonomous Browser Agent being able to heal issues where icon injection for product listing fails. And, for lack of a better word, we decided to name this agent Swym DOMinator for now!
So, how does it work?
Inspiration: Well, how does our team do it today?
Manually open the browser.
Locate all product grids (Ex., on PLP, on PDP).
Use Dev Tools to identify the product tile and then find an appropriate selector. Ideally, this one should have the CSS position property set to ‘relative’.
They then use these selectors in a predefined script to test it out for that store itself.
Once they verify that it works on every product grid, they then save the selectors and notify the merchant.
IF it does not work, they go back to step 3 and repeat.
Well, why can’t our AI agent just… do the same?
🔮 Leveraging Gemini to analyse and reason
And… It works! Our laser-sharp focus on this little giant of a problem won us the Runner’s Up prize!
⏳Future scope
Integrating IMAGE PROCESSING techniques to get DOM elements and modify them. Similar use case to browser use.
Integrate the automation into the onboarding flow.
Extend the same principles for a full UI health check (other teams stop here, NOT US) with auto-heal capabilities
A Chrome extension for Support
Alert to escalate when DOMinator fails
Now, if you have reached this far, you might be thinking, “Wait, so what was that about giving up in the post’s subtitle?”. While DOMinator’s hackathon story ends here, The SE7EN Deadly sAInts’ redemption story is still below. Read on to find out about our Baazigar moment.
🤔 “Wait, so what was that about giving up?”
Demo Day and The Twist of Fate 💫
On Day Two, we knew exactly what we wanted to build with Gemini, but nothing was working. By evening, we were exhausted and ready to quit. Whenever teams gathered in the common area and asked about our progress, I could only muster, “Our eyes are on the prize.” At first, it sounded hopeful; by the third time, it felt like a punch line.
Gemini kept returning the wrong data. Our grid-selection logic was behaving unpredictably. We scrambled to find another way for DOMinator to interact with the browser, but we didn’t have time to pivot now.
Meanwhile, other teams were already unwinding—there was even a “behind-the-scenes” karaoke session. We felt like we hadn’t made a scratch. So we walked downstairs to clear our heads. A cool breeze swept past the building, and we traded college stories as if the hackathon didn’t exist. We helped a few strangers find the train station, shared some memes, and simply breathed.
Ironically, the moment we stopped overthinking, the solution became obvious. After a quick cup of tea, we raced back upstairs. By about 3:10 am, all errors vanished, and DOMinator passed every test. This time, when I said, “Our eyes are on the prize,” we all meant it!
Meet the team:
Ishaan Shettigar
Sambhav Mahajan
Abhishek Yadav
Meherish Devaki
Aaryan Pandit (me!)
P.S. Why call ourselves the Seven when there were only five of us? Simple: we were assigned team number seven, so we leaned into the name 🤣.