​

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 private 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)

​

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: 35+ 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 open product layers and the closed harness runtime, use the Layered Verification Playbook.

​

Next