For AI agent builders
Where your agent runs when it’s in production.
Your LangGraph or PydanticAI agent is the brain. m9m is the skeleton — the thing that schedules it, sandboxes it, retries it, checkpoints it, and audits it. One binary, no cluster.
Why agents need a workflow runtime
The fun part of agent work is the graph. The unfun part — retries, timeouts, rate limits, cost caps, human-review steps, audit logs, sandbox escape prevention — is the same boring workflow-engine work that n8n and Temporal have been doing for a decade. m9m treats agents as a node type in that well-understood substrate.
What’s specifically for you
- Sandboxed CLI nodes. Run Claude Code, Codex, or Aider inside Linux namespaces with CPU / memory / network limits. No host escape. No surprise shell calls.
- MCP server. 37 workflow-management tools exposed over Model Context Protocol — so an agent can read runs, edit workflows, re-try jobs, and pull audit logs from inside another agent.
- Checkpoints. Pause on human-review steps, resume on approval. Crashes resume from the last checkpoint, not from scratch.
- Multi-model chaining. OpenAI, Anthropic, local models, and human steps in one workflow.
- Cost controls. Per-workflow, per-run, and per-tenant budget caps.
Typical setups
- PR review bot — webhook → fetch diff → sandboxed Claude Code → post comment. Runs as a cron or a GitHub webhook.
- Support triage — inbound webhook → LLM classifier → route-by-sentiment → GitHub issue or Slack ping.
- Data-quality agent — nightly cron → pull yesterday’s rows → LLM check → flag anomalies → email report.
- Agent-of-agents — one m9m workflow is the orchestrator; MCP-aware sub-agents read its state and act.
Related
Shipping an agent product?
We design and ship agent platforms on m9m. Sandboxing, MCP, human-in-the-loop, observability — the whole stack.