An agent runtime, not just a faster n8n.

m9m's performance and n8n compatibility get most of the attention. They shouldn't. The more interesting bet is this: workflow engines are the right substrate for production agent systems. m9m makes that bet explicit.

What "agent core" means here

Three capabilities, all first-class:

1. Sandboxed CLI agents as a node type. Run Claude Code, Codex, or Aider inside a Linux namespace with CPU, memory, and network limits — the same way you'd run any other node.
2. MCP integration. m9m exposes 37 workflow-management tools to any LLM that speaks Model Context Protocol. Agents can read runs, edit workflows, re-try jobs, and pull audit logs.
3. Durability by default. Human-review checkpoints, resumable runs after crashes, and Git-versioned workflow definitions — the infrastructure agents actually need in production.

Sandboxed CLI nodes

A CLI agent node is just a node. It takes a prompt, a sandbox spec, and optional allow-lists. m9m starts a namespaced process, copies inputs in, runs the agent, captures output + artifacts, and tears it down. No host-level escape. No global state.

{
  "id": "claude-review",
  "type": "cli.claude-code",
  "params": {
    "sandbox": true,
    "cpu": 2,
    "memory": "2Gi",
    "network": "restricted",
    "workdir": "/tmp/work",
    "prompt": "Review this diff for security issues:\n{{ $node.fetch_pr.diff }}",
    "timeout": "5m",
    "allowed_commands": ["rg", "cat", "git"]
  }
}

Combine it with a github.pr.get upstream and a github.pr.comment downstream and you have a review pipeline — one JSON file, one binary, no Kubernetes.

MCP — an LLM can manage m9m itself

m9m ships an MCP server that exposes workflow-management tools to any MCP-aware LLM. You can point Claude Code at an m9m instance and have it read run logs, patch broken workflows, and re-run jobs — with every action audited and every edit versioned.

# 1. Start m9m in agent mode with MCP enabled
m9m serve --mcp --port 8080

# 2. An LLM with MCP access sees 37 tools:
#    workflow.list, workflow.get, workflow.create, workflow.update,
#    run.start, run.cancel, run.logs, run.retry, run.artifacts,
#    node.list, credential.list, audit.search, ...

# 3. Ask it to fix a failing workflow:
#    "Find the workflow that failed this morning, read the error,
#     patch the retry policy, and re-run it."
#
#    The agent uses run.logs + workflow.get + workflow.update + run.retry
#    — every action audited, every edit versioned in Git.

Why a workflow engine is the right substrate

The hype cycle says "agents replace pipelines." Reality is agents are pipelines — with probabilistic nodes. The infrastructure that matters looks the same: queues, retries, timeouts, checkpoints, observability, secrets. Workflow engines have solved all of that. What they lacked was first-class sandboxing and an MCP surface. m9m adds both.

Not just LangGraph-in-Go

LangGraph is a library for building agent graphs in Python. m9m is a runtime you deploy. The overlap is narrow: if you're writing an agent, you'll still reach for LangGraph or PydanticAI. m9m is where that agent runs — alongside your cron jobs, your CRM sync, your invoice approvals, and your n8n exports.

Read more: m9m vs LangGraph.

Guides

• Running Claude Code in a sandbox
• Using MCP with m9m
• Building a custom node in Go