Mosaic, Part 3: Under the Hood of App Flows

1. The Context Engine

This is the brain of Mosaic.

Powered by a Large Language Model (LLM), it interprets a user's intent: "I'm visiting Tokyo," "I'm preparing for a check-up," "I'm starting a new class."

It uses signals like time, location, role, and past behavior to understand what stage of the journey you're in.

Unlike today's chatbots, which just respond to prompts, the Context Engine continuously updates context and reshapes the App Flow as your journey evolves.

2. The Registry of Tiles

The Tile Registry is the keystone of Mosaic — and the part that makes it more than "just another MCP."

In MCP, registries expose APIs that an agent can call.

In Mosaic, registries expose tiles: modular units made of three layers:

// logic.ts
export async function getWeather(location: string) {
  const response = await fetch(`/api/weather?loc=${location}`);
  return await response.json();
}

<!-- WeatherTile.svelte -->
<script lang="ts">
  export let weather: { temp: number; condition: string };
</script>

<div class="tile card">
  <h3>Weather</h3>
  <p>{weather.temp}°C — {weather.condition}</p>
</div>

{
  "name": "WeatherTile",
  "version": "1.0.0",
  "provider": "Community",
  "logic": "./logic.ts",
  "presentation": {
    "modes": ["card", "widget"],
    "component": "./WeatherTile.svelte",
    "props": {
      "weather": "object"
    }
  },
  "metadata": {
    "context": ["travel", "daily-life"],
    "priority": "medium",
    "pairsWith": ["MapTile"]
  }
}

So the registry doesn't store raw UI or screenshots. It stores logic modules, UI components, and metadata — everything needed for the Composer to use the tile.

3. The Composer

The Composer is the layout and integration engine.

• It receives a set of relevant tiles from the Context Engine.
• It looks at each tile's manifest (logic + presentation + metadata).
• It decides:
  • Which tiles to show.
  • In what order.
  • In what presentation mode (card, widget, popup).

How the Composer Renders Tiles

The Composer uses a shared design system (like Tailwind, Material UI, or a custom theme) to keep tiles consistent.

It mounts tile components dynamically, passing in data as props.

Example flow:

1. Context Engine says weather is relevant.
2. Composer imports logic.ts, runs getWeather("Tokyo").
3. Composer mounts WeatherTile.svelte in card mode, passing weather as props.

With existing web tech (dynamic imports, Web Components, Svelte/React), this is totally possible today.

Handling Multiple Tiles for the Same Thing

What if there are multiple tiles for weather or translation? Mosaic handles this in layers:

• Registry curation — verified tiles can be highlighted.
• Context Engine arbitration — the LLM can pick based on metadata (offline support, reputation, integration).
• User override — users can swap tiles if they prefer a different one.
• Coexistence — in some cases, multiple tiles can appear side by side.

This avoids today's app-store chaos while still allowing competition.

4. Security & Control

Dynamic apps need trust. Mosaic provides:

• Version locking — freeze your App Flow at a safe state.
• Rollback — undo unexpected updates.
• Verified tiles — signed by trusted providers.
• User overrides — control which tiles get used.

This ensures flexibility without sacrificing control.