Concurrent Flight Bookings During the Dubai Emergency

On March 4, 2026, I was doom-scrolling X and saw a post from @soupsranjan about how he was stranded in DXB and would’ve loved an agentic commerce system that could book him on multiple flights to maximize his chances of getting out.

So, I built it.

Simply put, this agent needed to:

1. Look for flights departing from DXB.
2. Filter for flights that show as "scheduled" or "on time" and ignore cancellations.
3. Be open to destinations worldwide, skipping GCC countries (including multi-stop).
4. Go to the website of the airline, enter all the booking details autonomously.
5. Navigate all the way to the payment screen.
6. Ask the user for their credit card details and enter them autonomously and safely.

The agent would need to do this at scale and make multiple bookings concurrently, whether that meant booking 4 flights across flydubai, Air India, IndiGo and Uzbekistan Airways.

The system was designed as a split pipeline. A deterministic DXB discovery layer hits Dubai Airport's server-rendered departures endpoint, paginates in real time, retries failures, and normalizes duplicate rows.

That raw feed is then passed through a rule engine that removes cancelled flights, filters out Emirates and GCC routes, excludes itineraries with GCC stopovers, and narrows the search window to the next 48 hours. At this point, we have already compressed a noisy public departures board into a small set of viable “escape” routes.

Each action runs as its own background job. Scrape, booking, and payment are all executed asynchronously on the server, while progress streams back to the UI over SSE. That architecture made it possible to conduct multiple booking attempts in parallel and give the operator live feedback.

Browser Use was used for the irreducibly human parts of the workflow: navigating airline sites, searching live inventory, filling passenger details, and bringing us to the payment screen.

Stack: Next.js, TypeScript, Tailwind, SSE, zod, cheerio, browser-use-sdk

The next step would be to deploy this live with explicit operator controls. That means a real job dashboard, authentication, rate limits, spend caps, and a hard human checkpoint before any payment is submitted.

To scale it, I would push the discovery and booking layers further apart. Discovery should continuously build a pool of viable routes, while execution workers consume that pool with concurrency controls, retries, and stronger observability.

The main thing I learned is that agentic commerce works best when the browser agent is the last mile, not the whole system. The interesting part isn’t getting an agent to click buttons, it is building the infra around it so the right actions happen quickly, safely, and at scale.