Skip to content
1 of 32 launch entitiesMosaic.directory V12

The interoperability hub for the Internet of AI

The memory layer under autonomous agents has split in two: local-first and cryptographic on one side, cloud-coordinated on the other. ai4all takes no side. It is the routing seam between them — one Model Context Protocol surface, twenty backends, and a firewall that runs before anything executes.

memory networks
20
protocol pillars
7
engineering stages
5

Hover a node · inner ring sovereign · outer ring cloud

Protocols the host speaks

The shift

From the read-path web to the write-path web

The traditional web was built for human pedestrians: we click, we read, we scroll. Agents that negotiate, execute, and transact need something else — and they cannot be let loose on human infrastructure without boundaries.

Legacy intranet of AI

  • Brittle DOM scraping against interfaces built for eyes.
  • Walled gardens, each with its own auth and its own schema.
  • Context fragmented across tools that cannot see each other.

The Internet of AI

  • Agentic delegates calling declared capabilities, not guessing at markup.
  • Stateful multi-step workflows that survive the session.
  • Peer-to-peer semantic routing across heterogeneous backends.

Position

Not a wrapper. A runtime seam.

ai4all sits between the applications people build and the execution substrate underneath, providing the vault and the connectivity matrix so a credible business can plug into the Internet of AI without building the whole stack itself. As a designated executor entity in the Mosaic ecosystem, that seam is the product.

Application layerThird-party enterprise apps and multi-agent research tools.
ai4all layerThe routing seam and universal adapter. Pre-execution firewall, schema translation, isolated executors.
Mosaic coreStateful sessions and secure distributed execution beneath.

Neutrality

The interoperability membrane

Twenty memory and user-intelligence networks, split across two architectural philosophies. ai4all is the bridge — users pick their side, and the routing layer absorbs the difference.

Group A · SovereignLOCAL-FIRST · CRYPTOGRAPHIC · STDIOGroup B · Non-sovereignCLOUD-COORDINATED · HTTP STREAMVanaSilmariPersonal AIRewindTenureMemTrustDinaOpenMemoryMem0LettaWispr FlowZepCogneeHypabaseMemantoA-MEMHindsightTheoriaGranolaTouchyai4all core routing

The memory sector has bifurcated. A hub that picks a winner is just another walled garden — so the routing seam addresses both sides through one session.

Request path

Automated secure connectivity across the stack

Every call takes the same four steps, and every step is inspectable.

  1. STEP 01

    Ingestion

    An application submits a multi-step request. It arrives as a self-describing payload — no session to resume.

  2. STEP 02

    Translation

    The request is normalised through the Model Context Protocol: JSON-RPC 2.0 envelope, declared tool schema, typed arguments.

  3. STEP 03

    Orchestration

    The hub resolves which backends can answer, translating between flat-vector and graph schemas, alongside A2A and AGNTCY routing.

  4. STEP 04

    Settlement

    Usage settles peer-to-peer over TODA/IP rails, with the receipt carried in the response rather than written to a shared ledger.

Hardened runtime

The brain never touches the hands

ai4all ingests third-party plugins without a trust hand-off escape. The reasoning engine is architecturally severed from the execution environment, so compromising an executor does not reach the model's context, credentials, or decision loop.

Pre-execution firewall

Intercepts, audits, and permissions every request before a runtime exists. Schema assertion first, argument inspection second, spawn last.

microVM containment

External tools and adapters run behind a hardware-virtualised boundary with their own guest kernel — not a shared one.

Cryptographic erasure

Ephemeral volumes mount per session and lose their keys at the end of it, so nothing durable survives into the next.

Roadmap

Five stages, honestly labelled

Stage 1 is this portal and the sandbox you can use today. Everything after it is engineering work we intend to do — stated as intent, not as shipped capability.

  1. STAGE 1Live

    Launch Portal & WebMCP Playground

    Establish the visual identity, publish the developer manuals, and ship an interactive WebMCP test surface.

  2. STAGE 2Next

    Stateless Host Engine & Pre-Execution Firewall

    Build a stateless host that ingests, parses, and verifies incoming tool-call payloads before anything executes.

  3. STAGE 3Planned

    Parallax Paradigm Execution Layer

    Physically isolate executing plugin runtimes from the host's reasoning environment.

  4. STAGE 4Planned

    Ledgerless Settlement Gateway

    Settle peer-to-peer usage without a shared ledger and without third-party gas fees.

  5. STAGE 5Planned

    Swarm Integration & Distributed Nodes

    Connect the runtime to A2A and AGNTCY routing, then push stateless coordination nodes to the edge — and eventually beyond it.

Build on the seam

Send your first tool call through the host

The sandbox runs the real request path in your browser — parse, envelope, schema, firewall, sandbox, settlement. Try a valid payload, then try a hostile one and watch where it stops.

Integration guide · How ai4all relates to Mosaic