AI Agents Can Run Directly Through Browser Extensions — Curio Ends the Need for Backend Automation

Developer void5tar has just open-sourced an AI Agent framework called Curio, implemented purely as a browser extension. Without relying on Playwright, Puppeteer, or any other backend setup, simply installing a Chrome extension allows AI to directly manipulate the current page — opening websites, reading content, clicking buttons, filling out forms, executing JavaScript, and even performing basic website reverse engineering.

This idea differs entirely from Vercel’s recently promoted agent-browser project. While agent-browser uses the CDP (Chrome DevTools Protocol) route—essentially a CLI tool that requires launching a standalone browser process—Curio abstracts the browser’s content script capabilities into standard function calls, allowing AI to control the current browsing page through a side panel. For debugging in a real browsing environment or interacting with pages already in a logged-in state, this approach is much more straightforward.

Implementation Concept: Wrapping Browser APIs as Function Calls

Curio’s core implementation isn’t overly complex, but the approach is clever. Chrome’s content scripts already have permission to access the page DOM, listen for events, and inject scripts. What void5tar did was standardize these capabilities into function-calling formats, enabling LLMs to invoke them as tools to control the browser.

Specifically:

• Content Script Abstraction: Operations like document.querySelector, element.click(), element.value = xxx are encapsulated into individual functions, each with clearly defined parameters (e.g., selector, action type, value).
• Page Script Injection: Supports executing arbitrary JavaScript in the page context—essential for bypassing some frontend detection mechanisms. For example, as shown in the demo, certain “learning platforms” detect mouse movements; injected scripts can mock those events.
• Agent Message Flow: Inspired by pi (likely an open-source agent framework), Curio supports streaming outputs from LLMs, meaning you can see the agent’s reasoning and action flow in real-time instead of waiting for a final result.

In terms of code structure, Curio handles agent state management, tool invocation, and LLM communication inside the background script, while the side panel purely handles the UI. This architecture allows background persistence, meaning tasks continue even if the panel is closed.

API Compatibility: Not Bound to a Specific Model

A noteworthy design choice: Curio supports any API following the OpenAI/Anthropic-compatible format. This means you can use GPT‑4, Claude, DeepSeek, Moonshot, Qwen, or even locally deployed Llama models. As long as the API conforms to the OpenAI function-calling standard, it will work seamlessly.

This flexibility is especially valuable for domestic developers, where access to OpenAI or Anthropic APIs may be restricted. Models like DeepSeek V3, which already rival GPT‑4 in function-calling capabilities, are also significantly more affordable. Curio’s model-agnostic design lets developers choose the right model based on task complexity and cost efficiency.

Using aggregator platforms such as OpenAI Hub makes configuration even simpler — one API key lets you switch between GPT, Claude, Gemini, or DeepSeek without configuring separate endpoints and credentials for each model.

Real-World Use Cases: From Automated Question Answering to Web Reverse Engineering

In Curio’s demo, void5tar presents two primary use cases:

1. Automated Question Answering

This is the most straightforward scenario. The AI reads the question content, retrieves an answer via search or a knowledge base, and auto-selects and submits the correct option — all without human intervention.

The crucial factor here is accurate DOM parsing, as question structures vary widely across sites — some use plain <input type="radio"> elements while others use custom components. Curio lets the LLM analyze the DOM before generating selectors, allowing it to adapt to most cases. Of course, when dealing with Shadow DOMs or dynamically generated elements, multiple interactions might be needed to pinpoint them accurately.

2. Web Reverse Analysis

This scenario demonstrates more technical depth. In the “learning platform” demo, video study tasks detect whether the mouse stays within the video area — if it’s inactive or leaves the page, the timer pauses.

Traditional workarounds like userscripts require manually analyzing the frontend code and hooking functions. In contrast, Curio lets the AI read the page’s JavaScript, identify detection logic (such as addEventListener('mousemove') or setInterval checks), and automatically inject scripts that mock the required behavior.

The advantage here is universality — you don’t need site-specific scripts. Just instruct the AI to “bypass mouse position detection,” and it will analyze and generate the appropriate injected code. That said, for sites with obfuscation or WebAssembly layers, human intervention may still be necessary.

Comparing Curio and agent-browser: Architecture Defines the Use Case

Vercel’s agent-browser has also gained traction recently, but its design philosophy differs completely:

| Dimension | Curio | agent-browser | |------------|--------|---------------| | Runtime Environment | Browser extension operating on the current page | Standalone CLI that launches a new browser instance | | Technical Route | Content Script + Page Script | Chrome DevTools Protocol | | State Management | Directly interacts with logged-in sessions | Requires --profile to load configurations or manual login | | Element Targeting | LLM-generated selectors | Snapshots with @e1, @e2 references | | Use Cases | Debugging, reverse engineering, tasks requiring real browsing environments | CI/CD automation, batch tasks, headless environments | | Performance Overhead | Runs inside current browser — no extra process | Requires an external process — higher resource cost |

agent-browser excels in standardization and reproducibility. Its snapshot mechanism assigns stable element references (@e1, @e2, etc.) that remain valid even if the DOM changes — ideal for E2E testing and CI/CD pipelines.

However, it cannot directly operate on the current browsing session, which limits its use for tasks involving logged-in states or interactive debugging. By contrast, Curio, being a plugin, can directly interact with the current tab's DOM, JavaScript, cookies, localStorage, and authenticated sessions — invaluable for real-world browser interactions.

Technical Implementation Details

1. Function-Calling Parameter Design

A good function-calling design must balance flexibility and control. Curio’s structure looks roughly like this:

{
  "name": "click_element",
  "parameters": {
    "selector": "string",
    "wait_for": "number",  // wait time (ms)
    "scroll_into_view": "boolean"  // whether to scroll into view
  }
}

Such detailed control allows an LLM to handle complex UI interactions — e.g., scrolling into view, waiting briefly for animations, then clicking. A simplistic click(selector) wouldn’t handle such scenarios reliably.

2. Error Handling & Retry Logic

Automation on the web is inherently uncertain — elements may not be loaded, selectors might break, or requests can timeout. Curio reports these errors back to the LLM for self-correction.

For instance, if click_element returns {"success": false, "error": "Element not found"}, the LLM could try wait_for_element, or re-run get_page_content to reassess the DOM.

This execute-feedback-adjust loop forms the essence of an intelligent agent. Simply throwing exceptions would interrupt workflows that could otherwise self-heal.

3. Security Considerations

Since Curio supports arbitrary JavaScript injection, it’s a double-edged sword: powerful but potentially dangerous. Malicious or unintended code (e.g., exfiltrating cookies) could have severe consequences.

While void5tar hasn’t fully detailed security mechanisms, the extension’s permission scope likely restricts it to actively open pages rather than silent background operations. Still, enterprises should review the source carefully before using it in production.

An improvement could involve a sandbox limiting specific operations — e.g., blocking document.cookie, disallowing cross-origin requests, or forbidding key DOM modifications — trading flexibility for safety.

Why Open-Sourcing Curio Matters: Lowering the Barrier for AI Agent Adoption

Before Curio, building a browser-controlling AI agent required:

1. Deploying a backend service (Node.js + Playwright or Python + Selenium)
2. Managing browser drivers
3. Handling browser process lifecycles (startup, teardown, crashes)
4. Dealing with proxies and anti-bot mechanisms
5. Wrapping all those capabilities into APIs for the LLM

That’s too much overhead for most users. Curio wraps all of it into one simple plugin. Users only need to:

1. Install the Chrome extension (via the Web Store or GitHub Releases)
2. Configure an API key
3. Type a description of the task in the side panel

This "plug-and-play" experience lets more people try AI-driven automation without backend complexity.

Developers can also learn from its code — it demonstrates how to build a usable agent with a lightweight architecture, skipping heavyweight microservices or distributed systems. Perfect for agile experimentation.

Current Limitations and Possible Improvements

1. Selector Robustness

Curio currently relies on LLM-generated CSS selectors. This works well for simple sites but struggles with modern SPAs (React, Vue, etc.). agent-browser’s snapshot referencing (@e1, @e2) system is more stable and LLM-friendly. Curio could implement a similar mechanism or UI-based “element picker” to auto-generate selectors.

2. Multi-Tab Support

At present, Curio can only control one tab. For workflows requiring multiple pages (e.g., list-detail navigation or cross-site comparison), users must manually switch tabs. Integrating the Chrome chrome.tabs API to let LLMs open, switch, and close tabs would solve this.

3. Task Persistence and Resumption

Currently, if the browser or extension crashes, progress is lost. Saving execution steps in chrome.storage would allow recovery after interruptions — essential for long-running batch operations.

4. Debugging and Logging

Enhanced diagnostic logs would help troubleshoot automation failures — e.g., recording function parameters, HTML snapshots, network requests, and intermediate LLM reasoning steps (Chain-of-Thought-like traces).

A Takeaway for Developers: Browser Extensions Are Underrated Agent Platforms

Curio reminds us that browser extensions are an underrated medium for AI agents. Unlike standalone apps or web services, they offer:

1. No extra dependencies — The browser is the runtime.
2. Built-in permission isolation — Extensions can only access authorized pages.
3. Deep browser integration — Access cookies, storage, browsing history, network events, and headers.
4. Cross-platform reach — Works on Windows, macOS, and Linux equally well.

These features make plugins ideal for “personal assistant” agents, such as:

• Email assistant: auto-classify emails, draft replies, summarize key info
• Shopping assistant: compare prices, track discounts, auto-fill addresses
• Learning assistant: summarize articles, translate content, generate notes
• Work assistant: fill forms, process batch data, draft reports

All require real-world browser interaction — precisely what Curio enables.

Final Thoughts

Curio is still young — small in codebase and basic in features — but valuable as a new paradigm: AI agents don’t need heavy backend infrastructures; a browser extension alone can deliver meaningful automation.

For developers, it’s well worth exploring — use it to automate repetitive browsing tasks, study how it wraps browser APIs into function calls, or fork and extend it for more advanced use cases.

Within the broader AI Agent ecosystem, Curio and agent-browser represent two distinct approaches — lightweight flexibility vs standardized reproducibility — not competitors but complements. The right choice depends on context.

The project is newly open-sourced, and the author is seeking feedback from the Linux.do community. If you’re interested in browser automation or AI agents, check out the GitHub repo or try the extension yourself. Open-source projects grow through community input — your feedback could help shape Curio’s future direction.

---

References

• Curio GitHub Repository — Source code and installation instructions
• Linux.do Community Discussion — Project introduction and live demos
• agent-browser Technical Overview — Comparative reference for Vercel’s agent-browser