Edict Three-Departments Orchestrator
An OpenClaw workflow that plans, reviews, dispatches, and tracks multi-agent work through named institutional roles.
Per-dimension scores and reasoning
Evidence shows permission matrix, state machine validation, audit logs, dashboard auth, security policy, CWE-22 tests, but lacks user confirmation mechanism, data flow transparency details, sensitive data handling specifics, dependency security audit, external effects control, rollback mechanism, and source attribution details. Therefore each criterion gets 1, deductions due to insufficient evidence or partial implementation.
Self-consistency: README aligns with code structure, state machine and permission matrix descriptions match files, score 2. Dependency availability: requirements.txt only lists numpy, but backend dependencies like SQLAlchemy, Redis are not in root requirements, possibly missing, score 1. Failure messages: tests and docs show error handling, e.g., OpenClaw CLI missing, path traversal rejection, score 2.
Audience and scenarios: README clearly targets developers, provides multiple use cases, score 2. Capability boundaries: permission matrix and state machine define boundaries, score 2. Trigger precision: state transitions have validation, but trigger conditions not precise enough, score 2. Environment fit: supports Docker, systemd, multi-platform, but depends on OpenClaw, score 2.
Information architecture: clear project structure, comprehensive docs, score 2. Install notes: Docker and manual install provided, but depends on OpenClaw, score 2. Naming stability: agent IDs and state names consistent, score 2. Examples and FAQ: examples and FAQ present, score 2. Known limitations: not explicitly listed, score 1. License: MIT, score 2. Versioning and changelog: Roadmap but no CHANGELOG, score 1. Maintenance responsibility: CONTRIBUTING and SECURITY present, but no clear maintainer, score 1.
Output usability: dashboard, CLI, API provide multiple outputs, score 2. Marginal value: unique review mechanism compared to CrewAI etc., score 2. Cost benefit: claims low deployment difficulty, but depends on OpenClaw and multiple services, cost not quantified, score 1.
Claim traceability: most claims in README have corresponding files, but some unverified, score 1. Cross-source corroboration: tests and CI present, but not independently verified, score 1. Fact-inference separation: README distinguishes facts and inferences, but some marketing language not explicit, score 1.
- Incomplete dependency management: root requirements.txt does not list backend dependencies (e.g., SQLAlchemy, Redis client), which may cause installation failures.
- Security mechanisms not fully verified: although CWE-22 tests exist, other security aspects (e.g., actual enforcement of permission matrix) are not verified in static review.
- Lack of user confirmation mechanism: no human confirmation before task execution found, which may affect safety of high-risk operations.
What does this agent do, and when should you use it?
Edict is a self-hosted multi-agent orchestration system built around OpenClaw and modeled on the Three Departments and Six Ministries workflow. The README describes 12 specialized agents including a compatibility role, while its role table names the Crown Prince, three departments, five ministries, Personnel, and a morning-briefing official. Its “Military Affairs Office” dashboard covers Kanban work tracking, task histories, memorial archives, sessions, model and Skill settings, news, and court discussion. The UI is a React 18 frontend served alongside a Python-standard-library `dashboard/server.py`; a separate asynchronous backend is described with SQLAlchemy, Redis, an event bus, an Outbox Relay, dispatch workers, and a DAG orchestrator. It is aimed at teams that want explicit stages, auditability, and operational intervention in multi-role work rather than an unconstrained group chat among models.
A request sent through Feishu, Telegram, or Signal is first classified by taizi, which distinguishes casual chat from work to be created as a task. Work then moves to zhongshu for planning and decomposition, menxia for review and possible rejection, and shangshu for dispatch and consolidation. Delivery roles can include hubu, libu, bingbu, xingbu, gongbu, and libu_hr; zaochao handles morning briefings and news aggregation. scripts/kanban_update.py cleans task titles and notes and enforces _VALID_TRANSITIONS, while audit.py records state changes. The asynchronous services use a Redis Streams EventBus; outbox_relay.py relays transactional Outbox events, dispatch_worker.py provides parallel dispatch, retries, and resource locks, and orchestrator_worker.py resolves DAG dependencies. The dashboard displays tasks, health, sessions, memorials, and reported agent thinking/tool activity, and exposes pause, cancel, resume, model-switching, and remote-Skill management actions.
- An engineering lead needs a user-registration project divided across API design, database work, JWT authentication, tests, and deployment documentation, with progress visible in one board.
- A team that requires a formal quality gate wants
menxiato review a plan fromzhongshuand reject it for rework before execution starts. - A platform team wants development, compliance, CI/CD, and documentation assignments routed to separate roles while preserving a state-machine history and audit trail.
- A team receiving requests through Feishu, Telegram, or Signal wants
taizito answer casual chat and create tasks only for actionable directives. - An operations lead needs a daily view of agent activity, token consumption, sessions, archived outcomes, and scheduled news briefings.
What are this agent's strengths and limitations?
- It separates planning, review, dispatch, and execution into named roles, and Menxia can reject a plan instead of merely participating in an open-ended collaboration.
- The state-machine validation in
kanban_update.pyplus theaudit.pylog provides traceability for task movement. - Its React dashboard combines Kanban, timelines, sessions, health data, model and Skill configuration, and pause/cancel/resume controls.
- The documented backend components include Redis Streams EventBus, transactional Outbox delivery, parallel dispatch, retry handling, resource locks, and DAG orchestration.
- Core operation depends on OpenClaw, so it should not be treated as an independent, general-purpose agent SDK.
- A full installation requires OpenClaw, Python 3.10+, and macOS or Linux; building the frontend also requires Node.js 18+.
- The README cites both 12 agents and 11 named agent IDs, so adopters should verify how the compatibility role is represented in the current configuration.
- Although a Redis and SQLAlchemy asynchronous backend is described, the README does not provide complete infrastructure configuration or production setup details for it.
- Remote Skills are downloaded from GitHub or URLs; the documentation notes possible network timeouts and recommends a proxy in some network environments.
How do you install or deploy this agent?
Install OpenClaw first, then use Python 3.10+ on macOS or Linux. Run git clone https://github.com/cft0808/edict.git, cd edict, and chmod +x install.sh && ./install.sh. For a first installation, configure an API key with openclaw agents add taizi, then rerun ./install.sh to synchronize it to the other agents. The installer creates workspaces, writes SOUL.md files, registers agents and permissions, synchronizes keys and data, and builds the React frontend when possible; a local frontend build requires Node.js 18+. To explore a dashboard with preloaded simulated data only, run docker run -p 7891:7891 cft0808/sansheng-demo and open http://localhost:7891.
How do you use this agent?
The recommended start command is chmod +x start.sh && ./start.sh, followed by http://127.0.0.1:7891. Alternatively, run bash scripts/run_loop.sh & and python3 dashboard/server.py separately. Send a directive via Feishu, Telegram, or Signal; it proceeds through the Crown Prince, Zhongshu, Menxia, Shangshu, and delivery-role stages, with state displayed in the dashboard. To add a remote Skill, run python3 scripts/skill_manager.py add-remote --agent menxia --name mmx_cli --source https://raw.githubusercontent.com/MiniMax-AI/cli/main/skill/SKILL.md --description "MiniMax multimodal CLI skill"; the documented alternative is a POST to /api/add-remote-skill.
How does this agent compare with similar options?
The README positions Edict against CrewAI, MetaGPT, and AutoGen, claiming differentiation through Menxia’s dedicated review-and-rejection step, a real-time Kanban board, task intervention, audit records, health monitoring, and in-dashboard model switching. This is the project’s stated positioning; functional equivalence or superiority should be validated in a deployment.
FAQ
Which model and credentials does it need?
taizi and then synchronized to the other agents. The README says each agent’s LLM can be switched, but it does not specify supported providers, pricing, or key formats.Can I try only the dashboard?
docker run -p 7891:7891 cft0808/sansheng-demo for a demo dashboard with preloaded simulated data. Full task handling still requires an OpenClaw installation.How does it prevent work from bypassing review?
kanban_update.py uses _VALID_TRANSITIONS to reject invalid state jumps, and state changes are written to audit logs.What can I check if a task stalls or a report does not return?
/api/agents-status, Gateway logs, and Agent IDs. It also documents POSTing {"thresholdSec":60} to /api/scheduler-scan to trigger a scheduler scan.