My browser agent took 6 tries on Blinkit and 1 on a site it had never seen
> Built: 12 Sep 2026, solo, in one day at the SLAB Hackathon.
> Status: finished hackathon build. The repo has a prototype of the cached version described at the end.
My browser agent needed 6 attempts to get a clean price out of Blinkit. A few hours later it got one out of District, a site it had never touched before, on the first try, live, on stage.
The agent didn't get smarter in between. It got a notebook.
This is Basket Buddy, which I built solo in a day for the SLAB Hackathon (Self-Learning Agent Browser) at CMR Institute of Technology, Hyderabad, Track 05: Self-Learning Loops. It took second place. The idea is small, and I think it generalises to a lot of agent work: make the agent write down what it learned, in a form it can read back next time.
The task
Search a quick-commerce site for a product ("milk"), and extract the name, size, price and MRP of the results. Do it across several platforms so someone can compare a basket without opening three apps.
Every browser action ran through WebCMD sessions, one throwaway profile and session per platform. No raw Playwright or Selenium script drives anything directly.
Attempt counts, not vibes
Here is the actual log, attempts before a working, clean extraction:
| Platform | Attempts | What happened |
|---|---|---|
| Blinkit | 6 | Cold start. No strategy existed yet |
| BigBasket | 2 | Blocked. A real 404 from the site itself, likely bot detection. Correctly abandoned |
| Amazon | 1 | Reused a lesson from Blinkit |
| Zepto | 2 | URL worked first try; one fix for discount-badge noise |
| District | 1 | Transfer test. Zero prior exposure. Live |
The number I cared about was never "did it work". It was "did it need fewer tries because of what it learned before".
What Blinkit taught it
Blinkit was painful, and every bit of pain became a line in a file. This is the real strategy the agent wrote after cracking it:
{
"platform": "blinkit",
"search_url_pattern": "https://blinkit.com/s/?q={query}",
"product_card_selector_note": "No stable class names; find ADD buttons with no children, then walk up 3 parents to reach the card",
"extraction_note": "Parse price via regex on innerText (₹\\d+), not by selector; first ₹ match is price, second is MRP if discounted",
"gotchas": ["Homepage search box is a fake trigger link (href=/s/), not a real input, don't try to click+type it"]
}
Look at that gotchas line. The search box on the homepage looks like an input, but it is a link that opens the real search page. An agent that clicks and types into it fails in a confusing way, every time, forever, unless it remembers.
The lesson that transferred was not "Blinkit's selectors". It was more general: verify the direct search URL before touching the DOM. Amazon worked first try because of it. Zepto's URL worked first try because of it. District, a site with no strategy file at all, worked first try because the agent reached for the URL pattern first instead of poking at a search box.
Two kinds of memory
There are two separate memory layers here, and keeping them apart is what made this clean:
- Site structure memory belongs to WebCMD itself: explore a site once, reuse the map.
- Task memory is my layer on top: strategies/*.json, one file per platform, written after each run with the search URL pattern, selector notes and gotchas. What worked, what didn't, and why.
The loop is simple:
plan the run
-> site known? no -> explore cold, learn, write strategies/<site>.json
yes -> reuse the strategy
-> extract name, size, price, mrp
-> next run starts from what this run wrote
Knowing when to stop
BigBasket returned a consistent real 404 to the automated browser. The agent logged it and moved on.
That sounds like a failure in the table, but I think it is one of the most important rows. An agent that "learns" by retrying until something gets through is not learning, it is brute-forcing someone else's site. Abandoning a blocked platform is the correct behaviour, and it should be recorded as a result, not hidden.
The other guardrails were enforced in code, not described in a prompt:
- Every run stops at read-only extraction. No checkout, no payment, no account action.
- Human confirmation is required before anything irreversible.
- Throwaway profiles only. No cookies or credentials are committed to the repo.
What I'd change for a real product
Live scraping per visitor doesn't scale, and it would invite more BigBasket-style blocks on every platform. The repo has a prototype of the better pattern in server/: a background job is the only place the agent runs, on a schedule, and an Express server serves the cached results instantly.
The hard parts left are not code problems: prices vary by pincode because dark stores do, a real product should never ask a visitor for their Blinkit password, and scraping at scale raises terms-of-service questions that more engineering doesn't answer.
The takeaway
If your agent keeps making the same mistake on the same website, the fix is often not a better model or a longer prompt. It is a small, human-readable file the agent writes after each run and reads before the next one. You can open it, check it, and correct it. And when the agent finally cracks something, the lesson is still there tomorrow.
The repo, with the full learning log and every strategy file: victorisaacchinta-eng/basket-buddy
---
I wrote this with AI assistance, working from the repo and its learning log. Every attempt count above comes from that log.
Mentions
My browser agent took 6 tries on Blinkit and 1 on a site it had never seen > Built: 12 Sep 2026, solo, in one day at the SLAB Hackathon. > Status: finished hackathon build. The repo has a prototype of the cached version described at the end. My browser agent needed 6 attempts to get a clean price out of Blinkit. A few hours later it got one out of District, a site it had never touched before, on the first try, live, on stage. The agent didn't get smarter in between. It got a notebook. This is Basket Buddy, which I built solo in a day for the SLAB Hackathon (Self-Learning Agent Browser) at CMR Institute of Technology, Hyderabad, Track 05: Self-Learning Loops. It took second place. The idea is small, and I think it generalises to a lot of agent work: make the agent write down what it learned, in a form it can read back next time. The task Search a quick-commerce site for a product ("milk"), and extract the name, size, price and MRP of the results. Do it across several platforms so someone can compare a basket without opening three apps. Every browser action ran through WebCMD sessions, one throwaway profile and session per platform. No raw Playwright or Selenium script drives anything directly. Attempt counts, not vibes Here is the actual log, attempts before a working, clean extraction: | Platform | Attempts | What happened | |---|---|---| | Blinkit | 6 | Cold start. No strategy existed yet | | BigBasket | 2 | Blocked. A real 404 from the site itself, likely bot detection. Correctly abandoned | | Amazon | 1 | Reused a lesson from Blinkit | | Zepto | 2 | URL worked first try; one fix for discount-badge noise | | District | 1 | Transfer test. Zero prior exposure. Live | The number I cared about was never "did it work". It was "did it need fewer tries because of what it learned before". What Blinkit taught it Blinkit was painful, and every bit of pain became a line in a file. This is the real strategy the agent wrote after cracking it: { "platform": "blinkit", "search_url_pattern": "https://blinkit.com/s/?q={query}", "product_card_selector_note": "No stable class names; find ADD buttons with no children, then walk up 3 parents to reach the card", "extraction_note": "Parse price via regex on innerText (₹\\d+), not by selector; first ₹ match is price, second is MRP if discounted", "gotchas": ["Homepage search box is a fake trigger link (href=/s/), not a real input, don't try to click+type it"] } Look at that gotchas line. The search box on the homepage looks like an input, but it is a link that opens the real search page. An agent that clicks and types into it fails in a confusing way, every time, forever, unless it remembers. The lesson that transferred was not "Blinkit's selectors". It was more general: verify the direct search URL before touching the DOM. Amazon worked first try because of it. Zepto's URL worked first try because of it. District, a site with no strategy file at all, worked first try because the agent reached for the URL pattern first instead of poking at a search box. Two kinds of memory There are two separate memory layers here, and keeping them apart is what made this clean: - Site structure memory belongs to WebCMD itself: explore a site once, reuse the map. - Task memory is my layer on top: strategies/*.json, one file per platform, written after each run with the search URL pattern, selector notes and gotchas. What worked, what didn't, and why. The loop is simple: plan the run -> site known? no -> explore cold, learn, write strategies/<site>.json yes -> reuse the strategy -> extract name, size, price, mrp -> next run starts from what this run wrote Knowing when to stop BigBasket returned a consistent real 404 to the automated browser. The agent logged it and moved on. That sounds like a failure in the table, but I think it is one of the most important rows. An agent that "learns" by retrying until something gets through is not learning, it is brute-forcing someone else's site. Abandoning a blocked platform is the correct behaviour, and it should be recorded as a result, not hidden. The other guardrails were enforced in code, not described in a prompt: - Every run stops at read-only extraction. No checkout, no payment, no account action. - Human confirmation is required before anything irreversible. - Throwaway profiles only. No cookies or credentials are committed to the repo. What I'd change for a real product Live scraping per visitor doesn't scale, and it would invite more BigBasket-style blocks on every platform. The repo has a prototype of the better pattern in server/: a background job is the only place the agent runs, on a schedule, and an Express server serves the cached results instantly. The hard parts left are not code problems: prices vary by pincode because dark stores do, a real product should never ask a visitor for their Blinkit password, and scraping at scale raises terms-of-service questions that more engineering doesn't answer. The takeaway If your agent keeps making the same mistake on the same website, the fix is often not a better model or a longer prompt. It is a small, human-readable file the agent writes after each run and reads before the next one. You can open it, check it, and correct it. And when the agent finally cracks something, the lesson is still there tomorrow. The repo, with the full learning log and every strategy file: victorisaacchinta-eng/basket-buddy --- I wrote this with AI assistance, working from the repo and its learning log. Every attempt count above comes from that log.
webcmd gives browser agents a reusable map of pages, actions + pitfalls. before trusting a saved workflow: 1. check the live page 2. test changed controls 3. keep a fallback when memory fails remember navigation. re-check state. agentrhq/webcmd
Participated in the SLAB Hackathon organized by the Office of Student Welfare, with the theme “Browser Agents.” The hackathon challenged us to build an agent capable of solving a meaningful real-world browser workflow, with a strong focus on live reliability, technical depth, recovery, and practical usability. As a team, we explored and worked with WebCMD, a self-learning browser infrastructure for AI agents. WebCMD enables agents to interact with real websites through browser control while retaining navigational context to make subsequent browser automation more efficient and reliable. The experience gave us practical exposure to: 1. AI agents and browser automation 2. Real-world browser workflows 3. WebCMD and browser infrastructure 4. Agent recovery and reliability 5. Live testing and debugging 6. Building and presenting a working solution under time constraints Working on this challenge helped us understand that building an AI agent is not just about generating responses, but about enabling an agent to reliably interact with real-world environments and complete tasks. Team: Ankit Paul Nikunj barnwal Vaibhav Gupta Parth Chopra A special thanks to Jay Saadanana for organizing the hackathon and providing us with the opportunity to work on an interesting and emerging area of AI. GitHub: agentrhq/webcmd #SLABHackathon #BrowserAgents #AIAgents #ArtificialIntelligence #WebAutomation #WebCMD #Hackathon #AI #Automation #StudentInnovation
Codex can now remember how websites work instead of figuring them out every time Give Codex a browser task today. Give it the same task tomorrow. Why should it have to figure out the website all over again? webcmd is an open-source plugin that lets Codex keep what it learns. As it browses, it saves pages, actions, and navigation paths locally. Later runs can reuse that knowledge. You can ask it to: - Collect your bookmarks into a table. - Compare product prices. - Pull company details into a spreadsheet. The authors compared five browser tools on a 100-task benchmark using the same controller model and judge. Three results stood out: |Tool|Tasks passed|Estimated cost per passed task| |:-|:-|:-| |agent-browser|47|$0.554| |Playwright CLI|55|$0.441| |webcmd|67|$0.255| That’s 20 more tasks passed than agent-browser, at roughly 2.2× lower cost per passed task. Average agent turns dropped from 25.5 to 9.8—about 62% fewer turns. What you get: - Multiple browser steps executed in one program. - Page-state changes instead of another full page dump. - Useful navigation paths remembered locally. - Separate browser sessions for parallel agents. Example prompt: >Collect my recent X bookmarks and return the author, text, and URL for each one. The caveat: the authors published one run per tool. Costs are API-equivalent estimates, excluding the judge. webcmd completed 99 tasks, but 67 passed—completion and success aren’t the same thing. The interesting part isn’t just the benchmark. It’s letting browser agents reuse what they’ve already learned. Free and open source, with Codex setup instructions in the repo. Join Discord