What is a browser profile for AI agents?

What is a browser profile for AI agents?

Some login flows can't be automated — at least not reliably. SSO with vendor-specific JavaScript. Sites that mark a device as trusted on first login and treat every "new" device with maximum suspicion afterward. Step-up auth that throws a different challenge each visit. Building agent-side automation for any of those is brittle on day one and broken by day thirty. Profiles take a different bet: do the login once, by hand if necessary, and let the persisted browser state do the work after that.

When agent-driven auth isn't enough

Three classes of flow that defeat agent-bootstrapped authentication:

1. Sticky-device 2FA. Sites that re-challenge every "new" device but trust the one you logged in from. A fresh agent session is always a new device, which means re-challenging on every run.
2. Custom SSO and step-up auth. Vendor-specific IdP flows, magic-link confirmations across multiple devices, risk-based challenges that change form each time. Hard to model as a deterministic task.
3. Throwaway access to internal tools. A QA dashboard, a partner portal — places where enrolling a digital identity is overkill and you really just want the agent inside the page.

For all three, the right abstraction isn't "make the agent better at logging in." It's "do the login once, the way a human would, and reuse the cookies."

How a Notte profile works

A profile is a saved snapshot of browser state — cookies, localStorage, sessionStorage, cache — that Notte attaches to a fresh browser instance at session start. The lifecycle has two phases:

1. Bootstrap. Create a profile, then open a session with the profile attached and persist=True. Log in — programmatically if you can, or manually through Notte's session viewer if the flow requires a human (think Google login with passkey, bank with photo verification). When the session ends, the browser state is written back to the profile.
2. Reuse. Every subsequent session that attaches the same profile with persist=False starts already authenticated. Multiple parallel sessions can read from the same profile concurrently.

from notte_sdk import NotteClient

client = NotteClient()

# 1. Bootstrap — create a profile and complete the login once.
profile = client.profiles.create(name="github-login")

with client.Session(
    profile={"id": profile.profile_id, "persist": True},
) as session:
    session.execute(type="goto", url="https://github.com/login")
    # Drive the login programmatically here, OR connect Notte's viewer
    # and let a human complete it. Browser state persists either way.

# 2. Reuse — fresh sessions start already authenticated. persist=False is
# read-only, so you can run many in parallel without write conflicts.
with client.Session(
    profile={"id": profile.profile_id, "persist": False},
) as session:
    agent = client.Agent(session=session, max_steps=10)
    response = agent.run(
        task="Open my GitHub notifications and list the most recent ones.",
    )

Profiles vs. digital identities

Profiles and digital identities solve overlapping problems with different bets. They aren't substitutes — they target different login shapes.

Many production systems use both: a profile for the heavy initial enrollment on a hard-to-automate flow, an identity layered on top for the routine actions afterward.

Common use cases

• Personal automations on your own accounts — connect once, run forever. Lowest-friction path for hobby and internal scripts.
• Internal-tool scraping behind SSO that nobody wants to reverse-engineer for the agent.
• High-trust verticals (banks, brokerages, regulated dashboards) where fresh fingerprints get flagged and a returning trusted device sails through.
• Customer-bring-their-own-account products — the customer logs in once via your embedded viewer, and from that point on your agent acts on their behalf without ever holding the credentials directly.

Key takeaways

• A browser profile is a saved snapshot of cookies, localStorage, and cache that lets a Notte session reuse a previously-authenticated browser state.
• Lifecycle: client.profiles.create(...) → first session with persist=True (login happens, often manually) → later sessions with persist=False start authenticated.
• Profiles and digital identities are complementary, not interchangeable. Profiles favor human-bootstrapped flows; identities favor agent-bootstrapped ones.
• Pair with credential vaulting when the login is programmatic; reach for profiles when it isn't.