[Browser identity]
Many portals decide whether to trust a session based on network path, device shape, cookies, cache behavior, and prior login state. Ramain models those as agent profile settings instead of leaving each workflow to rebuild identity from scratch.
Profiles are the browser identity layer
Agent profiles store browser-facing settings such as operating system, cache persistence, popup handling, ad blocking, media blocking, PDF behavior, and stealth options. They are scoped to the workspace and governed by role and ownership checks.
That means an operations team can choose whether an agent should behave like a clean browser, a persistent workspace user, or a more constrained execution profile.
Network routing is separate from task logic
Ramain supports managed proxy configuration and browser profile settings, so teams can control how an agent reaches a portal without putting network details inside the workflow itself.
The workflow does not need to know proxy credentials. It asks the browser to do work; the session infrastructure decides how that browser reaches the target site.
What this prevents
Without profiles, teams hard-code fragile setup into every workflow: log in, accept popups, route traffic, wait for cookies, handle PDF viewer differences, and recover from local desktop drift.
With profiles, those concerns live next to the browser runtime, not inside the business workflow.
Browser profiles keep identity, routing, and session behavior close to the browser runtime, while the workflow stays focused on the business task.
