Agent-E Web Automation

Turn natural-language requests into multi-step browser research and actions.

Stars
★ 1.3k
Last updated
4mo ago
License
MIT
Primary language
Python

At a glance

Works with
Universal · cross-platformOpenAI API
You'll need
Python 3.10+uvAG2Google Chrome or PlaywrightShell / CLINetwork accessLocal filesystem
Typical use
An operations specialist handling repetitive web forms can have Agent-E collect supplied information, populate fields, and pause for review before submission.
Main limitation
The present scope is browser automation rather than complete desktop control, and form handling does not yet cover PDFs; canvas-based Google applications remain planned work.

What does this agent do, and when should you use it?

Agent-E is a self-hosted, AG2-based computer automation system whose current scope is the web browser. Its documented open-source architecture combines a User proxy that executes skills with a Browser navigation agent that owns browser-interaction skills. The system distills the browser accessibility tree into compact text, input-field, or all-field views before selecting actions such as clicking, entering text, and opening URLs. Tasks can be submitted through a browser chat interface or through a FastAPI `/execute_task` endpoint that streams results. It is a practical fit for browser-based retrieval and workflows, but not yet a general desktop agent: single-tab state, dynamic controls, Shadow DOM, PDFs, and canvas-based Google applications remain documented limitations or planned work.

Agent-E accepts a natural-language task and uses AG2 agents to select and execute defined skills. geturl, get_dom_with_content_type, and the optional get_user_input inspect the URL, page state, and user feedback; click, enter_text, bulk_enter_text, enter_text_and_click, and openurl manipulate the browser. get_dom_with_content_type can return text_only, input_fields, or all_fields; its distillation process uses the DOM Accessibility Tree and injects an mmid attribute so the model can target elements with DOM query selectors. Each skill returns a natural-language account of its outcome, giving the agent context for its next decision. Users can start tasks from the browser chat UI or send them to FastAPI with POST /execute_task; API callers may also supply separate llm_config values for planner_agent and browser_nav_agent. Execution changes browser and form state, while chat logs can be written to files or printed to standard output according to configuration.

  1. An operations specialist handling repetitive web forms can have Agent-E collect supplied information, populate fields, and pause for review before submission.
  2. A purchasing or e-commerce researcher can ask it to find products, apply sorting criteria, open a result, and perform an action such as adding the item to a cart.
  3. A researcher can use it to visit news, sports, university, or local-business websites, locate requested facts, and report visible page content.
  4. A project team working in a browser-based platform such as JIRA can use natural-language requests to navigate pages and filter issues.
  5. An engineering team can expose the self-hosted FastAPI endpoint inside an internal workflow and provide separate model settings for the planner and browser navigation agents.
  6. A contributor evaluating browser behavior can run the JSON tasks under test/tasks against live websites with python -m test.run_tests.

How do you install or deploy this agent?

The documented runtime is Python 3.10 or newer, with Python 3.11 recommended. On macOS or Linux, run ./install.sh from the project root, or ./install.sh -p to install Playwright support without another prompt. On Windows PowerShell, use .\win_install.ps1 or .\win_install.ps1 -p. For manual setup, install uv, then run uv venv --python 3.11, source .venv/bin/activate, uv pip compile pyproject.toml -o requirements.txt, and uv pip install -r requirements.txt; use .venv\Scripts\activate on Windows. Run playwright install if Google Chrome is unavailable. Copy the configuration with cp .env-example .env, then set at least AUTOGEN_MODEL_NAME and AUTOGEN_MODEL_API_KEY. For a non-OpenAI endpoint, also configure AUTOGEN_MODEL_BASE_URL and, when required by the provider, AUTOGEN_MODEL_API_TYPE and AUTOGEN_MODEL_API_VERSION. To reuse local Chrome, obtain its profile path from chrome://version/ and assign it to BROWSER_STORAGE_DIR.

How do you use this agent?

After configuration, start Agent-E from the repository root with python -m ae.main; on macOS, python -u -m ae.main is the documented workaround for BlockingIOError. When the Agent-E icon appears in the browser, open its chat interface and try a command such as open youtube and search for funny cat videos. For programmatic use on Linux or macOS, launch uvicorn ae.server.api_routes:app --reload --loop asyncio; on Windows, use uvicorn ae.server.api_routes:app --loop asyncio. A first API invocation is: curl --location 'http://127.0.0.1:8000/execute_task' --header 'Content-Type: application/json' --data '{"command":"go to espn, look for soccer news, report the names of the most recent soccer champs"}'. The request may additionally contain an llm_config object with separate planner_agent and browser_nav_agent settings. Run the complete test suite with python -m test.run_tests.

What are this agent's strengths and limitations?

Pros
  • DOM Distillation can reduce the accessibility tree to text, interactive inputs, or all distilled fields instead of passing an unfiltered HTML document to the model.
  • Browser behavior is exposed through named sensing and action skills rather than unrestricted model-generated code, creating a clearer execution boundary.
  • It provides both an interactive browser experience and a self-hosted FastAPI /execute_task interface for application integration.
  • Model configuration covers OpenAI and custom compatible endpoints, with a documented LiteLLM and Ollama route for local open-source models.
  • The repository includes live-site JSON tasks, test-range controls, result identifiers, and an option to capture screenshots after operations.
Limitations
  • The present scope is browser automation rather than complete desktop control, and form handling does not yet cover PDFs; canvas-based Google applications remain planned work.
  • The documented implementation currently handles only one tab reliably and can lose state when another tab opens.
  • Live-site changes make test outcomes variable, while complex dropdowns, Shadow DOM, and losses during DOM distillation are acknowledged areas for improvement.
  • Adoption requires a Python environment, model configuration, and either Chrome or Playwright; remote-model deployments also depend on network access and a model provider.
  • The LiteLLM and Ollama path is documented but explicitly described as not thoroughly tested, so moving to local or less capable models may require prompt simplification or skill refactoring.

How does this agent compare with similar options?

Key facts side by side with the most closely related agents.

Agent Source review Stars Updated Language Full support on
Agent-E Web Automation This agent 48 · Major gaps ★ 1.3k 4mo ago Python OpenAI API
Camoufox CLI 60 · Some gaps ★ 349 1mo ago Python Codex · Claude Code
Auto Browser 62 · Some gaps ★ 793 1mo ago Python OpenAI API · Claude API
Heym 46 · Major gaps ★ 1.3k today Python Codex · Claude.ai

How does FollowAgents rate this agent?

FollowAgents source review · FARS-2.1
Major gaps
48/ 100 5-point scale 2.4 / 5
Trust 8/29
Reliability 9/14
Adaptability 12/18
Convention 9/18
Effectiveness 7/13
Verifiability 3/8
Why each dimension lost points
Trust8 / 29 · 1.4/5

Evidence shows: README describes user confirmation mechanisms (e.g., waiting for user review before form submission) and skill library design to avoid executing malicious code. However, no specific implementation details for least privilege, data flow transparency, or sensitive data handling are provided. Deductions: lack of concrete details on sensitive data handling, dependency security not mentioned, external effects (browser automation) risks not clearly controlled, rollback mechanism completely absent.

Reliability9 / 14 · 3.2/5

Evidence shows: README and test files provide test running methods, but no test results or consistency guarantees. Dependency list is complete, but availability assurance not stated. Failure messages: README provides solutions for common issues, but not systematic. Deductions: self-consistency lacks test evidence, dependency availability unverified, failure message coverage incomplete.

Adaptability12 / 18 · 3.3/5

Evidence shows: README describes multiple use cases (form filling, search, shopping, etc.) and provides environment variable configuration and custom skill directories. However, capability boundaries not clearly defined (e.g., no PDF forms), trigger precision relies on LLM understanding, environment fit only mentions specific macOS and Windows issues. Deductions: capability boundaries incomplete, trigger precision unverified, environment fit not covering all platforms.

Convention9 / 18 · 2.5/5

Evidence shows: README has clear structure with installation, configuration, running, testing sections, provides example commands and FAQ. However, no version changelog, naming stability not stated, known limitations only mention DOM distillation may lose information. Deductions: version changelog missing, naming stability not stated, known limitations incomplete.

Effectiveness7 / 13 · 2.7/5

Evidence shows: README provides multiple usage examples and demo videos, demonstrating practical value. However, no performance benchmarks or cost analysis, cost-benefit not quantified. Deductions: cost-benefit lacks data support, output usability unverified.

Verifiability3 / 8 · 1.9/5

Evidence shows: README cites paper and blog, but no specific test results or third-party verification. Deductions: claims lack traceability, cross-source corroboration insufficient, facts and inferences not clearly separated.

Risks and how to mitigate them
  • Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
  • No version changelog provided, maintenance responsibility unclear.
  • Dependency security not mentioned, need to check for vulnerabilities.
  • Rollback mechanism absent, no recovery after failed operations.
  • Capability boundaries incomplete, may mislead users.
Evidence confidence: Low Reviewed Aug 09, 2026 Reviewed revision f218c3cb4b2b
See the full review method →

FAQ

Do I have to buy the managed service to use Agent-E?
No. The repository is MIT-licensed and documents a self-hosted setup. The README separately offers a free trial of a managed Web Agent and orchestrator with enterprise enhancements, but it does not state ongoing pricing.
Is an OpenAI model mandatory?
No. OpenAI models are directly configurable, while AUTOGEN_MODEL_BASE_URL and related variables support other compatible services. A LiteLLM-plus-Ollama local route is also documented, although the project says it has not been thoroughly tested.
What sensitive resources can it access?
It reads page content and performs browser navigation, clicks, and text entry. When BROWSER_STORAGE_DIR points to a local Chrome profile, automation runs in that browser-profile environment, so adopters should control the selected profile, website sessions, model API credentials, and generated logs.
Why might a browser task fail intermittently?
Documented causes include changing live websites, dynamic dropdowns, single-tab state limitations, Shadow DOM, information lost during DOM distillation, and missing Playwright drivers. Because tests operate on real websites, the project does not expect every test to pass consistently.
Can it wait for a person before submitting a form?
A documented form-filling demo fills the form and waits for user review before submission. Planner access to user clarification can also be controlled with PLANNER_USER_INPUT_SKILL_ENABLED.
View on GitHub ↗ Install ↓

Related agents