Skip to main content

​
Web Browsing

Some work doesn’t have an API — it lives behind a login, in a portal, on a page with a download button. Erdo agents can drive a real web browser to do that work: open a site, sign in, click through a flow, read what’s on the page, download a file, or take a screenshot — then bring the results back into your thread.
This runs a full browser, not a simple page fetch. It’s for interactive work — logging in, multi-step flows, clicking, downloading. For querying your connected tools and data, agents use connectors and SQL/Python, which are faster and cheaper.

​
What you can do

  • Get something from behind a login — “Log into our ad portal and download this month’s spend report.”
  • Do a multi-step task on a site — “Go to this supplier’s site, find the SKU, and tell me the lead time and price.”
  • Pull data off a page that has no API — “Read the pricing table on this page and turn it into a dataset.”
  • Capture a page — “Take a full-page screenshot of this dashboard.”
The agent narrates what it’s doing, and you can watch the live browser as it works. When the browser finishes — or reaches its time limit — the session closes and the live view ends; the results stay in the thread.

​
What comes back

Whatever the agent produces in the browser comes back as part of the result:
  • Files — anything the agent downloads or exports (a CSV, a PDF, a report) is saved to your Erdo storage and returned as a download link, not a throwaway URL.
  • Screenshots — images the agent captures are saved and returned the same way.
  • Extracted content — text, tables, and observations the agent read off the page, ready to use in the rest of the thread (e.g. turned into a dataset).
Because files are re-hosted into Erdo, the links keep working after the task finishes — you can open them later or feed a downloaded file straight into a dataset.

​
Signing in safely

When a task needs to log in, the agent uses your saved credentials for that site:
  • Credentials are stored encrypted and are scoped to the specific site.
  • The agent’s reasoning never sees the actual values — they’re injected straight into the login form by the browser, not read by the model.
  • Like connectors, credentials are per user — the agent acts as you, with your access, and only on the sites you’ve set up.
If a login needs a one-time email code, an agent can read it from an inbox you’ve given it — so a verification step doesn’t dead-end the task.

​
How it fits with the rest of Erdo

  • Prefer a connector when one exists — connected tools sync into queryable datasets, which is faster and more reliable than driving a browser.
  • Use web browsing for the gaps: sites with no API, one-off portal tasks, and anything that genuinely needs a person-like browser session.
  • A file a task downloads can become a dataset, and a page it reads can become knowledge — the browser is a way in, and the rest of Erdo takes it from there.
Web browsing is an Erdo capability. Under the hood it uses a managed browser provider, but that is an implementation detail we can swap — you connect, authorize, and retrieve everything through Erdo, with your own permissions.