| FMRS | 54 / 100 · D | 79 / 100 · B |
|---|
| Reliability | 8 / 20 | 12 / 20 |
|---|
| Security and permissions | 9 / 20 | 18 / 20 |
|---|
| Maintenance | 12 / 20 | 16 / 20 |
|---|
| Documentation | 14 / 20 | 18 / 20 |
|---|
| Setup experience | 11 / 20 | 15 / 20 |
|---|
| Best for | - Teams seeking self-hosted multi-agent orchestration
- Engineering and operations teams that want a lead agent to coordinate specialized workers
- Organizations needing shared memory, persistent identity, workflows, or human approval gates
- Users able to manage Docker, API keys, and agent-harness credentials
| - 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 | - Users who only need a single MCP tool or simple chat assistant
- Environments that cannot run Docker or manage agent-harness credentials
- Teams that do not want tasks to flow among multiple agents, shared memory, or external integrations
- Users requiring documented compatibility with a ready-made desktop client
| - 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 | - Access to the local or remote Agent Swarm MCP endpoint
- An Agent Swarm API key supplied through an Authorization header with the Bearer prefix
- The X-Agent-ID of a registered agent
- Depending on enabled integrations and harnesses, credentials for Slack, code hosting, email, Linear, Jira, or other services
| - 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 | - Worker agents execute tasks in isolated Docker environments but may access the code, files, and services configured for them
- Shared memory retains learnings across sessions and can broaden the context visible to later tasks
- Enabled integrations can cause messages, emails, ticket updates, code changes, or pull requests
- Misconfigured API keys, Bearer headers, or agent IDs can cause connection failures or access to the wrong agent instance
- Automated workflows and external actions should be reviewed with human approval gates, especially for irreversible operations
| - 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 |
|---|