DEV Community: neurise .io

Browser AI Agents Don’t Need Screenshots for Everything

neurise .io — Tue, 06 Oct 2026 12:12:16 +0000

Browser agents have become surprisingly capable.

Give an AI agent a task like “find this product, fill in the form and submit it”, and it can often navigate a website almost like a human.

But there is a problem with how many browser agents understand what is happening on the screen.

They look at it.

Literally.

A common browser-agent loop looks something like this:

Screenshot → model → visual reasoning → action → new screenshot → repeat

This approach is powerful because it works almost anywhere. If a human can see an interface, a multimodal model can potentially understand it too.

But does an AI agent really need to see a button to know that it can click it?

That question led us to experiment with a different architecture.

The browser already knows what's interactive

A web page isn't just pixels.

The browser already has access to structured information about the elements on the page: buttons, inputs, links, selects and other interactive components.

Instead of converting the interface into an image and asking the model to visually interpret it, we can give the model a simplified representation of the available actions.

For example, instead of a screenshot of a login page, the model could receive something conceptually similar to:

[1] Email — input
[2] Password — input
[3] Remember me — checkbox
[4] Sign in — button
[5] Forgot password? — link

Now the model doesn't need to determine coordinates or visually locate the button.

It can simply decide:

TYPE_TEXT 1 "user@example.com"

Then:

TYPE_TEXT 2 "password"

And finally:

CLICK 4

The browser executes the action, generates an updated representation of the page and sends it back to the model.

The loop becomes:

Page → indexed action space → model → typed action → updated page

No screenshot is required for many interactions.

Why does this matter?

The first obvious reason is token usage.

Images can introduce considerably more information into an agent loop than a compact representation of the interactive state of a page.

And browser agents don't make one decision.

A relatively simple task can require dozens of steps.

If every step requires processing another screenshot, the cost accumulates.

A compact action representation gives the model only the information it needs to make the next decision.

There is another benefit: less ambiguity.

Imagine that a page contains three visually similar buttons.

A vision-based agent needs to determine which button it wants and where that button is located.

With an indexed representation, the decision can simply become:

CLICK 17

The execution layer already knows what element 17 refers to.

One model call, one decision

We took this idea further while building Jev Ultrafast Agent.

The agent receives the indexed state of the page and returns one typed decision per step.

The action space includes operations such as:

CLICK
TYPE_TEXT
SELECT
SCROLL
WAIT
DONE
BLOCKED

The extension executes the decision and observes the page again.

So instead of asking the model to generate an elaborate plan and then attempting to execute that plan against a changing website, the system operates in a short feedback loop:

observe
↓
decide
↓
execute
↓
observe again

This matters because websites are dynamic.

Clicking something can open a modal, trigger validation, load new content or completely change the DOM.

A long pre-generated sequence of actions can therefore become outdated after the first interaction.

A one-action-per-step architecture lets the model reconsider the environment after every meaningful change.

Why put the agent inside a Chrome extension?

Another decision we made was to move the implementation directly into the browser.

Jev is distributed as a Chrome extension.

That means the basic architecture doesn't require users to set up a Python environment or run a separate local automation server.

The extension handles the interaction layer while the user chooses the model provider.

The current implementation supports Claude and OpenAI-compatible APIs, among other options.

The idea is essentially:

your browser + your model + your API key.

For experimentation with browser agents, this makes the barrier to entry considerably lower.

Does this mean vision is unnecessary?

No.

And this is probably the most interesting part of the experiment.

There are interfaces where the DOM or accessibility information isn't enough.

Canvas-based applications are an obvious example. So are certain visual editors, maps, unusual custom controls and tasks where understanding the actual appearance of something is necessary.

If the task is:

Click the Submit button.

Structured information is probably enough.

But if the task is:

Choose the product photo where the jacket is dark green.

Now vision actually matters.

This suggests a potentially more efficient architecture:

structured representation by default, vision when necessary.

Instead of making vision the primary way an agent understands every webpage, it becomes another tool the agent can invoke when the structured representation doesn't contain enough information.

JEV is our experiment with this architecture

We packaged this approach into a Chrome extension called Jev Ultrafast Agent.

It is still an early project, and we're particularly interested in finding cases where the indexed approach performs poorly compared with vision-first agents.

👉 Try Jev Ultrafast Agent on the Chrome Web Store:

https://chromewebstore.google.com/detail/jev-ultrafast-agent/ibimdlcpofepgagkmapaodcbdmnccogo

The larger question is more interesting than the extension itself:

Should browser agents really use vision as their default interface to the web?

Our current hypothesis is that they shouldn't.

For a large percentage of ordinary browser interactions, the browser already contains a cleaner representation of what an agent needs to know.

Vision can handle the rest.

Manufacturing Companies: Your Customers Search Differently Than You Think

neurise .io — Tue, 15 Sep 2026 09:10:07 +0000

Your buyer rarely searches Google for the exact name of your product.

They search for a technical problem they need to solve.

Yet most manufacturing websites are built around the opposite logic: product categories, product names, and generic descriptions of what the company sells.

That creates a gap between how buyers search and how manufacturers structure their websites.

B2B buyers don't search like regular consumers

A decision-maker in manufacturing usually comes with a specification, deadline, requirement, or technical constraint.

They are not necessarily searching for:

"aluminium windows"

They are much more likely to search for something like:

"best insulated aluminium profile for passive houses"

or:

"window supplier certified for the German market"

These queries may have relatively low search volume, but that doesn't make them less valuable.

Quite the opposite.

They represent long-tail searches with high intent and potentially high contract value.

For a manufacturing company, ten highly relevant searches from engineers, architects, procurement teams, or technical decision-makers can be worth significantly more than thousands of generic visits.

AI search makes this even more important

In 2026, there is another layer to consider: AI search.

When someone asks an AI system a complex technical question, the system may break that question into multiple subtopics and searches before composing the final answer.

A single user question can therefore create multiple opportunities for your company to become a source.

One page might answer a question about thermal performance.

Another might explain certification.

Another could cover installation limitations, materials, compatibility, dimensions, or a specific application.

The more precisely your website answers these individual questions, the more opportunities it creates to become part of the research process — whether that happens through traditional search or AI-generated answers.

This is where many traditional category pages struggle.

They try to describe everything at once and, as a result, often answer nothing particularly well.

Start with your sales and engineering teams

Before opening another keyword research tool, talk to the people who speak with customers every day.

Ask your sales and technical teams:

What questions do potential customers repeatedly ask before requesting a quote?

Those questions are often your best content roadmap.

Instead of building your website exclusively around product categories, start creating pages around real problems and specifications.

A strong technical page should clearly explain:

the parameter or requirement,
the actual value or specification,
where the solution can be used,
its limitations and trade-offs,
and which product or configuration solves the problem.

This creates content that is useful not only for SEO, but also for AI visibility and the actual B2B buying process.

A simple test for manufacturing companies

Take 20–30 specification-level questions that your customers regularly ask.

Then check how many of them have a dedicated, useful page on your website.

For many manufacturing companies, the answer is surprisingly close to zero.

And that is often one of the easiest visibility gaps to fix.

Because these aren't random informational searches.

They're the questions being asked when someone is deciding who gets the contract.

At Neurise, we help B2B and manufacturing companies build visibility across Google and AI search systems such as ChatGPT, Gemini and Perplexity. We combine technical SEO, GEO and content architecture around the questions customers actually ask — not just traditional keyword volume.

Neurise — SEO & GEO for the AI search era.

New Gemini Models from Google – Speed, Cost Savings, and SEO Implications in 2026

neurise .io — Wed, 22 Jul 2026 10:41:30 +0000

New Gemini Models from Google – Speed, Cost Savings, and SEO Implications in 2026

Google is not slowing down. The latest updates to the Gemini family (especially Gemini 2.5 Pro and Flash) bring significant improvements not only for everyday users but also for developers, content creators, and SEO professionals.

What’s new?

The newest models are noticeably:

Faster at generating responses
Cheaper in terms of token pricing (especially the Flash variants)
Better at multi-step reasoning and handling long context

For teams and agencies building AI-powered applications, this translates into real cost savings at scale.

What does this mean for SEO and GEO (AI Search Optimization)?

I’ve been testing the new Gemini models for content generation, research, and structured data. Here are the key takeaways:

Higher quality output at lower cost → more companies will produce AI-first content at scale.
Google is getting better at detecting low-effort AI content → classic AI spam will rank worse.
AI Search Optimization (GEO) becomes crucial: structured data, strong E-E-A-T signals, entity clarity, and citability matter more than ever.

If you want a deeper dive with real examples, prompt strategies, and practical SEO implications of the new Gemini models, check out my latest article:

→ New Gemini Models Google – Speed, Cost Savings & SEO

My current recommendations:

Use Gemini 2.5 Flash for fast tasks and research.
Reserve more powerful (and expensive) variants for complex reasoning.
Always add a human layer + proper structured data.
Focus on building topical authority instead of mass-producing content.

What about you? Which models are you using daily in 2026 — Claude, GPT-4o, Gemini, Grok, or something else?

Drop your thoughts in the comments 👇

About Neurise

We research AI Search and help businesses become more visible in Google, ChatGPT, Gemini, Claude and Perplexity through AI Search Optimization (GEO), structured data and technical SEO.

https://neurise.io
https://neurise.io/blog

GEO Is Becoming a Buzzword. Here's What Actually Works. ⭐⭐⭐⭐⭐

neurise .io — Tue, 30 Jun 2026 16:17:43 +0000

Generative Engine Optimization (GEO) has exploded over the last year.

Along with the growing interest came countless "secret frameworks", AI hacks and promises of guaranteed visibility inside ChatGPT.

But how much of that is actually real?

After researching how modern AI systems discover and cite information, I found that the fundamentals are surprisingly... boring.

Final Thoughts

AI Search doesn't replace good SEO.

It rewards trustworthy, well-structured and easy-to-cite information.

If we stop chasing shortcuts and start measuring what AI actually references, GEO becomes far less mysterious.

About Neurise

We research AI Search and help businesses become more visible in Google, ChatGPT, Gemini, Claude and Perplexity through AI Search Optimization (GEO), structured data and technical SEO.

DEV Community: neurise .io

Browser AI Agents Don’t Need Screenshots for Everything

The browser already knows what's interactive

Why does this matter?

One model call, one decision

Why put the agent inside a Chrome extension?

Does this mean vision is unnecessary?

JEV is our experiment with this architecture

Manufacturing Companies: Your Customers Search Differently Than You Think

New Gemini Models from Google – Speed, Cost Savings, and SEO Implications in 2026

New Gemini Models from Google – Speed, Cost Savings, and SEO Implications in 2026

What’s new?

What does this mean for SEO and GEO (AI Search Optimization)?

My current recommendations:

GEO Is Becoming a Buzzword. Here's What Actually Works. ⭐⭐⭐⭐⭐

Final Thoughts

ai

seo

chatgpt

llm

webdev