Opera Neon and the Dawn of the Agentic Browser

Breaking: the browser now does the work

On September 30, 2025 Opera began shipping Neon, its long-teased agentic browser. The headline is not another chatbot living in a sidebar. Neon turns the browser itself into a controlled environment where an agent can read the Document Object Model, navigate tabs, fill forms, run code, and return results inside a workflow the user can see and intervene in. Opera’s framing is explicit in its Opera release note for Neon: the browser is built to act for you, locally, inside your current session using a feature called Neon Do, and it packages that behavior into reusable Cards and multi-step Tasks.

If you want a mental model, think of today’s browsers as notebooks and tab managers. Neon recasts the browser as a workbench with power tools. You still write and read, but the bench can also clamp the workpiece, measure, cut, and hand you the finished part. The important shift is not the assistants. It is that the work now happens where your identity, cookies, permissions, and muscle memory already live.

What Opera actually shipped

Neon Do: an on-device execution loop

Runs inside your current browser session and uses your live logins. You do not hand credentials to a cloud robot. Neon Do reads page structure, clicks, scrolls, selects, and enters text exactly where you would, but on your command and within guardrails.
Execution is visible and pausible. You watch Neon take steps, step in to approve, or take over. That visibility is not cosmetic. It is the seed of auditability.

Tasks: scoped workspaces with state

A Task is a container that keeps the context of a job. Tabs, notes, Cards, and the actions Neon took are grouped. Switch to another Task and you change the entire working set. Come back later and the state is where you left it.

Cards: reusable prompts and micro-tools

A Card is a saved instruction and context. Think of a Card called “Summarize any pricing page with term extraction” or “File an expense receipt to our finance app.” Cards remove prompt drift and simplify repeatability. In practice they become your team’s internal catalog of small agents.

Paid early access

Neon launched in a paid early access program. Pricing is about twenty dollars per month, and the rollout is gated. This positions Neon as a product for power users and teams willing to pay for local-first execution and a clear permission model.

The combination matters. By limiting the agent to on-device execution, Neon can respect your existing browser permissions and enterprise policies. By introducing Tasks and Cards, it gives users a language to organize work and a path to team-level standardization.

A fork in the road: who pays for agentic browsing

Two days after Neon shipped, on October 2, 2025, Perplexity made its Comet browser free for everyone. Comet had been available to a subset of users through paid tiers and invites. Now it is broadly downloadable, with an upgraded Background Assistant for Max subscribers and a new Comet Plus news bundle. In other words, Comet is opening the top of the funnel while reserving power features for paying customers, as covered in Comet now free worldwide.

At the same time, The Browser Company has been moving Arc’s successor, Dia, toward a subscription model. That split reveals a strategic fork likely to define the next year of agentic browsing:

Path one: free, ad and data subsidized. Comet will win share quickly by lowering the barrier to entry and bundling discovery. Expect deeper integrations with commerce and content where the agent drives transactions.
Path two: premium, local-first stacks. Neon and Dia will charge for reliability, privacy, and fine-grained control. Enterprises will accept a subscription in exchange for visible execution, logs, and policy hooks.

Neither path is universally superior. They answer different buyers. For consumers and prosumers, free plus convenience is persuasive. For teams with compliance constraints, observable, local-first agents win the room.

Neon, Comet, Dia: how the agent behaves on a page

Let’s drop the marketing names and describe how each behaves when you ask for the same job: “Find three suppliers, compare shipping terms and taxes, fill out the new vendor form in our procurement portal, and save a summary.”

Neon

On-page execution: Neon Do reads and acts on the live page. It can open and close tabs, move through forms, and persist notes inside a Task. It pauses for consent at sensitive steps, then resumes. Its work and intermediate results live in the Task, so you can revisit and reuse them later.
Reuse: You can turn the procedure into a Card with field placeholders. The next person runs the Card and gets a consistent outcome.
Data path: Local by default. The agent uses your logged-in session. This is friendly to corporate identity and device posture rules.

Comet

On-page guidance and actions: Comet runs a sidecar that follows you, explains the page, suggests steps, and in some flows takes actions. Background Assistant, available on higher tiers, can continue multi-step jobs when the window is not in focus, then notify you when it is done.
Reuse: Workflows exist, but the model is oriented to dynamic help rather than template-led automation that lives in named Task containers.
Data path: The free tier and content bundles hint at a model where assistance is offset by partnerships and engagement. That can be a strength for discovery and a concern for strict data boundaries.

Dia

On-page copilot with a paid ceiling: Dia’s subscription unlocks heavier usage and more capable skills. The story emphasizes a familiar browser shell with a deeply integrated assistant. Dia’s posture is premium convenience with a predictable monthly cost.

The user experience converges in one respect. All three are moving away from chat as the primary interface. You still converse, but outcome is organized around jobs to be done. The browser is not a place to ask. It is where things are completed.

Why the browser is becoming the default runtime for agents

Distribution and daily active use. The browser is the most used application on both consumer laptops and enterprise desktops. An agent that lives there meets the user where they already are.
Permission and identity model. Cookies, storage, and sign-in state exist at the browser level. An on-device agent respects existing multi-factor authentication, device posture checks, and conditional access without inventing a new trust tier.
Native access to the page. With permissioned access to the Document Object Model, the agent can read and act without unreliable screen scraping. It can also use standard events, which means less brittle automation.
Sandboxing. Browsers already isolate origins and processes. That gives vendors a foundation to run tools safely as WebAssembly modules with explicit capabilities rather than opaque binaries.
Auditability. A browser can record clickstreams, field-level changes, network calls, and user approvals. That is the essential raw material for compliance and debugging.

Put simply, the browser has the right physics. It sits at the intersection of identity, content, and policy, and it ships with a security model tuned by decades of hard lessons.

The enterprise roadmap for 2025 and 2026

If your job is to deploy this to thousands of employees, you care less about the demo and more about how you will control, observe, and trust it. Here is what to expect over the next four quarters.

Auditable task graphs. Every agentic run will produce a directed graph that shows pages visited, data read, actions taken, tools invoked, and checkpoints where a human approved or edited. Expect exportable logs, replay, and diffing between runs. Vendors will ship a visual inspector so a manager can click a node and see the exact state.
In-browser standards for tools. Model Context Protocol popularized the idea of a local gateway that connects models to tools safely. Browsers will adopt MCP-style patterns inside the page context so agents can call tools through a negotiated, permissioned channel rather than ad hoc integrations. For an early view of how this stack is propagating into platforms, see how MCP is landing in tools.
WebAssembly tool sandboxes. Tooling will move to WebAssembly with capability-based security. A currency converter will ship as a signed module that can only make network calls to a declared set of domains and cannot touch local files unless granted an explicit handle. Security teams will be able to approve or deny modules in a catalog and see which Tasks depend on them.
Identity, single sign-on, and device posture. Browser-native agents must respect enterprise identity the same way extensions do. Look for support for single sign-on, automatic reauthentication on token expiry, and posture checks that disable agent actions on non-compliant devices.
Data loss prevention hooks. Agents will integrate with existing data loss prevention policies. If a Task tries to paste customer data into an external form, the agent should detect the policy boundary and require an override, then log the exception.
Policy controls at three layers. Organization-level policies will define allowed domains and tools. Team-level policies will set which Cards are visible and who can publish new ones. User-level settings will control default consent, such as whether Neon Do can auto-submit forms or must always ask.
Storage and retention. Tasks and Cards will need retention windows, export, and deletion guarantees. Legal holds must freeze specific runs without freezing the entire toolchain. If your data architecture is evolving alongside agents, explore the data layer as agent control plane and how that changes retention and lineage.

These features are not nice-to-haves. Without them, an agent in the browser is a demo. With them, it becomes deployable software.

What this means for product strategy

Neon’s early-access subscription clarifies Opera’s bet. If you are paying, you deserve clear control and visibility. Comet going free clarifies Perplexity’s bet. If you want reach, you need to collapse friction and let the agent find users before the incumbents do. Dia’s subscription signals a third path where design, cohesion, and predictable cost become the product.

The consequence is a faster cycle. An agent can improve weekly because it ships as a browser feature, not a new desktop app. That compounds distribution and feeds network effects around Cards and Task templates. Vendors that seed high-quality, audit-ready templates for common work, like vendor onboarding or reimbursement, will earn trust faster than those chasing generic novelty.

For teams already experimenting with agentic workbenches outside the browser, there is a clear bridge. Productivity suites are becoming agent stages too, with native logging and controls. To see how this mindset is landing in familiar tools, read how to turn Office into auditable workbenches. The patterns are consistent: visible execution, explicit consent, and a replayable trail.

Build or partner: a 60-day checklist

You have two quarters to decide whether to build on a browser’s agent stack or to ship your own. Use this checklist to get to a confident yes.

Choose a deployment posture

If your users already run managed browsers, start with a partner stack that supports on-device execution and policy control. If you need unique primitives, prototype a thin browser shell with a WebView and your agent runtime, but plan to prove value inside a mainstream browser later.

Define the smallest valuable Task

Pick one workflow in the top five percent of time spent that touches multiple web apps. Instrument the baseline time and error rates. Your first agent should reduce time by at least 30 percent and eliminate at least one copy-paste step.

Map required browser primitives

List the page actions you need: read table rows, click buttons by role, detect price elements, upload a file. Confirm your target browser exposes permissioned Document Object Model actions, an isolated execution context per Task, and a way to intercept network requests for logging.

Decide your tool strategy

For tools that call external services, use WebAssembly modules with explicit capabilities. Keep secrets in the browser’s secure storage and gate tool calls through a policy engine. Avoid shipping opaque binaries.

Ship Cards before you ship chat

Turn recurring steps into Cards with placeholders. Name them like internal playbooks. Your goal is to make repeatability obvious for non-experts. Chat remains useful for diagnosis and exploration, but Cards carry the business outcome.

Build the audit path on day one

Log every step with timestamps, target elements, request headers, and human approvals. Provide a replay that shows the page and the click path. You will need this for security reviews and for training. Make it easy to export a run for investigation without exposing unrelated sessions.

Integrate identity early

Wire single sign-on from the start. Ensure Tasks inherit the user’s identity and that reauthentication is graceful. Plan for just-in-time access requests when a Card crosses a domain boundary.

Add data loss prevention guardrails

Before a pilot, define which fields count as sensitive and in which domains they are allowed. Build a visual consent step that shows the data about to cross a boundary with a clear reason and a one-click deny.

Price for the buyer you are courting

If you are going consumer-first, consider a free tier that proves value in under one minute. If you are going enterprise-first, price the pilot to include audit, policy, and support. Tie your price to a named Task outcome, not to generic usage.

Make it safe to stop

Provide a one-click export of Tasks and Cards and a way to run them in another agentic browser. Portability builds trust, and it keeps you honest about using standards rather than secret glue.

The near future

By the end of 2026, mainstream browsing will feel different in quiet but important ways. When you open a browser, you will pick a Task, not a tab. You will ask the agent to start, watch it work, and step in when a decision matters. Your organization will treat the agent’s run like any other business process, with logs, retention, and policies.

That sounds like a lot of plumbing because it is. The payoff is not a flashy demo. It is a browser that helps you finish work without leaving the safe, auditable space where your company already lives. Neon’s launch crystallizes the moment. The browser is no longer a viewer of pages. It is where software does things for you. The winning teams in the next two quarters will be the ones who start building for the browser as the agent, not just the window into the web.