​

Product Architecture

Myrm ships as two product layers plus optional cloud control plane. Understanding the split helps you deploy, debug, and migrate from other agents.

​

Layers

Plain language: the frontend is what you click; the server is the door into your workspace; the harness is the brain and hands inside the sandbox.

​

Harness public API (integration contract)

Open-source server code must integrate through myrm_agent_harness.api — not deep imports into internal harness modules. Architecture CI in myrm-agent-server blocks from myrm_agent_harness.*._* imports so harness internals can evolve while the public api.__all__ stays stable. Release wheels ship readable .py stubs plus compiled core extensions. Why it matters for SaaS: the control plane rolls a new runtime Docker image tag per user sandbox (server + harness bundled in the image). Server glue imports only api.hooks / api.skills, so the glue layer stays stable across image rolls — a pattern most monolithic open-source agents do not support.

​

Request flow (typical chat)

1. User sends a message in frontend (or an IM channel via server).
2. Server authenticates, loads agent profile, streams events to the UI.
3. Harness runs the agent loop: tools, memory recall, sub-agents, context compression.
4. Results stream back through server → UI (and optional channel notification).

​

What to configure where

​

Deployment modes (same features, different packaging)

​

Device & hardware layer: what works today, what does not

“Personal AI companion” competitors put the agent onto your own board, watch, or old phone. Here is our split, stated plainly: Honest difference from the competition: Hermes Gadget already ships an open SDK, a desktop simulator (the same firmware core runs in a desktop window, so you can develop and accept without hardware), and a per-model physical verification matrix. We agree with that path and plan the same discipline (a passing build is not a working device; unverified items must be written down explicitly) — but it is not shipped today, so we do not market it.

​

Platform support & verification status: every capability is labelled

Implementation depth differs across the three platforms, so we do not write “works everywhere”. Each capability carries a status: Legend: ✅ has a real-stack / real-binary test record; ⚠️ code exists but no physical-machine verification; ❌ explicitly disabled on that platform or not implemented. Passing unit tests and CI is not the same as working on the machine — unlabelled means unverified. The full list of unverified items is tracked on our roadmap; the discipline itself is a capability verification matrix with support labels.

​

Migrating from other agents

• Config: import paths for Hermes / OpenClaw-style exports (see Quick Start).
• Memory: Myrm uses structured DB memory + GUI — not a single MEMORY.md file.
• Skills: prebuilt + community discovery; evolution is approval-gated.
• Channels: 26 built-in providers — re-link OAuth/ tokens in Settings.

For an honest feature matrix vs OpenClaw, Hermes, Claude Code, and others, see Competitor Comparison. For reproducible low-load validation across the open product layers and the open-source harness runtime, use the Layered Verification Playbook.

​

Next