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

Expected source files:
  • manifest.toml
  • definition.json
  • optional skills/, hooks/, mcp/, config/defaults.toml

​
Signed packs and trust policy

Sign at pack time:
Signing embeds the public key but does not install the signer in the verifier’s trust configuration. Use permissive mode for this immediate local path, then switch to strict after installing the signer as trusted:
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:
Detached reusable run:

​
Browser target: mob web build

The browser runtime is the real meerkat agent stack compiled to wasm32 — same agent loop, same LLM providers (Anthropic, OpenAI, Gemini), and same streaming as CLI/RPC/REST. mob web build does not compile it; the command copies the required prebuilt runtime artifacts into the browser bundle. 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 an equivalent wasm-bindgen pipeline. The CLI fails closed without them and never emits a placeholder bundle. Pass either the generated output directory or the *_bg.wasm file (the sibling .js glue is copied alongside it):
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:

​
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