[Browser execution]
Ramain treats the browser as the runtime for manual operations work. Each authoring or workflow run gets an isolated browser session that can be viewed live, attached to a workflow, released when finished, and replayed later from the run history.
What is managed
Ramain launches controlled browser sessions for authoring and workflow execution, so each run has its own live workspace instead of sharing a fragile desktop or reused tab.
A session carries the browser view, the workflow it belongs to, the active run state, and the ownership boundary around it. Operators can watch the browser, reconnect to an active run, and terminate work without confusing it with another user's session.
Why isolation matters
Portal automation is risky when many workflows share a browser, a cookie jar, or a long-lived desktop. Login state leaks, tabs drift, and recovery becomes guesswork.
Ramain keeps workflow execution scoped to the session that launched it. Run status, session id, browser mode, viewport, and workflow id travel together so a user can understand which browser performed which work.
How it behaves in practice
During authoring, the user teaches inside the Builder tab while the agent operates the live browser. During execution, saved workflows launch managed browser runs that can be watched, terminated, or resumed from status.
The browser is not just a screen recording. It is the action surface the compiler learns from and the runtime the workflow uses later.
Managed browsers make UI automation reviewable. Teams can see what happened in the browser while keeping each workflow run scoped, recoverable, and separate from other work.
