| FMRS | 61 / 100 · C | 79 / 100 · B |
|---|
| Reliability | 10 / 20 | 12 / 20 |
|---|
| Security and permissions | 10 / 20 | 18 / 20 |
|---|
| Maintenance | 14 / 20 | 16 / 20 |
|---|
| Documentation | 15 / 20 | 18 / 20 |
|---|
| Setup experience | 12 / 20 | 15 / 20 |
|---|
| Best for | - Teams that need agent workflows under deterministic admission and policy constraints
- Scenarios requiring worst-case pricing before execution and per-node cost attribution after
- Compliance or investigation workflows needing one replayable audit trace where the dashboard and the audit trail are the same file
- Organizations that want a human to press a button before execution starts, for example from Slack
- Developers who want deterministic, reproducible demos and tests on any checkout via `--scripted`
| - Engineering teams scaling AI coding agents while controlling spend
- Platform teams that need auditable, rollback-aware agent execution records
- Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
|
|---|
| Not for | - Those who only need an interactive single-agent loop without pre-execution authorization
- Anyone looking for a general personal AI assistant gateway or a tool configured by allowlists
- Users expecting node arguments to be fully validated: admission authorises a node's kind, arguments are checked only where the kind declares an args_schema, and a schema bounds their shape, not what a factory lets them reach
- Scenarios requiring the HTTP API to use a durable session layer, or the tool plane to be governed by policy documents instead of CLI flags
- Users who need agent nodes on the Claude CLI backend to be fully governed: by default they run under an allowlist mapped from the node's own tools, but enforcement there is Claude Code's, and the explicit bypass tier has no checks at all
| - Developers who just want a simple code-completion helper without run governance
- Teams unwilling to accept local JSONL run records with HMAC signing
- Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
|
|---|
| Required permissions | - The default backend drives the claude CLI on your PATH (a Claude subscription, no API key)
- Node bodies come from the registry, never from a proposal; the registry is the source of the kinds a planner may propose
- Policy decides what the planner is able to propose: a denied edge changes the shape of the graph rather than producing a refusal to retry
- The MCP gate binds the MCP surface, not the host: an agent with its own file tools in the run directory could forge the approval decision, and the trust boundary is the working directory
- run_command children are unconfined
- ContainerExecutor is the real boundary; the in-process sandbox is defense in depth
| - Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
- Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
- Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
- Execution of user-configured verifier commands (e.g. npm test)
|
|---|
| Risks and side effects | - Admission authorises a node's kind; arguments are validated only where the kind declares an args_schema, and a schema bounds their shape rather than what a factory lets them reach
- The in-process sandbox is defense in depth, run_command children are unconfined, and ContainerExecutor is the real boundary when explicitly used
- The HTTP API does not yet use the durable session layer
- On the Claude CLI backend an agent node is delegated, not governed: by default it runs under an allowlist mapped from the node's own tools, but enforcement is Claude Code's, and the bypass tier has no checks at all
- Policy documents govern planning while the tool plane still reads CLI flags
- The MCP gate binds the MCP surface, not the host: an agent with its own file tools in the run directory could forge the approval decision; the trust boundary is the working directory, as it is for the Slack workspace
| - Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
- Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
- Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
- Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
|
|---|
| Supported clients | | Claude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue |
|---|
| Tools | 0 | 0 |
|---|