inside aura: architecture of an ai-native browser
aura started as a question: what would a browser look like if intelligence was part of the engine, not bolted on as an afterthought?
to answer that, we designed the architecture around three constraints: local-first by default, agentic workflows as a first-class primitive, and a rendering engine that never fights your focus.
the result is a layered system: an automation runtime that can observe and act, a context engine that understands your current work, and a thin ui that stays quiet unless you call on it.
the question
aura started as a question: what would a browser look like if intelligence was part of the engine, not bolted on as an afterthought?
every major browser was built to load pages. the ai layer was always an extension — a sidebar, a toolbar, a plugin that sits outside the content. we wanted to ask what happens when you flip that: intelligence first, rendering second.
local-first by default
the first constraint was on-device by default. we do not want your browsing history, your tab context, or your agent prompts leaving your machine unless you explicitly allow it.
this shapes everything from model selection to storage: we favour smaller, faster, task-specific models that run locally over large frontier models that require a network call. the fallback to cloud is opt-in, not opt-out.
the practical tradeoff is that local models are less capable for complex synthesis tasks. we solve this by being intentional about what each model is asked to do — and by building a routing layer that knows when to escalate.
agentic workflows
the second constraint was treating automation as a first-class primitive. most browsers can open a tab. aura can observe a tab, read its content, decide the next step, and act — all without you switching context.
the automation runtime is sandboxed per-tab. it has read access to the dom and limited write access gated by a user-defined policy. the policy is set once, in plain language, not code.
we designed this as a pipeline: observe, summarise, decide, act. each stage is pluggable. you can swap in a different model for the summarisation step, or add a confirmation gate before any action executes.
context engine
the third constraint was context. most ai tools ask you to provide context each time. we wanted the browser to maintain it.
the context engine tracks your current project, open tabs, recent actions, and any documents you have pinned. it maintains a compressed working set that gets passed to the agent layer on every invocation.
this is the part of aura that feels most like magic when it works — and most frustrating when it is wrong. we have spent more time on the coherence of context than on any other part of the system.
where we go from here
the current architecture is a foundation, not a destination. the automation runtime will get a proper plugin system. the context engine will get long-term memory backed by a local vector store.
the thing we are most interested in is making aura aware of intent — not just what you are reading, but what you are trying to accomplish. that is a harder problem, and we are working on it.