Skip to main content
mobpack is the portable artifact for mobs. You build it once, then invoke it as a typed callable run, install/deploy it for reuse, or build a browser bundle.

​
What this guide is for

Use this guide when you want to:
  • package a mob into a portable artifact
  • sign and validate that artifact
  • invoke it consistently across CLI, service, and browser targets

​
What you get

  • Single-file artifact: .mobpack
  • Optional signing and trust verification
  • Deterministic inspect and validate boundaries
  • Typed callable invocation (mob run) and browser bundle target (mob web build)

​
Directory to artifact

rkat mob pack ./mobs/release-triage -o ./dist/release-triage.mobpack
rkat mob inspect ./dist/release-triage.mobpack
rkat mob validate ./dist/release-triage.mobpack
Expected source files:
  • manifest.toml
  • definition.json
  • optional skills/, hooks/, mcp/, config/defaults.toml

​
Signed packs and trust policy

Sign at pack time: 
rkat mob pack ./mobs/release-triage -o ./dist/release-triage.mobpack --sign ./keys/release.key --signer-id release@example.com
Run with strict trust: 
rkat mob run ./dist/release-triage.mobpack --prompt "triage release regressions" --trust-policy strict
Trust policy resolution:
  1. CLI --trust-policy
  2. RKAT_TRUST_POLICY
  3. config trust.policy
  4. default strict (fail closed; accepting unsigned or unknown-signer packs requires an explicit permissive opt-in)
Strict mode rejects:
  • unsigned packs
  • unknown signers
  • invalid signatures
  • signer key mismatches

​
Run Modes

One-shot CLI run: 
rkat mob run ./dist/release-triage.mobpack --prompt "triage latest incidents"
Detached reusable run: 
rkat mob run release-triage --flow main --param severity='"high"' --detach
rkat mob attach release-triage <RUN_ID>

​
Browser target: mob web build

The web build compiles the real meerkat agent stack to wasm32 — same agent loop, same LLM providers (Anthropic, OpenAI, Gemini), same streaming as CLI/RPC/REST. Not a simulation. Prerequisites: the prebuilt meerkat-web-runtime artifacts — the wasm-bindgen glue (meerkat_web_runtime.js) and its paired meerkat_web_runtime_bg.wasm — produced by wasm-pack build meerkat-web-runtime --target web (or the committed sdks/web/wasm directory). The CLI does not compile wasm32 itself and fails closed without them — it never emits a placeholder bundle. Pass either the wasm-pack output directory or the *_bg.wasm file (the sibling .js glue is copied alongside it): 
rkat mob web build ./dist/release-triage.mobpack -o ./dist/release-triage-web --wasm ./sdks/web/wasm
Output is a self-contained, runnable bundle — serve the directory (e.g. python3 -m http.server over the output) and open index.html:
  • index.html — ready-to-run demo page: enter an API key, click Start, the mob boots in-browser
  • meerkat-bootstrap.js — reusable ES module exporting bootMobpack(opts); import it from your own app
  • meerkat_web_runtime.js — the wasm-bindgen glue
  • meerkat_web_runtime_bg.wasm — the compiled meerkat agent stack
  • mobpack.bin — the packed mob artifact (loaded via the runtime’s init_runtime)
  • manifest.web.toml — derived web manifest
The generated bootMobpack bakes in the trust policy this bundle was built with (--trust-policy); override it (and supply trusted_signers) for signed/strict production deployments.

​
How the WASM runtime works

The runtime uses tokio_with_wasm as a drop-in tokio replacement (backed by the JS event loop), reqwest with browser fetch for HTTP, and web-time for browser-safe timestamps. The #[async_trait(?Send)] pattern handles wasm32’s single-threaded model. API: 
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",
});

const session = runtime.createSession({ model: "claude-sonnet-4-6" });
const result = await session.turn("Your prompt here");
const events = session.pollEvents();

​
Browser capabilities and limitations

Available: agent loop (streaming, retries), all LLM providers, sessions, JSON schema validation, budget enforcement, events, skills, MCP config types, tool/compactor/memory traits. Not available (browser inherent): filesystem config loading, stdio MCP servers, shell tool, file-based persistence. Use programmatic config and in-memory storage instead. Not yet available (upstream blocker): MCP protocol client over HTTP — the rmcp crate depends on tokio/mio which don’t compile on wasm32. MCP config types and tool definitions work; actual connections to MCP servers are blocked pending rmcp wasm32 support.

​
Cool web patterns

​
Incident war room

Build ops-war-room.mobpack, publish web bundle behind internal auth, and let responders open a zero-install multi-agent workspace in-browser.

​
Embedded dashboard copilot

Bundle dashboard-copilot.mobpack and embed it in your observability or release dashboard to summarize anomalies and propose mitigation steps in context.

​
Example library

See runnable examples:
  • examples/028-mobpack-release-triage-sh for a signed release-triage mobpack that is packed, inspected, validated, and deployed end to end
  • examples/029-web-incident-war-room-sh for a browser-deployable SEV war room with source-controlled mobpack inputs and kickoff prompts
  • examples/030-web-dashboard-copilot-sh for an embeddable dashboard copilot that emits a web bundle plus sample host-integration assets

​
See also