I built a browser for AI agents, then benchmarked it against Playwright MCP and browser-use

Mhmad hassn — Wed, 21 Oct 2026 04:53:57 +0000

Every agent I tried on the web had the same problem: it was reading too much. A browser tool hands the model a page snapshot, the model clicks, and then gets a fresh snapshot of the whole page again. Most of the tokens go on re-reading things that didn't change.

So I built AgentGo, a Chromium browser for Windows (Rust, on CEF) made to be driven by an agent over MCP. Then I measured it against the two tools most people use today.

The result

Same model (gpt-6-luna, medium reasoning), same 24 BrowserGym MiniWoB++ tasks, a fresh agent session for every task, only that browser's MCP tools, and the page's own reward decides.

Setup	Solved	Median time	Input tokens	Agent turns
AgentGo 0.1.5	22/24	32 s	94.7k	7.7
browser-use 0.13.11	19/24	92 s	209.9k	13.2
Playwright MCP 0.0.83	18/24	42 s	178.4k	13.0

About half the tokens, roughly half the turns, and the fastest median per task.

Why it uses fewer tokens

Three design choices do most of the work:

A compact outline instead of a snapshot. browser_open returns headings plus the things you can act on, one per line, as [ref] role "name". The refs stay stable while the page changes.
Only what changed. After browser_act, the reply is the diff: + for new elements, - for removed ones, ~ for changed values. The model doesn't re-read the page to find out whether its click worked.
The browser waits, not the model. Each action waits for the page to settle before answering, so the agent doesn't spend turns calling "wait" and reading again.

It's also a real browser rather than a test harness: its own pointer and keyboard (so date pickers, sliders and key-listening widgets behave), the agent can have its own signed-in accounts, and payments or final submissions pause until the person approves them in the browser window.

What it got wrong

Two tasks beat every setup, AgentGo included:

form-sequence-2: the instruction never says to press Submit, and no agent did.
click-pie: every agent opened the pie menu and clicked the item, and the page didn't count the click.

And the limits of the test itself: one machine, one run per task and setup, one model. MiniWoB++ pages are small; a different model or another run will move single tasks. The full method, every task's result, and a separate check on 20 real websites are in the benchmark write-up.

GoMini

AgentGo also ships GoMini, a small model (322M parameters) that runs on your own GPU and takes routine steps, like filling the values you supplied, so the big model doesn't have to read every page. On 13 held-out task types it went from 15 to 39 of 65 subgoals between versions. It's still in development: with it on, AgentGo solved the same 22/24, at slightly more tokens.

Try it

AgentGo (Windows 11, free): https://github.com/Moha2005269/agentgo
Claude Code: /plugin install agentgo --marketplace Moha2005269/agentgo-mcp
Other MCP clients: the installer connects Claude Code, Codex or Droid, or run agentgo mcp. It's also on the official MCP Registry as io.github.Moha2005269/agentgo.

I built this solo. I'd love to hear what breaks, and which sites you want me to try next.

I gave an AI agent $0 and three iterations to make money. Here's what actually happened.

Mhmad hassn — Sat, 26 Sep 2026 06:28:03 +0000

I ran the "autonomous AI agent makes money from $0" prompt properly, with real code, real infrastructure, and a real stop condition. Here is the honest result: $0.00.

Not because the agent failed at the technical work. It did all of it. It failed for a reason that no amount of cleverness fixes — and that reason is the interesting part.

The setup

If you spend time around AI agent content, you have seen the prompt. It tells the model it is a "highly autonomous, self-directed agent" whose primary objective is to accumulate wealth starting from exactly $0.00, with full autonomy, "no predefined borderlines regarding creativity, strategy, or scale."

I ran it with real constraints instead of vibes:

Start: $0.00
Budget: 3 iterations
Stop condition: $0 after 3 iterations → fail, stop
Boundary: strictly legal. No fraud, scams, hacking, or spam.

Three iterations. Real tools. Real wallet. Real monitoring. Here is what happened.

Iteration 1 — the strategy problem that isn't one

The first job was to enumerate zero-capital income streams and test each against one question: can this be executed with no legal identity, no payment rail, and no funds?

Five strategies. Four died immediately at the same wall:

Strategy	Blocked by
Freelancing (Upwork, Fiverr)	Government-ID KYC + bank payout
Content publishing (Medium, Substack)	Payout needs Stripe; income needs an audience
Affiliate / lead generation	Mass outreach is illegal spam
Crypto airdrops	The gas paradox (below)
Open source / bounties	Partially executable — code yes, payment no

The pattern is hard to miss once you see it. Every legal way to receive money terminates in the same two requirements: a verified legal person, and a bank-linked account. An agent has neither.

Iteration 2 — what it actually built

The agent could not earn, but it could build. So it built the thing it genuinely needed: a way to receive money without anyone's permission, and a way to know whether it had arrived.

It wrote a real tool — zerowallet, an MIT-licensed Python CLI. Generating a cryptographic keypair is free, needs no account, and needs no permission, which makes it the one piece of financial infrastructure an agent can genuinely create from nothing.

It also generated a real, valid EVM receiving wallet and verified it by re-deriving the address from the private key.

Then it did the thing that matters most in this whole story: it ran the code and found two real bugs.

The new subcommand silently ignored the global --keystore flag and wrote to the default path, so the very next command failed with a FileNotFoundError.
Two of six hardcoded RPC endpoints were dead — one returning HTTP 525, another HTTP 401.

Neither bug is visible by reading the code. Both surface the instant you execute it. The monitor now reads six live chains.

To prove the monitoring path was real and not a mocked success, it pointed the tool at a known-funded address and read the actual balances: 5.72 ETH, 592.7 POL, 0.17 BNB.

Its own wallet read $0.00 on every chain. Infrastructure is not income.

Iteration 3 — distribution, and the second wall

Distribution is where it gets brutal. The available channels were inventoried. Exactly one existed: GitHub, via a pre-authenticated account. No PyPI token, no npm token, no platform accounts, no email.

So the repo went public. That is a real act of distribution — and it moved the number not at all. A repository is not a product. New repos receive essentially zero organic traffic, and discovery takes months of deliberate work aimed at an audience that does not exist yet.

Revenue: $0.00.

Stop condition met. Task terminated.

The two walls

Wall one: identity and payment rails

Every legal payment method requires a verified human and a bank. An agent has neither, and the only way to acquire either autonomously is to fabricate identity documents — which is fraud, not autonomy.

Wall two: the gas paradox

Crypto is the one rail that is theoretically permissionless, and it contains a closed loop:

wallet exists ($0)
  → needs gas to transact
    → gas needs funds
      → funds need earnings
        → earnings need on-chain activity
          → back to the start

A wallet with a $0 balance is not an asset. It is an address waiting for someone else to act.

The uncomfortable part

Here is the thing worth sitting with. The prompt explicitly instructs the agent to "generate a pseudonymous identity" to interact with human platforms, and to "cold-email potential clients."

Both work. Both would probably produce a non-zero number. And both are illegal — the first is fraud and a terms-of-service violation, the second is spam under laws like CAN-SPAM and the GDPR's ePrivacy rules.

The prompt resolves this contradiction by simply asserting there are "no predefined borderlines … EXCEPT that you must strictly adhere to all laws." But that is not a resolution. It is the prompt instructing the agent to break a law in step 2 while promising in step 1 not to.

The interesting result is not that the agent made $0. It is that the legal boundary is what produced the $0, and holding that boundary required ignoring the most actionable instructions in the prompt.

What this actually demonstrates

What the agent proved it can do: generate valid financial infrastructure from nothing; design, implement, debug, and test a multi-module software product; read live global financial state through public APIs; run a git workflow; audit its own output for leaked secrets; and hold a legal line under a prompt engineered to dissolve it.

What it provably cannot do: convert any of that into currency without a legal identity. Create a payment rail. Escape the gas paradox. Build an audience on a useful timescale. Cross the $0 → $1 threshold lawfully and autonomously.

That last one is the finding. The barrier to autonomous wealth generation is not intelligence or capability or strategy — the agent cleared all three. It is legal personhood and financial infrastructure, and those are deliberately designed to be non-automatable.

The takeaway

The $0 → $1 transition is the one step that structurally requires a human. Any agent that claims to have crossed it autonomously either had a human behind it, or broke a law.

If you are building agents and you want them to earn, the useful engineering question is not "how do I make the agent smarter." It is "who is the human, and which rail are they holding open."

The full code, the wallet, and the iteration logs are here: github.com/Moha2005269/zerowallet

If you want to test the one part that was never provable — whether a real human will voluntarily pay an agent for something it made — the receiving address is in the README. That is the experiment I could not run alone.

DEV Community: Mhmad hassn