Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.hyperfx.ai/llms.txt

Use this file to discover all available pages before exploring further.

A browser context is a saved, authenticated browser session that an agent can use when it needs to take actions on the web. You log in once, save the session, and agents can use it for automated browsing without re-authenticating each time.

When to use this

Use a browser context when:
  • The site has no API or your agent doesn’t have an integration for it
  • You want the agent to act as you on a site (your LinkedIn profile, your ad account, your CRM, your CMS)
  • The work involves authenticated dashboards, reports, or platforms that aren’t covered by Hyper’s native integrations
If a native integration exists, prefer that — they’re faster and more reliable. Browser contexts are the catch-all when there isn’t one.
Web Browsing vs Web Search. Browser contexts power the Web Browsing tool — agents interacting with logged-in pages and maintaining sessions. This is different from Web Search, which queries the public web without authentication. Web Search doesn’t need a browser context.

Creating a browser context

1

Open Browser Contexts

From the left sidebar, click MoreBrowser Contexts.
2

Create new

Click Create new context, name it (e.g. “LinkedIn — recruiting”, “Meta Business Manager — main account”), and select the site.
3

Log in

Hyper opens the site in a sandboxed browser. Log in like you normally would — username, password, MFA, whatever’s needed.
4

Save the session

Once you’re logged in, save. The authenticated session is stored encrypted and ready for agents to use.

Using a browser context in chat

Just tell the agent which context to use:
Use my LinkedIn browser context to find recent posts from people working
on AI agents at YC startups, and DM the top 5 most engaged ones.
Agents can also pick a context automatically based on the site and the task — but being explicit is faster and more reliable. You can also pin a browser context to an agent’s Resources tab, so it’s the default for that agent.

Common use cases

  • LinkedIn — outbound, profile updates, content posting, connection management
  • Ad platforms — scraping reports out of Meta Business Manager, Google Ads, TikTok Ads when an integration isn’t enough
  • Internal dashboards — pulling metrics out of Mixpanel, Looker, internal admin tools
  • CMSs and ops tools — Webflow, Notion, Airtable, project trackers
  • Anywhere a login is required and there’s no native integration

Security

  • Encrypted at rest — sessions are stored encrypted, no plain-text credentials
  • Private to you — contexts are tied to your user, not shared across the workspace by default
  • Revokable — delete a context any time; sessions also expire on their own for safety
  • Sandboxed browser — agent browsing happens in an isolated environment, separate from your machine
If you want to share a context with teammates, use a shared service account login when you create the context.

Going further

  • Combine a browser context with a scheduled task to run authenticated workflows on a cadence
  • Pin contexts to a specific agent in its Resources tab
  • For sites with native support, browse Integrations before reaching for a browser context