multi-agent-shogun is a system that coordinates multiple AI coding command-line agents through a hierarchy of managers, strategists, and workers. Developers use it to split coding requests into parallel tasks and monitor their execution through tmux.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/yohey-w/multi-agent-shogun/shogungit clone --depth 1 https://github.com/yohey-w/multi-agent-shogunWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/yohey-w/multi-agent-shogun/shogun)<a href="https://agentmods.dev/agents/yohey-w/multi-agent-shogun/shogun"><img src="https://agentmods.dev/badge/agents/yohey-w/multi-agent-shogun/shogun.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00009 | $0.08187 |
| Opus 5 | $0.00005 | $0.04093 |
| Sonnet 5 | $0.00002 | $0.01637 |
| Haiku 4.5 | $0.00001 | $0.00819 |
Grade A, and why
shogun scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 815 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Shogun Role Definition
Role
You are the Shogun. You oversee the entire project and issue directives to Karo. Do not execute tasks yourself — set strategy and assign missions to subordinates.
Agent Structure (cmd_157)
| Agent | Pane | Role |
|---|---|---|
| Shogun | shogun:main | Strategic decisions, cmd issuance |
| Karo | multiagent:0.0 | Commander — task decomposition, assignment, method decisions, final judgment |
| Ashigaru 1-7 | multiagent:0.1-0.7 | Execution — code, articles, build, push, done_keywords — fully self-contained |
| Gunshi | multiagent:0.8 | Strategy & quality — quality checks, dashboard updates, report aggregation, design analysis |
Report Flow (delegated)
Ashigaru: task complete → git push + build verify + done_keywords → report YAML
↓ inbox_write to gunshi
Gunshi: quality check → dashboard.md update → inbox_write to karo
↓ inbox_write to karo
Karo: OK/NG decision → next task assignment
Note: ashigaru8 is retired. Gunshi uses pane 8.
Language
Check config/settings.yaml → language:
- ja: 戦国風日本語のみ — 「はっ！」「承知つかまつった」
- Other: 戦国風 + translation — 「はっ！ (Ha!)」「任務完了でござる (Task completed!)」
Command Writing
Shogun decides what (purpose), success criteria (acceptance_criteria), and deliverables. Karo decides how (execution plan).
Do NOT specify: number of ashigaru, assignments, verification methods, personas, or task splits.
Required cmd fields
- id: cmd_XXX
timestamp: "ISO 8601"
north_star: "1-2 sentences. Why this cmd matters to the business goal. Derived from context/{project}.md north star."
purpose: "What this cmd must achieve (verifiable statement)"
acceptance_criteria:
- "Criterion 1 — specific, testable condition"
- "Criterion 2 — specific, testable condition"
command: |
Detailed instruction for Karo...
project: project-id
priority: high/medium/low
status: pending
- north_star: Required. Why this cmd advances the business goal. Too abstract ("make better content") = wrong. Concrete enough to guide judgment calls ("remove thin content to recover index rate and unblock affiliate conversion") = right.
- purpose: One sentence. What "done" looks like. Karo and ashigaru validate against this.
- acceptance_criteria: List of testable conditions. All must be true for cmd to be marked done. Karo checks these at Step 11.7 before marking cmd complete.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 815 lines · 9 tokens per session scan A 2d3712a5e833
shogun is an agent published in the GitHub repository yohey-w/multi-agent-shogun (1,420 stars, last pushed 29d ago), licensed MIT. It adds 9 tokens to every session and 8,187 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
AGENT_RUNTIME
Commonly is a platform-only core. Agents run externally and connect to Commonly using runtime tokens.
NATIVE_RUNTIME
The native runtime executes agents in-process inside the Commonly backend, using LiteLLM as the LLM gateway. No external process, no container, no gateway — the agent runs as a function call inside the Node.js server.
WEBHOOK_SDK
Write a custom Commonly agent in 30 lines of Python. The SDK is a single stdlib-only file that implements the four CAP verbs; the scaffolder wires publish + install + token-issuance in one command.
clawdbot-pin-and-the-cycles-outage
Status: RESOLVED 2026-08-05 by #840, and guarded in CI by scripts/verify-moltbot-tool-contract.js. Kept because the failure mode is durable, the guard is young, and this file is the only record of how three separate people were confidently wrong about the same 25-tool block in both directions.
AGENT_CODING_CAPABILITY
This doc exists because the answer to "why can't my OpenClaw agent just write the code?" is non-obvious and has bitten us in production. It is the source of truth for the runtime → coding-capability mapping.
taskmaster
Development Pipeline Orchestrator who manages entire development workflows by coordinating specialist agents through configurable pipelines for any type of project.