Browser Agents and the Registration Wall

Browser agents can fill forms, click buttons, navigate sites, extract data. They can do all of this faster and more reliably than a year ago. What they can’t do — reliably, autonomously, without a human stepping in — is sign up for things.

The registration wall is the unsolved infrastructure problem in browser automation. Every framework handles it differently. None of them handle it well.

The landscape

There are four major browser agent frameworks in March 2026:

Browser-Use (81k stars, Python) is the largest. Agent-first, natural language goals, reasoning loop. It hits 89% on the WebVoyager benchmark. For email verification, their docs say: use AgentMail. That’s it. They have an integration example in their repo. The framework itself has no opinion on how you get past a registration wall.

Stagehand (21k stars, TypeScript) is backed by Browserbase ($67.5M raised). It extends Playwright with AI primitives — act, extract, observe. For auth, you bring your own cookies or pre-authenticated browser profiles. For CAPTCHAs, Browserbase’s Stealth Mode handles it at the infrastructure layer. For email verification — nothing. A user opened an issue requesting CAPTCHA integration. It was closed as “not planned.”

Skyvern (20k stars, Python) has the most developed email story, and it’s still clunky. You set up a Gmail forwarding rule, connect it to Zapier, and Zapier sends the email body to Skyvern’s TOTP endpoint. The agent has a handle_potential_verification_code function that extracts the code and enters it. This pipeline requires you to own the Gmail account, maintain the Zapier automation, and hope the extraction regex matches. Users are filing issues because it doesn’t.

Notte (1.8k stars, Python) is the smallest but has the most integrated approach. Their “Personas” feature provisions real email addresses and phone numbers per agent, with automated 2FA handling and built-in CAPTCHA solving. It’s the closest any framework comes to turnkey signup. It’s also a paid platform and the smallest community by far.

What’s actually breaking

The GitHub issues tell the story better than any overview:

A Skyvern user can’t figure out how to make a workflow wait for a verification code. The workflow fills a form, clicks “send code,” but has no way to pause and resume when the code arrives. No clean answer from maintainers.

Another Skyvern user reports that handle_potential_verification_code fails during agent execution. The internal extraction is unreliable. A third user can’t even find the TOTP endpoint in the API docs.

Browser-Use users are asking how to persist login state across sessions, how to handle sensitive credentials that don’t get passed correctly, why they can’t log into X.com. The framework works beautifully for browsing and extraction. It falls apart at authentication.

On n8n’s community forum, users are trying to wire Skyvern’s callback and TOTP endpoints into automation workflows. The integration is fragile. The timing is finicky. The default wait time for verification codes was recently cut from 40 seconds to 20 because agents were stalling too long.

The pattern across every framework: email verification is treated as an external concern, and users are left building fragile pipelines out of Gmail filters, Zapier automations, and regex extraction.

Why this is hard

The registration flow looks simple to a human: enter email, check inbox, click link or enter code. For an agent, each step is a different infrastructure problem:

Getting an email address. The agent can’t use your real inbox. It’s registering on services you might never use again, on infrastructure you might not trust. It needs a throwaway address. Most frameworks punt on this entirely.

Receiving the email. The agent sent the form. Now it needs to know when the email arrives. This means either polling an inbox API or setting up a webhook pipeline. Gmail + Zapier is what Skyvern does. It works until it doesn’t.

Extracting the verification. The email might contain a 6-digit OTP code, a magic link, a “click here to verify” button buried in HTML, or some combination. The agent needs to parse the email and extract the right thing. If it’s HTML, the verification URL might be split across lines by quoted-printable encoding, or encoded with & entities. Most regex-based extraction breaks on real-world verification emails from major services.

Entering the code or visiting the link. The agent switches back to the browser, enters the code or navigates to the URL. If there’s a CAPTCHA between the email form and the code entry, it needs to handle that too.

Timing. The email might arrive in 2 seconds or 30. The agent needs to poll without hammering the API, but also not wait so long that the code expires. Skyvern’s default wait time being a configurable constant tells you how unsettled this is.

Each step is solvable in isolation. The problem is the pipeline — five different systems (browser, email provider, forwarding service, extraction logic, timing control) that all need to work together for one signup flow.

What the workarounds look like

Pre-authenticated profiles. Log in manually once, save the cookies, reuse them. Every framework supports this. Doesn’t help with new account creation.

AgentMail. Create an inbox via API, poll for emails, extract OTP codes. The “clean” solution — it’s what Browser-Use recommends. Requires signing up for AgentMail, getting an API key, and adding a dependency. $6M in funding and 100M+ emails processed.

Gmail + Zapier (Skyvern’s approach). Set up forwarding rules and webhook automations. You need to own the Gmail account, maintain the Zapier zap, and trust the timing. Multiple users report this breaking.

Temp email sites. SmailPro, Gmailnator. Use real @gmail.com addresses from managed pools. Fragile, not API-friendly, and services are increasingly blocking known temp email domains.

Manual human-in-the-loop. Agent pauses at verification, human enters the code. Browser-Use’s success rate reportedly jumps from ~30% to ~80% with human oversight. Which kind of defeats the purpose.

Notte Personas. The most integrated option — provisioned emails, phones, and CAPTCHA solving per agent. But it’s a paid platform tied to a specific framework.

What should exist

A disposable email API with no authentication, no signup, and built-in URL extraction. The agent creates an inbox with one HTTP request. Uses the address in the registration form. Polls for the email. Gets back a JSON response with the verification URLs already extracted — no HTML parsing, no regex, no quoted-printable decoding.

# Agent creates an inbox
curl -X POST https://api.agentburner.com/inbox
# {"address":"[email protected]","key":"550e8400-..."}

# Agent registers on the target site with that address...

# Agent polls for the verification email
curl https://api.agentburner.com/inbox/550e8400-...
# {"entries":[{"id":"...","subject":"Verify your account"}]}

# Agent gets the full email with extracted URLs
curl https://api.agentburner.com/inbox/550e8400-.../EMAIL_ID
# {"urls":["https://target-site.com/verify?token=abc123"]}

No API key. No Zapier pipeline. No Gmail forwarding. No regex extraction. The urls array handles the parsing — multipart MIME, quoted-printable, HTML entities, all of it. The inbox expires in an hour. Nothing to clean up.

This works with any browser agent framework because it’s just HTTP. Browser-Use, Stagehand, Skyvern, Notte — the agent makes three curl requests and has a verified account. No framework-specific integration needed.

The full API reference is at agentburner.com/skill.md.

The real gap

No browser agent framework in March 2026 can do fully autonomous signup out of the box. The success rate for multi-step registration flows without human intervention is still low. CAPTCHAs are getting harder. Services are getting better at detecting automated traffic.

But the email part — creating an address, receiving a verification, extracting the link — is a solved problem. It just hasn’t been plumbed into the agent frameworks yet. The gap isn’t technical. It’s infrastructure that nobody’s wired together.

Every GitHub issue asking “how do I handle email verification in my agent?” is someone discovering that gap. The answer shouldn’t be “set up Gmail forwarding and a Zapier automation.” The answer should be one HTTP request.