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: github.com/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.