Separate decisions from execution
The model interprets the task and observations. The agent or orchestration layer manages the loop, context, retries, and tool selection. The controller translates proposed actions into interactions with a browser or desktop. The runtime supplies the actual session and operating environment. One vendor may package several layers, but the responsibilities still exist.
Our taxonomy keeps these responsibilities separate so a browser infrastructure provider is not automatically ranked as an autonomous agent. A hosted browser can run a deterministic Playwright script or support an agent. The decision logic belongs elsewhere unless the provider explicitly documents it as part of its product.
Add the operational layers
Identity determines which account the run acts as. Policy decides whether a proposed action is allowed. A queue decides when work starts and how failed jobs are handled. Observability records what happened. Outcome validation decides whether the requested result is acceptable. These layers often explain why a working demo is not yet an operable service.
Keep task state separate from browser state. A persisted browser login does not tell you which records a job already processed. A job checkpoint does not prove that the browser still has the correct account open. Before a resumed action, reconcile both kinds of state.
Two useful reference architectures
For a stable portal, consider a deterministic controller in a managed browser, a scheduler, and an artifact validator. Add a bounded model step only where page interpretation is necessary. This architecture gives each uncertain operation a clear owner and avoids paying for model reasoning on every predictable interaction.
For varied authorized portals, consider an agent framework with a browser runtime, task-specific policy enforcement, and a review queue. Use schemas for extracted data and explicit approval for consequential changes. These are proposed patterns, not claims that every named framework integrates with every host without additional work.
Choose where to standardize
A team can standardize on a runtime while evaluating several agents, or standardize on an agent while testing hosting options. The best seam depends on the workload. Define an interface for session creation, action execution, artifact retrieval, and cancellation so experiments do not require rewriting business rules.
Keep pricing aligned with layers: model tokens, runtime duration, proxy transfer, service fees, and review effort. Keep benchmarks aligned with layers too: browser availability and agent task completion measure different things. A stack diagram should make these boundaries visible before a comparison page makes a buying recommendation.