How Hamlet checks 2,500 local government meetings every day with Browserbase

TL;DR: Hamlet is building toward national coverage of local government meetings, with a target of 19,000 cities, 3,000 counties, and 80,000 special districts. It runs browser agents built with the Stagehand SDK on Browserbase to find agendas and meeting videos on thousands of one-off government website. Moving from manual collection to Browserbase cut Hamlet's costs by about 70%, and the switch paid for itself in five months.

What Hamlet does

Hamlet turns local government meetings into data that businesses can use. It captures each meeting's agenda and video, transcribes it, identifies the speakers, and records how every member voted. Customers, including data center developers, real estate developers, and political action committees, use that data to spot chances to do business with a city or to move faster through permitting and entitlements.

Jeff Hui, a founding engineer at Hamlet, owns the first step: finding each meeting and capturing its agenda and video before the rest of the pipeline takes over.

Thousands of government websites, no two alike

There's no standard for how local governments publish their meetings. A few use a structured vendor platform, but many run their own sites, and a single city can split its meetings across two or three vendors. That means Hamlet can't build one integration and reuse it everywhere. Each site needs its own approach to find the agendas, videos, and rosters, and every new location Hamlet adds works a little differently from the last. "In some ways, it represents the early internet," Jeff says. "Every location does things its own specific way."

Hamlet also has to get there in time. Some governments post a meeting video only because they're legally required to, then take it down after 48 hours. The next meeting replaces it. Agendas need to be captured before the meeting happens, and some video archives update nightly. "If you miss it one day, you might actually just miss the meeting," Jeff says.

Why people and hand-written scripts couldn't keep up

Hamlet tried to build everything in house. In the early days the team paid people to visit sites and find new agendas. "If you hired thousands of people, maybe you could do this sustainably," Jeff says, "but it would be their full-time jobs to check all this." Both approaches broke on the long tail. Every fix covered one government's site, and hundreds more had quirks of their own. Jeff calls it death by the long tail: "The common cases are pretty straightforward. The edge cases are always bespoke."

Backfill was the most manual part. When a customer needed history for a new location, someone on the team downloaded every agenda PDF and meeting video by hand.

Hamlet needed coverage that scaled at a reasonable cost, and a system flexible enough to handle the obscure cases that broke hand-written scripts.

How Hamlet uses Browserbase

Hamlet checks about 2,500 locations every day. Most don't offer an API or use a standard meeting vendor, so Hamlet reaches them through Browserbase, running up to 19,000 browser sessions a day.

For the sites with the least structure and the hardest access, Hamlet runs browser agents built with the Stagehand SDK. Each agent opens a real browser on a government site and works through it the way a person would. It finds the governing bodies, locates the agendas and meeting videos, picks up related attachments, and identifies the current council or board members. Because the agents read the page instead of following fixed selectors, they keep working when a city moves its meeting archive. Hamlet moved to Stagehand from another browser agent framework that used LLM calls inefficiently, and the switch cut those costs by about 60%.

For the most complicated sites, Jeff writes site-specific guidance into the prompt, describing how a particular government's site has to be operated to reach its meetings. Then a Browserbase browser handles the rest, including the form submissions and dated layouts that a plain HTTP request can't get through.

The same setup handles backfill. When a customer needs two to four years of history on a new location, Hamlet points its agents at a set date range and processes those meetings in a few days, so the data is ready during the customer's onboarding week.

The pipeline runs in three steps: Browserbase browsers driven by the Stagehand SDK → agendas, videos, and rosters → Hamlet's transcripts, speakers, and votes.

What it adds up to

Hamlet can watch the long tail of American local government on a daily cadence and fill in its history on demand.

• About 70% lower cost than collecting meetings by hand, with payback in five months
• About 60% lower costs after switching to Stagehand from another browser agent framework
• Up to 19,000 browser sessions a day, checking about 2,500 locations
• A coverage target of 19,000 cities, 3,000 counties, and 80,000 special districts
• Hundreds of Stagehand agent runs a day on the sites with the least structure
• Years of historical meetings backfilled in days, within a customer's onboarding week
• Runs that keep working when a government site changes its layout, with site-specific guidance for the hardest cases

Sunil calls American public meetings maybe the largest source of original content in the country. Keeping up with them across thousands of fragmented sites depends on reliable browsers.

What's next

Hamlet is rolling range-based ingestion out to every location it supports and expanding toward the long tail of America's local governments. Hamlet also wants its browser agents to scan a new government site, identify its meeting vendors, and choose how to ingest it on their own.

If your agents need to work across thousands of sites with no API, talk to our team. Give your agents the web.