Every Thursday at noon, Lifetime open-play slots would drop. The good Tuesday session was usually gone in seconds. I won twice in six weeks by doing the same ridiculous routine: refresh, tap, hope. That is not a workflow. That is a thumb race.

Hand-drawn booking race diagram comparing manual booking at about fifteen seconds with an agent booking flow at about four seconds.
The agent did not need to be clever. It needed to be fast, predictable, and gated before payment.

I built a small browser agent for the flow. It opens the booking page, filters for open play, finds the target session, checks spots, prepares the registration, then asks me before the paid confirmation click.

The conversation is intentionally simple:

Me: What's open Tuesday?
Agent: 6:30 PM intermediate has 4 spots. Book it?
Me: Yes.
Agent: Booked. $12 on the card on file.

The browser work behind that takes about four seconds on my setup. My manual flow was usually closer to fifteen seconds, and sometimes slower when the app hesitated. In my four-week test, the agent booked the session each time. That is a small sample, so I do not treat it like a benchmark. I treat it like a useful field test.

The useful part was not the model. It was the harness around the browser:

  • Semantic selectors: target the "Register" button by role and name, not by a brittle CSS class.
  • Structured observation: read page state as text and controls, not screenshots.
  • Confirmation gate: pause before anything that spends money.
  • Audit log: keep the action trail so a bad run can be replayed and fixed.

This is why I care about browser agents. Most services do not expose the exact API you want. They do expose a website. If an agent can use that website safely, with the same guardrails a careful human would want, a lot of everyday work becomes programmable.

BAP is the browser layer I built from this lesson: github.com/browseragentprotocol/bap.