Forking from #21 (comment), it's good for us to align on the use-cases targeted by this proposal so we can guide the API design. There's 2 broad use-cases:

1. Automation: This is the non-human in the loop remote browser automation task. I don't think we should be targeting this, MCP was purpose built for this use-case and will likely be the most efficient mechanism for it. It's possible WebMCP provides a means to take an existing site and use it a regular "MCP service". The Agent uses the WebMCP tools instead of DOM parsing/screenshots, i.e., actuation. It's more efficient than actuation but less so than direct MCP.

2. User and Agent sharing the UI: This is the human in the loop case, where a user is consuming the website alongside the Agent and interaction can pass between the 2 as needed. The web UI itself could be the top level browsing context or embedded as a widget in the Agent (the difference shouldn't matter).

I'm not opposed to 1) but don't think this should be our focus and wouldn't want to make complicated API choices to support it.

@bwalderman @sushraja-msft I think that's your take as well based on the MS explainer. Wasn't sure if you're thinking about it differently now given the service worker based idea which is veering into the automation territory..?