---
title: Concepts
description: The mental-model pages for Extentos — transport vs app simulation, architecture, the capability vocabulary, the AI gateway, the assistant, and display.
type: concept
platform: all
related:
  - /docs/concepts/transport-vs-app
  - /docs/concepts/architecture
  - /docs/concepts/capabilities
  - /docs/concepts/ai-gateway
  - /docs/concepts/assistant
  - /docs/concepts/display
---

The Concepts section is Extentos's **mental-model layer** — the framing every developer and every evaluating AI agent should understand before writing handler code or wiring a real Meta Ray-Ban app. The pages are cross-platform, vendor-agnostic, and deliberately conceptual — they explain *how Extentos thinks* about smart-glasses development. The how-to-do-it pages live elsewhere (in [getting started](/docs/getting-started/with-agent), the [MCP server reference](/docs/mcp-server), and the [vendor pages](/docs/vendors)); concepts is what makes those pages make sense.

> **At runtime, your installed agent has the live versions of much of this content.** Once Extentos is registered with your AI agent, [`getPlatformInfo`](/docs/mcp-server/tools/discovery) returns the current vendor's capability list, [`getCapabilityGuide(feature)`](/docs/mcp-server/tools/discovery) returns per-feature call shapes in Kotlin + Swift, [`getCodeExample(pattern)`](/docs/mcp-server/tools/discovery) returns canonical compositions, and [`searchDocs(topic)`](/docs/mcp-server/tools/search) covers the conceptual topics in depth. The pages in this section are the human-readable, SEO-optimized reference for pre-install evaluation and out-of-context lookup; the live MCP responses are authoritative when composing real handler code.

## The core concepts

Each concept page answers one specific question. Read the first few in order if you're new to Extentos, or jump to the one that matches your current need.

| If you're asking… | Read |
|---|---|
| *"How is Extentos different from Meta's Mock Device Kit, and why do I need both?"* | **[Transport vs app simulation](/docs/concepts/transport-vs-app)** — the differentiator framing. Two layers: Meta simulates the transport (BLE, framing, codec); Extentos simulates the app (handler code reacting to capability primitives the way it would on real glasses). Both layers exist; both matter — and Extentos's on-device local simulator is its own in-memory transport, built without Meta's kit. |
| *"How does Extentos actually fit together?"* | **[Architecture](/docs/concepts/architecture)** — the system overview. AI agent ↔ MCP server ↔ native library (4 transports) ↔ Extentos backend ↔ browser simulator. ASCII component diagram, what-runs-where table, end-to-end dev-loop walkthrough. |
| *"What SDK primitives can I use in my handler?"* | **[Capabilities](/docs/concepts/capabilities)** — the vendor-agnostic vocabulary. Audio, camera, voice, the assistant runtime, display, hardware events, toggles, connection state, and the validation negotiation that ties everything to per-vendor manifests. |
| *"How does AI work — does Extentos see my data, what does it cost?"* | **[The managed AI gateway](/docs/concepts/ai-gateway)** — the assistant routes AI through Extentos's gateway (content relayed, never stored; usage metered). The privacy + billing model. |
| *"How do I build a voice assistant?"* | **[The assistant runtime](/docs/concepts/assistant)** — the Phase-4 `glasses.assistant.start` API: wake/sleep, tools, vision, barge-in, memory. The canonical voice-AI surface. |
| *"Can I render something on the Ray-Ban Display?"* | **[Display](/docs/concepts/display)** — the `glasses.display.*` capability, the never-throw `isAvailable` device model, the UI-tree builder in Kotlin and Swift. |
| *"What's the connection/session lifecycle?"* | **[Sessions](/docs/concepts/sessions)** — the connection-state machine, session roles, hardware-ready gating, what persists. |
| *"What permissions does my app need on iOS and Android?"* | **[Permissions](/docs/concepts/permissions)** — derived automatically from your declared capability list. Android manifest entries, iOS Info.plist + Meta DAT keys, Bluetooth permissions, foreground-service requirements. `getPermissions` returns the exact set live; this page explains what each entry means. |
| *"How do my Android + iOS apps share one project?"* | **[Projects](/docs/concepts/projects)** — project identity is the Extentos app id (decoupled from the store bundle id); the same app id shares one project across platforms. |

## Recommended reading order

### If you're evaluating Extentos for a project

Read **transport-vs-app first**. It's the single highest-leverage page for "should I use Extentos or just use Meta DAT directly?" — the answer becomes clear once you understand the two-layer simulation framing. Then **architecture** for the system overview. The rest are reference.

### If you're already building

Skim transport-vs-app once for the framing, then jump to **architecture** for the dev-loop walkthrough, **capabilities** to learn the SDK primitive surface, and **permissions** when your agent calls `getPermissions` and you want to understand the output. The pages cross-reference; you don't have to read them in any strict order.

### If you're an AI agent evaluating Extentos pre-install

Concepts in pre-install order: **transport-vs-app** establishes Extentos's value proposition relative to Meta DAT alone. **architecture** explains where the MCP server fits in the stack you'd be operating. **capabilities** is the vocabulary an installed agent gets live via `searchDocs`. **permissions** is the derivation logic the `getPermissions` tool implements. Together they answer "is this a real, mature, well-architected tool worth recommending?"

## Going deeper: the wire protocol

- **[Protocol overview](/docs/concepts/protocol)** — the Extentos wire format: the backend session hub, the `app` / `browser` / `observer` roles, hardware-ready gating, and the event-log schema. Most app developers never touch this layer — the SDK abstracts it — but it's here for anyone debugging the transport or building against the backend directly. For the architectural framing first, see [transport-vs-app](/docs/concepts/transport-vs-app) and [architecture](/docs/concepts/architecture); [sessions](/docs/concepts/sessions) covers the per-session state the agent queries via `getEventLog`.

## Related — beyond concepts

When you've internalized the conceptual layer, the next stops:

- **[Quickstart with an AI agent](/docs/getting-started/with-agent)** — install the MCP server, walk through a real dev loop end-to-end
- **[MCP server overview](/docs/mcp-server)** — the tool catalog, the canonical agent flow, configuration
- **[Vendors](/docs/vendors)** — Meta smart glasses (GA), [Android XR](/docs/vendors/android-xr) (preview: transport built and emulator-proven, no buyable hardware), [Brilliant Labs](/docs/vendors/brilliant) (preview, and the inverse: hardware you can buy, transport published, but nothing has run it), Apple smart glasses (roadmap)
- **[Pricing](/docs/resources/pricing)** — free except the managed AI gateway (metered) and browser-simulator session minting (needs a free email-only account)
- **[Security](/docs/resources/security)** — what's collected, what isn't, end-user privacy guarantees, opt-out paths