Examples: WASM runtime

The WASM runtime compiles the Meerkat agent stack to wasm32 for browser deployment. It routes through the same AgentFactory::build_agent() pipeline as the native surfaces, but intentionally uses standalone in-memory session and mob state. It does not provide runtime-backed keep-alive recovery or cross-process persistence.

This page is intentionally browser/WASM-specific rather than a cross-surface tabbed page. Use Examples: Mobpack first if you want the packaging/deployment path that usually leads into browser delivery.

Build the WASM bundle

CLI
Manual (wasm-pack)

Assemble a self-contained browser bootstrap from a .mobpack artifact. The command does not compile wasm32; it copies the required prebuilt meerkat-web-runtime from the generated wasm-pack --target web output directory named by --wasm:

rkat mob web build ./dist/my-mob.mobpack -o ./dist/web-bundle --wasm ./meerkat-web-runtime/pkg --trust-policy permissive

Then serve and open it: python3 -m http.server -d ./dist/web-bundle. The generated page trust-verifies the pack and initializes the runtime. A host application must still create the mob, spawn members, and provide its own prompt/transcript UI.

Build the WASM package directly with wasm-pack:

CARGO_TARGET_WASM32_UNKNOWN_UNKNOWN_RUSTFLAGS='--cfg getrandom_backend="wasm_js" -C link-arg=-zstack-size=8388608' \
  CARGO_PROFILE_RELEASE_CODEGEN_UNITS=256 \
  CARGO_PROFILE_RELEASE_OPT_LEVEL=0 \
  wasm-pack build meerkat-web-runtime --target web --out-dir pkg

--out-dir is relative to the meerkat-web-runtime crate directory, so this workspace-root command writes meerkat-web-runtime/pkg. The repository-maintained wrapper is npm --prefix sdks/web run build:wasm.

Initialize runtime

Use init-time credentials and provider base URLs to seed the browser runtime’s realm config. The @rkat/web RuntimeConfig is provider-specific: anthropicApiKey, openaiApiKey, geminiApiKey, and the matching provider base URL fields (anthropicBaseUrl, openaiBaseUrl, geminiBaseUrl). The old generic apiKey/baseUrl compatibility fields are deleted, and SessionConfig does not accept per-session apiKey or baseUrl.

import { MeerkatRuntime } from "@rkat/web";
import * as wasm from "@rkat/web/wasm/meerkat_web_runtime.js";

const runtime = await MeerkatRuntime.initFromMobpack(wasm, mobpackBytes, {
  anthropicApiKey: "sk-ant-...",
  model: "claude-sonnet-4-6",
  mobpackTrust: {
    policy: "strict",
    trustedSigners: {
      "release@example.com": releaseSignerPublicKeyHex,
    },
  },
});

Mobpack ingress is fail-closed. The default is strict trust with an empty signer store, which rejects unsigned packs and unknown signers. Supply trusted signers for deployed packs. For a locally generated unsigned demo only, opt in explicitly with mobpackTrust: { policy: "permissive" }. initFromMobpack() verifies the archive and makes its skills available to standalone sessions. It does not create a mob or expose the complete packed definition. A host that wants the declared topology must separately load a MobDefinition, call createMob(), and spawn its members as shown below. For proxy deployments, pass a provider-specific dummy key and base URL. The proxy injects the real server-side credential.

const runtime = await MeerkatRuntime.init(wasm, {
  anthropicApiKey: "proxy",
  anthropicBaseUrl: "http://localhost:3100/anthropic",
  model: "claude-sonnet-4-6",
});

Create session and run turn

const session = runtime.createSession({
  model: "claude-sonnet-4-6",
});

const result = await session.turn("Hello");
console.log(result.text);

Stock MeerkatRuntime.init() and initFromMobpack() only synthesize InlineSecret bindings in the in-memory global realm from provider keys and URLs. They do not accept realm/binding configuration or load native realm files. Registering an external resolver does not create a realm or convert those bindings. Use the key/proxy examples above for stock browser sessions; OAuth or cloud credential handling can stay in the server-side proxy.

External auth is a custom Rust/WASM composition seam. A custom bootstrap must install a binding with credential source CredentialSourceSpec::ExternalResolver { handle: "wasm_host" } before that binding can use the callback. The following fragment only shows registration; it is not an external-binding bootstrap for the stock npm bundle:

import { registerExternalAuthResolver } from "@rkat/web";

await wasm.default(); // Load the wasm-pack web binary before invoking an export.
registerExternalAuthResolver(wasm, async (authBinding) => {
  const token = await hostAuth.freshAccessToken(authBinding);
  return {
    kind: "inline_secret",
    secret: token.accessToken,
    metadata: { account_id: token.accountId },
    expires_at: token.expiresAt,
  };
});

Register before building the externally bound session. First runtime installation preserves a registration made after binary initialization; reinitializing an existing runtime clears it, so register again afterward. withAuthBinding(authBinding, config) only sets a structural selector for an already-configured binding; it cannot install one.

Poll events

for (const event of session.pollEvents()) {
  if (event.type === "text_delta") {
    document.body.innerText += event.delta;
  }
}

Mob lifecycle in browser

// Create mob from definition
const mob = await runtime.createMob({
  id: "research-team",
  orchestrator: { profile: "lead" },
  profiles: {
    lead: {
      model: "claude-sonnet-4-6",
      tools: { builtins: true, comms: true },
    },
    worker: {
      model: "claude-sonnet-4-6",
      tools: { builtins: true, comms: true },
    },
  },
});

// Spawn members
await mob.spawn([
  { profile: "lead", agent_identity: "lead-1" },
  { profile: "worker", agent_identity: "worker-1" },
]);

// Wire peers
await mob.wire("lead-1", "worker-1");

// Inspect runtime state
const members = await mob.listMembers();
const leadStatus = await mob.memberStatus("lead-1");

const sub = await mob.subscribeMemberEvents("lead-1");

for (const envelope of sub.poll()) {
  console.log(envelope.payload.type, envelope);
}

sub.close();

Cross-mob comms

Wire ambassadors across mobs for inter-faction communication. Resolve each member’s opaque peer target through its owning mob, then install trust in both directions. This keeps address and Ed25519 identity construction inside the runtime rather than hand-authoring an external target.

const northTarget = await northMob.crossMobPeerTarget("ambassador-north");
const southTarget = await southMob.crossMobPeerTarget("ambassador-south");

await northMob.wireToPeer("ambassador-north", southTarget);
await southMob.wireToPeer("ambassador-south", northTarget);

// Send work to a member through the canonical member path
await northMob
  .member("ambassador-north")
  .send("Send a message to the south faction proposing an alliance on the eastern front.");

Direct comms_send and comms_peers are reserved low-level placeholders rather than current wasm-bindgen exports or public @rkat/web wrapper methods. Inter-agent messaging happens through member-directed turn submission and the comms tools available to agents during their turns (send_message, send_request, send_response, and peers).

What is available on wasm32

Category	Available	Not available
Agent loop	Full agent state machine, streaming, budget	—
Providers	Anthropic, OpenAI, Gemini (browser fetch)	—
Sessions	Ephemeral sessions	Persistent sessions (filesystem)
Mobs	In-memory orchestration, helpers/forks, flows, lifecycle	Cross-process recovery and persistent mob stores
Comms	In-process (`inproc`) transport	TCP, UDS, network transports
Tools	Custom JS callbacks, task/datetime, and in-process comms tools	Shell, filesystem-mutating, and agent-internal mob-management tools
Skills	Trust-verified mobpack skills compiled into the system prompt	Runtime skill repositories and skill tools (filesystem, HTTP, stdio, Git)
Hooks	—	Configured hook engines and command hooks
Compaction	Automatic session context compaction at configured/model-aware thresholds	No additional manual compaction API in `@rkat/web`
Scheduling	—	Durable schedule driver and stores
Other	Helper/fork delegation inside browser mobs	MCP client and cross-process runtime recovery

Next step

Examples: Mobpack - the packaging/deployment path that often comes before browser delivery
Examples: Mobs - the multi-agent runtime model behind many WASM demos

Getting started

Concepts

Guides: Models And Hosting

Guides: Runtime Behavior

Guides: Orchestration

Examples: Foundations

Examples: Capabilities

Examples: Orchestration And Deployment

Examples: WASM runtime

Build the WASM bundle

Initialize runtime

Create session and run turn

Poll events

Mob lifecycle in browser

Cross-mob comms

What is available on wasm32

Next step

​Build the WASM bundle

​Initialize runtime

​Create session and run turn

​Poll events

​Mob lifecycle in browser

​Subscribe to member events

​Cross-mob comms

​What is available on wasm32

​Next step

Build the WASM bundle

Initialize runtime

Create session and run turn

Poll events

Mob lifecycle in browser

Subscribe to member events

Cross-mob comms

What is available on wasm32

Next step