Agentic browsers cross the chasm: Comet free, Neon live
Two announcements in 72 hours changed where AI agents live. Perplexity made Comet free and Opera began shipping Neon, turning the browser into the distribution layer for agentic software. Here is why this shift matters and what to build next.


The week the browser became the agent’s home
Two moves in the past 72 hours pushed agentic browsing from early adopter curiosity to mainstream battleground. On October 2, 2025, Perplexity announced that Comet is now free for everyone. Two days earlier, on September 30, 2025, Opera confirmed it was shipping invites for Neon, its agentic browser that can execute tasks and even code for users inside the local session, as detailed in its newsroom update, Opera ships Neon to first users.
The signal is clear. The browser is becoming the distribution layer for large language model agents. Not a sidebar chatbot. Not a bolt on feature. A place where agents live, see what you see, and act on your behalf with the right permissions.
Think of the modern browser as an operating system for the web. Tabs are processes. Autofill, identity, payments, and storage are system services. Extensions are drivers. When an agent runs inside this environment, it inherits the most important advantage any software can have: proximity to attention. It sits where the user already spends hours a day and where work already happens.
Why this inflection matters
Here is why the Comet and Neon news is more than product marketing. It changes distribution economics, the architecture of trustworthy agents, and the path to product market fit for startups.
1) The browser is where attention lives
- Distribution is not another app install. It is the default window on work and life. If your agent plans trips, checks out with a wallet, or reconciles invoices, the browser is already logged in to the relevant accounts. That cuts onboarding friction and demo time. Instead of asking users to forward receipts or paste tokens, the agent can operate within the existing session.
- Agents can render immediate, visible progress. Rather than replying with a paragraph, they open the right page, highlight the relevant fields, stage the form, and ask for a single confirmation. Users see the action and build trust.
2) Local autonomy breeds trust
- Neon emphasizes local execution within the browsing session. The more an agent acts locally, the less it needs to ship sensitive context to the cloud. That aligns with user expectations and regulatory pressure. It also avoids the grind of repeated logins and brittle third party cookies.
- Local first does not mean no server. Use the server for heavy model inference or reconciliation, while the browser process owns sensitive state like session cookies, payment gates, and explicit user approvals.
3) Agents can complete transactions, not just generate text
- The jump is from answers to actions. A travel agent that compiles a perfect itinerary is helpful. One that fills the booking page, detects conflicts in your calendar, and waits for your confirmation is valuable. The browser exposes primitives to take those actions in a way users understand.
4) Product velocity improves when the platform handles the hard parts
- Browsers already solve identity prompts, network permissions, file access, and sandboxing. Your team can focus on domain logic rather than rebuilding a desktop wrapper or an automation stack from scratch.
For a deeper look at the trust dynamics behind Perplexity’s agent push, see our analysis of the trust shift around Perplexity agents.
What to build now: a practical playbook
Here is a startup friendly plan for the next 90 days. The goal is to meet users in the browser and turn your agent into a trustworthy coworker that completes tasks.
1) Ship a WebExtensions based companion
- Create a minimal extension that provides three things: context capture, on page actions, and a single confirm step. Context capture means reading the active tab for structured signals like prices, titles, dates, and addresses. On page actions means controlled clicks, form fills, and navigation within the visible session. The confirm step is a clear dialog that shows what will happen and asks for approval.
- Start with one high frequency, low risk workflow your customers already perform. Examples: copy invoice line items into an accounting tool, compare two product pages and stage a checkout, or extract meeting times and create a draft calendar invite.
2) Treat permissions like a product surface
- Ask for the minimum host permissions. Explain why in plain language at the moment of need. Provide a visible indicator when the agent is observing or acting on a page. Build a persistent activity log the user can inspect and clear.
- Add a one click kill switch in the toolbar. Respect it immediately.
3) Design for local first, cloud assisted
- Keep sensitive tokens and session cookies in the browser process. Use the cloud only for model inference and durable memory. When the agent needs to act, send intent metadata rather than raw page data. For example, send this intent: will click the Confirm button on example.com checkout with total 128.40 USD. Do not ship the entire page markup.
- Cache expensive model calls and never ship personal data in prompts unless it is essential and visibly consented. Use structured arguments to models when possible, not pure free text prompts.
4) Use familiar affordances
- Keyboard shortcuts and right click menus beat hidden chat commands. Tab names that reflect task context help users switch with confidence. A small set of reusable instruction templates prevents prompt fatigue.
5) Make success measurable
- Track task completion rate, time to completion, number of user corrections per task, and rollback frequency. These are better north star metrics than raw monthly active users. Instrument with on device analytics that never capture the page content itself, only the agent’s intentions and outcomes.
If you are pairing agents with real world data flows, study the shift to data-plane agents that actually do work.
Build versus buy: how deep should you go
The biggest strategic decision is whether to build a browser, fork one, or ride the wave with extensions and native integrations.
When to buy or integrate
- You are focused on a vertical domain such as travel, fintech back office, recruiting, or health intake. Your differentiation is the workflow and data model, not a rendering engine. Build a WebExtensions companion for mainstream browsers and test explicitly with Comet and Neon. Meet users in the places they already live.
- You want the shortest path to distribution. The fastest route is an extension plus a web app that showcases end to end tasks. Add a lightweight desktop wrapper only if you need deep local file access or background processes.
- Your customers demand control and audit. Use the browser as an execution surface so your actions are visible and replayable. Provide exportable logs and deterministic replays that reconstruct which elements were clicked and which fields were changed.
When to build deeper
- You need capabilities that extensions cannot reliably deliver, such as cross origin automation that exceeds permission scopes, persistent background tasks across many tabs, or a custom memory model that binds to the rendering pipeline. In those cases, consider a Chromium fork or a native companion process that communicates with the extension through a secure local channel.
- Expect real cost. A credible fork requires a dedicated team for security updates, engine merges, cross platform packaging, and hardware acceleration bugs. Budget at least 6 to 10 engineers just to keep pace. Differentiate with eyes open.
A sane middle path
- Pair an advanced extension with a small native helper app for private local data access like offline files, calendars, or encrypted stores. Communicate over a local protocol with explicit user consent. You get the control you need without taking on a full browser codebase.
Local autonomy and privacy are features, not footnotes
In an agentic browser world, privacy is not a policy page. It is a product capability users can observe.
- Keep execution inside the logged in session. When the agent acts with the user’s own cookies, it avoids brittle scraping and reduces the risk of secrets leaving the machine. Users also understand the security model because it matches how they already browse.
- Make approvals granular. If the agent wants to pay, it should present a clean summary with merchant name, amount, and itemization. If it wants to send an email, show the draft, recipients, and attachments. Keep approvals consistent so users build a habit of scanning the right details quickly.
- Build a privacy dial. Offer three modes: Observe only, Stage actions, and Execute with confirm. Default to Stage actions. Let the user promote trusted workflows to Execute with confirm after repeated success.
For governance patterns and oversight that scale with your surface area, revisit how agent control towers arrive.
Plug into agent to transaction pathways
To move from chat to checkout, your agent needs reliable ways to agree on identity and payment.
- Adopt the Payment Request Application Programming Interface. It standardizes checkout prompts and lets the browser surface saved cards, addresses, and contact info. Your agent can stage a transaction and let the user complete it with a single confirmation.
- Support passkeys with Web Authentication. This gives the agent a way to log in on behalf of the user without handling raw passwords. Store credentials in the platform’s secure enclave where possible and avoid building your own cryptography flows.
- Use clear intent contracts in your own application programming interfaces. Define a simple schema for actions like book_hotel, pay_invoice, or schedule_meeting. Include explicit fields for amount, currency, merchant, date, and idempotency keys. The browser agent can validate these before asking for approval.
- Prepare for receipts. Every agent action that changes state should return a machine readable receipt with a timestamp, actor, and result. This is your audit trail and your customer support superpower.
First integrations to pursue this quarter
Start with integrations that reduce risk, prove value fast, and lean on the browser’s native strengths.
1) Payments and checkout
- Integrate with mainstream wallets and payment flows. Support Payment Request API on your site and ensure your extension recognizes and stages those flows. This meets users where they already pay and sets up your agent to become a trusted purchasing assistant.
- If your product touches commerce, build a one click compare and stage feature. The agent collects prices and terms from two or three pages, generates a side by side summary in page, and fills the winner’s checkout form up to the final confirmation.
2) Calendar, email, and documents
- Offer Google Workspace and Microsoft 365 scopes that are limited to read calendars and write events, read email headers and draft messages, and read or write a single folder in cloud storage. Keep scopes narrow and brand them clearly in your approvals.
- Deliver an in page draft for any outbound communication. Users should never wonder what the agent sent.
3) Collaboration and tickets
- Ship integrations for GitHub issues, Jira tickets, Notion docs, and Slack threads that summarize, tag, and propose next actions. The browser context gives the agent access to the right workspace without extra logins.
4) Travel and expenses
- Implement a trip flow that reads dates and destinations from emails or chats, opens two booking sites, applies the company policy on price and carrier, and stages a cart with receipts filed to the right shared drive.
5) Data capture and validation
- Build a visual inspector for structured fields. Users can click a price on a page, label it, and teach the agent a reusable rule. Store these rules locally per domain so they are visible and editable.
Design patterns that work inside browsers
- Show your work. When the agent extracts data, highlight the source region on the page. When it fills a form, animate the fields it touches. Visual breadcrumbs create trust.
- Ask for confirmation only when the state will change. Avoid approval fatigue by letting the agent gather and analyze quietly, then ask once at the boundary of action.
- Provide a recoverable history. A panel that lists the last ten actions with undo buttons is better than a notification feed. Let users rewind a task to a specific step.
- Fail safe. If a site’s layout changes, pause and ask. If an action requires a multi factor challenge, prepare the form and wait. Avoid guessing.
Growth without gimmicks
Agentic browsing enables new growth loops that are grounded in utility, not vanity metrics.
- Measure time saved per task and publish it as a weekly digest to users. Show them what the agent did and what it unlocked.
- Encourage users to turn frequent actions into reusable cards or templates. Share them within a team. Community templates become a durable acquisition channel.
- Treat invites as operational, not viral. An invite should import the templates and policies a teammate already vetted, not just a referral code.
Risks to manage before they manage you
- Terms of service conflicts. Some sites restrict automation. Build a domain policy file that lets users exclude domains or require Observe only. Respect robots style signals where appropriate and document how your agent behaves.
- Model drift. When prompts and models change, actions can drift. Version your action templates and keep a canary set of tasks that run daily on known pages to catch breakage early.
- Vendor concentration. If your entire product depends on a single model or a single browser, you carry platform risk. Keep an abstraction layer over models and test on multiple browsers. The goal is not to support everything, but to keep options open.
- Security posture. A malicious page can try to trick naive agents. Require element level checks, not naive text matching. Never click invisible elements. Never act on behalf of a user unless the action originates from an explicit agent prompt or a controlled template.
The bottom line for startups
- Build where attention lives. Your agent should live in the browser because that is where users work and where actions happen.
- Lead with local autonomy. Make privacy observable. Keep sensitive execution in the session and ask for clear confirmations.
- Wire up transaction pathways. Identity, payment, and receipts turn research into outcomes. Design explicit intent contracts.
- Start with an extension. Prove value on one workflow, then expand with templates and a native helper if needed. Forking a browser is a last resort.
A smart closing thought
The Comet and Neon announcements are not just another cycle of features. They mark a structural shift in where agents live and how they earn trust. When the browser becomes the operating system for the web, the winning products will be the ones that turn messy intent into clean, auditable action. Build the piece that closes that loop and you will not just demo intelligence. You will deliver outcomes people rely on.