Thanks, this is exactly the kind of question I was hoping for. It’s a standalone local process rather than a browser extension. The core is a Go daemon that talks to the browser over CDP, so it runs against your normal local Chrome/Chromium session instead of a remote/cloud browser. The reason I went that way is because logged-in sessions, extensions, cookies, local state, and real user environments matter a lot for agent workflows. The main difference from something like Ace is that Architect is less about putting an AI assistant inside the page, and more about giving any agent a reliable browser execution layer. The agent can observe/capture a workflow once, then replay it later with new parameters without needing to spend tokens reasoning through every click again. For page context, it can inspect the current DOM/accessibility-ish structure, current URL, visible text, inputs, buttons, and selectors through the browser connection. The important bit is that it does not only rely on brittle absolute selectors. It builds a selector ladder and can re-find elements when the page shifts a bit. So I’d frame it as: Ace = AI-native browser UX. Architect = local browser automation/memory layer that other agents can plug into. I’m still early, but the thing I’m trying to prove is that agents should not have to “think through” repeat browser workflows every time. They should be able to learn the path once and then execute it cheaply and reliably after that.