← product

Glasses platform independence — do we ever leave MentraOS?

Question (2026-07-24): will we eventually be able to — and do we want to — run the glasses experience without the Mentra app, on our own stack?

Short answer: we can, at a cost that scales with how independent we go; we don't want to near-term. Stay on MentraOS for the glasses now, because our value is already portable and the only real reasons to own the stack aren't here yet. This doc captures the architecture split, the paths out, the triggers that would justify leaving, and what a migration would actually touch.

The architecture split (why we're not locked in)

Today: Mentra Live glasses ──BLE──▶ MentraOS phone app ──relay──▶ our AppServer (Railway) ──▶ HJ backend.

Mentra provides three things below the line: the BLE bridge (phone↔glasses), the on-glasses OS (mic / camera / speaker / button I/O), and the session relay (the /webhook session protocol). Everything above the line — JQ, the cloned voice, AisleAsk, Sophia intent routing, the entire backend — is ours.

So we are I/O-locked, not logic-locked. The integration friction we hit standing this up (their webview model, session protocol, Node/module quirks) is platform-integration cost, not product lock-in. A future migration swaps a thin transport layer, never the brain. This is the single most important fact and the reason we can defer the decision safely.

The three paths to "our own", cheapest → dearest

  1. Phone-only JQ — no glasses, no Mentra at all (MOBILE_JQ_PRESENCE.md). Same voice, same backend, zero hardware dependency. This is the real "our own, right now" answer for the audio-first experience; the only thing given up is the hands-free glasses form factor. Treat this as the parallel no-Mentra product, not a fallback.
  2. Fork / self-host the MentraOS relay. MentraOS is open-source, so we can self-host the bridge as a resilience hedge against Mentra-as-a-startup risk — without building hardware. A hedge, not a rebuild.
  3. Own the hardware — the OWNED_HARDWARE_HORIZON.md scenario. The only path to full control (firmware, BLE, battery, manufacturing). Company-scale bet, not an infra choice.

The two — and only two — triggers to go own-stack

Neither is present yet. Absent these, riding MentraOS is correct.

  1. We need to break the walls MentraOS enforces — no ambient listening, no unprompted speech, no world-vision. Those are exactly the three walls OWNED_HARDWARE_HORIZON says owning the glasses deletes, gated behind Sophia's local NLU (decide on-device before the LLM) + the consent/ethics work (AR_GLASSES_LIVING_VOICE.md, Sophia licensing gate). This is the real "want our own" motivation — a deliberate, licensed, counsel-gated mission decision (ambient, always-with-you presence), never a convenience upgrade.
  2. Mentra becomes a platform risk — pivots, shuts down, gates us out, changes terms, or the unit economics break at scale.

Portability guarantees to preserve (so the option stays cheap)

Keep the option open by keeping the brain independent of the transport:

  • No product logic in the glasses app. apps/glasses stays a thin adapter: receive I/O events, call the HJ backend, speak the result. All intelligence lives in the backend + Sophia, reachable by any client.
  • Voice, nudges, AisleAsk, deals, captures are already backend endpoints the phone, glasses, or a future own-device all consume identically.
  • The capture rail is app-neutral and consent-typed — it doesn't care what hardware produced the photo.

Migration surface (what leaving Mentra would actually touch)

Small and contained, by design:

  • Replace: the BLE bridge + session relay (a new phone app or self-hosted fork) and the glasses I/O adapter (apps/glasses, ~one file of wiring).
  • Keep unchanged: the HJ backend, JQ voice, AisleAsk, deals, capture rail, Sophia — i.e., essentially everything that is the product.

Recommendation

  • Now: stay on MentraOS for the glasses. It is the "buildable now" thesis — it put a real hands-free product on real hardware in days.
  • Keep the brain portable (already true — enforce it in review: no product logic in apps/glasses).
  • Run phone-only JQ as the parallel "our own" track — it needs no new hardware and de-risks the whole hardware dependency for the audio-first use.
  • Hold the relay-fork as a cheap resilience hedge, to deploy only if trigger #2 fires.
  • Reserve "own hardware" for trigger #1 — when we deliberately choose to break the three walls. That's a mission call (Living Voice's ambient presence), gated on Sophia + consent + counsel, not something the current integration friction should push us toward.
GLASSES PLATFORM INDEPENDENCE — Docs | HiveJournal