In Part 3, we looked under the hood of Mosaic — the Context Engine, the Registry of Tiles, and the Composer. We also saw why Progressive Web Apps (PWAs) are the natural starting point.
Now let's go deeper: how exactly Mosaic works as a PWA today, and where it could go in the long term.
How Mosaic Works as a PWA
At first, Mosaic can be implemented as a single container PWA hosted at {abc.com}.
When you install Mosaic once (from {abc.com}), you get the wrapper app that includes:
- Context Engine → interprets user goals.
- Tile Registry client → fetches logic, UI components, and metadata.
- Composer → assembles tiles into an App Flow and renders it.
Each App Flow is just a route inside this PWA.
https://{abc.com}/appflow/tokyo-trip
https://{abc.com}/appflow/moving-house
https://{abc.com}/appflow/meal-planner
All three share the same manifest, service worker, and scope.
Why They Are Not Separate PWAs
Browsers determine PWA identity by the scope field in the manifest.
If Mosaic defines its manifest with:
{
"name": "Mosaic",
"start_url": "/",
"scope": "/appflow/"
}Then every route under /appflow/ belongs to the same installed PWA.
This means you install once, and all flows open inside that single container.
- To the OS, it's one PWA (one icon, one storage).
- To the user, each flow feels like a different app because the Composer dynamically reshapes the UI based on the flow ID.
So:
Tokyo Trip and Moving House are not two different PWAs.
They're two different parameters/configurations inside the Mosaic container.
This avoids clutter (otherwise every flow = new icon = recreating today's problem).
Why PWAs Are the Perfect Bridge
PWAs already provide many of the features Mosaic needs:
Self-updating
Service Workers let PWAs update silently in the background.
Flows evolve without reinstallations.
Cross-platform reach
PWAs run in browsers, mobile, and desktop.
Flows are just links — instantly accessible.
Installability
The container can live on your home screen.
Users can "install Mosaic" once, but still open any App Flow link.
Offline capabilities
Tiles can cache data or run local logic when offline.
Instant shareability
A Tokyo Trip flow is just a URL you can send to a friend.
When they click, it runs inside their Mosaic container (or in the browser if they haven't installed yet).
This makes PWAs the perfect near-term vehicle for Mosaic.
But PWAs Have Constraints
We should be realistic about today's PWA ecosystem:
- Device APIs — limited access to Bluetooth, NFC, sensors, and background sync.
- Discoverability — app stores prioritize native apps, PWAs feel hidden.
- Platform politics — iOS restricts push notifications, background tasks, and storage.
These constraints mean PWAs can't unlock every use case. But they can already demonstrate the core Mosaic experience: adaptive, self-updating, and shareable App Flows.
The Near Future: Hosted Registries
At the start, websites like {abc.com} can host Tile Registries and Flow Builders:
- Developers publish reusable tiles.
- Users combine tiles into App Flows via a simple web builder.
- Flows are shared as URLs.
Multiple providers could host registries — just like multiple app stores exist today.
Some registries may specialize (travel, fitness, education), while others remain general-purpose.
The Long-Term Goal: OS-Level Mosaic
Over time, Mosaic could move deeper into the operating system, just like app stores and file explorers did.
- The Tile Registry becomes part of OS settings (where you choose which registries to trust).
- App Flows become OS-native adaptive apps, disposable and self-updating.
- Users don't manage dozens of installs. They simply trigger flows by expressing goals.
This is where Mosaic diverges from MCP (Model Context Protocol):
- MCP focuses on chat-based interaction — you ask, it responds.
- Mosaic delivers app-based experiences — not a conversation, but a disposable, adaptive app that appears, serves its purpose, and disappears.
Mosaic = chatless orchestration + goal-driven adaptive apps.
The Roadmap
Today
{abc.com}as a container PWA.- App Flows are just routes (
/appflow/:flowId) inside it. - Install once, open any flow by link.
Near Future
- Multiple hosted registries.
- Flow builders for families, teams, communities.
- Sharing flows feels like sharing docs or playlists.
Long Term
- Registry management at the OS level.
- Adaptive App Flows become first-class citizens of the OS.
- Apps as we know them give way to goal-driven flows.
Why This Matters
PWAs let us build Mosaic today — with one container app and flows as routes. Hosting registries at sites like {abc.com} lets users and developers experiment now.
But the long-term vision is bigger: Mosaic as an OS-native orchestrator, with registries managed at the system level. Unlike MCP's chat-first approach, Mosaic enables goal-first disposable apps that adapt and disappear when finished.
The future isn't about apps you hunt down and install.
It's about flows that find you, adapt with you, and vanish when the job is done.
Homework for You
👉 Homework 1: Look at the URLs you used today. How many of them could be App Flows inside one container PWA instead of separate apps?
👉 Homework 2: If you're technical, read a PWA manifest on one of your installed web apps. Notice the scope field. Can you imagine how /appflow/:flowId could all be grouped under one container?