DEV Community

Cover image for Browser Agents Weren't Built for the Web They Use: Why We Built Wizang EYES

Browser Agents Weren't Built for the Web They Use: Why We Built Wizang EYES

Over the past year, everyone has tried to build autonomous browser agents. Most of them break in production.

If you’ve built agents using Puppeteer, Playwright, or Selenium combined with an LLM, you know the frustration:

  1. Vision-based perception — sends high-res screenshots to GPT-4o. It’s slow (1.5s+ per frame), costs \$0.05–\$0.15 per step, misses offscreen state, and fails when bounding boxes jitter.

  2. ARIA snapshots - dump massive 20,000+ token accessibility trees into the context window. Your prompt overflows, costs explode, and 90% of the payload is DOM noise that has zero interactive value.

  3. Raw HTML extraction - crashes token budgets instantly and chokes the model on CSS classes, SVG paths, and minified scripts.

> The web was engineered for human eyes and browser rendering engines. “It was never designed for machine perception.”

We spent the last few months asking a fundamental question:

What is the minimal, deterministic mathematical representation of a webpage that an AI agent needs to act with 99.9% reliability?

The answer became Wizang EYES.

The Perception Problem in Numbers

When an AI agent navigates a page like Hacker News or Amazon:

1. Raw HTML: ~150,000 characters (~35,000 tokens).
2. ARIA Accessibility Tree: ~24,000 tokens of nested role hierarchies.
3. Wizang EYES Semantic Map: 1,338 tokens containing exact (x, y) click coordinates, semantic roles (button, link, input), and normalized visible text.

That is an 80% to 94% token reduction with zero loss of interactive fidelity.

{
"url": "https://news.ycombinator.com",
"element_count": 29,
"tokens": 1338,
"elements": [
{ "t": "link", "tx": "Hacker News", "x": 130, "y": 12 },
{ "t": "input", "tx": "Search", "x": 48, "y": 457 },
{ "t": "button", "tx": "Submit", "x": 471, "y": 12 }
]
}

Machine-Native Perception Architecture

Wizang EYES is not another browser wrapper or scraper. It is infrastructure:

1. Deterministic Coordinate Grounding: Every interactive element is mapped to page-level viewport coordinates (x, y) in a single sub-20ms JS extraction pass.

2. Multi-Frame Layout Normalization: Iframes, shadow DOMs, and nested layers are normalized into a unified spatial frame.

3. Sub-Millisecond Context Recycling: A warm pool of headless Chromium instances recycles execution contexts to eliminate cold-boot penalties.

If you are building browser agents, web automation workflows, or autonomous QA testers, we’re opening up early access for design partners.

API Docs: Here

Top comments (1)

Collapse
 
alexshev profile image
Alex Shev

Browser agents need perception that matches the task, not just DOM access. The hard part is knowing what changed visually, what is actionable, and what the agent should ignore. A web page is both interface and evidence, and most agents still blur those two roles.