Skip to content

What WAMP is

WAMP is a platform for building AI applications. It gives you a running host — windows, an agent loop, a tool registry, typed storage, scheduling, an identity system — and a way to add your own software to it. After this page you will know what the platform hands you, what you can put on top, and the one structural idea the rest of the documentation depends on.

These are the primitives. Every one of them is something your code declares or calls, not something you reimplement.

Primitive What it is
Agents An AI that runs a loop: reads context, calls tools, decides when it is done. You can define your own agent with its own prompt and tool set.
Tools A named function with a JSON schema that an agent may call. Register one and every agent in the host can use it.
Views React surfaces you mount into the shell — a full window, a docked panel, a dock tool, a status widget, an overlay.
Commands Named actions with optional keybindings, reachable from the palette or from another extension.
Storage Typed collections with schema versioning and a predicate query DSL, plus per-extension key/value and raw SQLite.
Scheduling Cron jobs and local HTTP routes, so an extension can do work while nobody is looking at it.
Identity Who is using this: a WAMP account, an anonymous installation, or your product’s own end user. The shell owns sign-in; your code reads the session it produces.

Model access is part of the substrate too. An extension calls ctx.api.ai.chat(...) or opens a multi-turn session; the host owns provider routing, keys, and metering. You do not ship an API key in your app.

Everything you build is an extension. There is no separate app type, plugin type, or widget type. An extension is a directory with an extension.json manifest, some code, and a declaration of what it may touch. A one-icon status widget and a full-screen product are the same kind of artifact at different sizes, built with the same manifest and loaded by the same loader.

An app is an extension that owns its window. That is a single field on a contributed page:

"contributes": {
"pages": [
{ "id": "tasks", "title": "Tasks", "icon": "ListChecks",
"context": "both", "presentation": "app" }
]
}

With presentation: "docked" (the default) your page renders inside WAMP’s own chrome, next to the assistant. With presentation: "app" the page takes the window over: WAMP’s chrome is hidden and you draw your own with <AppShell> from the interface kit. Nothing else about the extension changes — same manifest, same permissions, same build, same distribution.

That is why there is one lifecycle in this documentation instead of three: author an extension, run it inside WAMP, then choose how users get it.

The platform’s own surfaces are extensions, which is the most direct evidence of what the primitives carry:

  • A web browser with an agent-callable tool surface, so an agent can drive pages the user can also see.
  • A coding environment — file tree, editor, diffs, terminal — which is one extension among the bundled set, not the product itself.
  • A CLI harness workbench that tiles several foreign coding agents in one window.
  • A marketplace client for installing other extensions.

The worked recipes cover the shapes most products start from: a persistent product with typed storage, a daily cron and AI assist; a chat app with a model picker and multi-turn sessions; a headless pack that contributes only tools; a webview wrapper; a file-tool extension; and an app whose users are its own.

It is not an AI IDE. Coding is one application on the platform, shipped as an extension like anything else. If you are evaluating WAMP against coding tools, you are comparing the platform to one of its apps.

It is not a chat wrapper. A chat surface is available to your app, but the agent loop, the tool registry, and the storage layer are usable with no chat in sight — a scheduled extension with no UI is a legitimate thing to ship.

It is not a hosted agent API. If what you want is durable agent sessions running in managed cloud sandboxes, driven over HTTP from a backend you already have, that is a separate product with its own documentation: WAMP Cloud.

It is not a sandbox for untrusted code. Permissions gate the capabilities the host provides to an extension, and the manifest declares them for the user to see. The extension’s own JavaScript is not confined beyond that, so an installed third-party extension is trusted code on the user’s machine — treat it the way you would treat any other installed application.

  • Quickstart — the shortest path from nothing to an app running in front of you.
  • Core concepts — the vocabulary, in the order it builds on itself. Worth ten minutes before your second page of code.
  • Extensions and apps — the artifact in detail.
  • Choosing a path — how finished work reaches users: a marketplace extension, your own branded desktop binary, or your existing product with WAMP behind it.