This release is a pre-release and may not be stable for production use.
🌐 clawsomeflow.com · 📖 Docs
English · 简体中文
Turn your goal into a reusable task flow, and let an active scheduler drive a team of AI agents to execute it — parallel, isolated, observable, and convergent. You orchestrate the work; ClawsomeFlow keeps it under control.
Don't just run a one-off task — build a workflow that ships the same result reliably, again and again. Define a Flow once, reuse it flexibly with execution parameters, and re-run it whenever you need it. And it's not just for coding: orchestrate every role of a one-person company — market, content, ops, customer service, engineering — into one end-to-end, reusable workflow.
Full compatibility with OpenClaw, Claude Code, Codex, Cursor, Hermes and other CLI Agents.
Quick Start · Docs · News · Who Should Try It · Core Features · How It Works · Why ClawsomeFlow · Contributor Local Deploy · Roadmap · Community
📰 News
- 2026-06-02: ClawsomeFlow public release 🎉
🎯 Who Should Try It?
- Builders of an AI-native one-person company who want to orchestrate every role — not just coding (market, content, ops, customer service, engineering) into one end-to-end workflow; founders and operators who systematically delegate repeatable work to agent teams;
- Developers and teams who need multiple agents to collaborate like a real team (plan, implement, verify, converge) — not just more chat windows;
- Ambitious super-individual creators — one person steering many specialized agents to continuously amplify output;
- Engineering-minded folks done with prompt-only black-box orchestration — predictable behavior, controllable cost, rollback guardrails;
- Building a software engineering agent team that can develop in parallel across local branches.
✨ Core Features
ClawsomeFlow turns scattered AI agents into a controllable engineering system — from the first instruction to the final, reviewable result.
| 🗣️ Get it done in natural language | 🧠 Precise orchestration, not guesswork | 🚀 Many agents, one graph |
|---|---|---|
| Define flows, create agents, orchestrate tasks, and step in at runtime — all by describing what you want. No glue code, no SDK wrangling. | Control flow lives in code, not in a prompt. The scheduler decides dispatch, retry, timeout and convergence — so behavior is predictable and tokens aren't wasted. | Lay out your work as a DAG and let multiple agents collaborate in parallel; a leader summarizes and converges the results into one deliverable. |
| 🔐 Isolation & rollback by default | 📊 Observability you can audit | 🔄 A system that improves itself |
|---|---|---|
| Built on Git worktree isolation with a built-in cross-process repo lock, ensuring absolute reliability of all agent collaboration behaviors; supports intelligent merge and rollback, and any merge can be quickly checked and reverted with one click, plus optional human checkpoints for in-flight course correction. | Every dispatch, completion and failure is recorded as a RunEvent — each run is traceable, replayable and reviewable, with no black boxes. | Not happy with a result? File a complaint and the system reflects, reworks, and writes the lesson back — so the next run is better than the last. |
| ♻️ Reusable, reliably repeatable workflows | 🏢 End-to-end workflows for every role of a one-person company |
|---|---|
| Define a Flow once, reuse it with runtime parameters — stable, convergent, and auditable every time, not a one-off task. | Beyond coding: orchestrate market, content, ops, customer service, and engineering into one end-to-end, reusable workflow. |
ClawsomeFlow inherits the following capabilities from ClawTeam:
- Git Worktree parallel isolation foundation: each Agent has an independent branch and directory, naturally fitting multi-agent parallel development.
- Inter-Agent messaging: point-to-point inbox and broadcast, so team members share progress in real time.
On top of this, ClawsomeFlow adds AI combined with precise orchestration, enhanced Harness engineering (built-in cross-process repo lock for absolutely reliable multi-branch parallel development, intelligent merge and rollback — including a post-run per-agent Run diff and one-click merge revert, complaint-loop mechanism, optional human checkpoints for in-flight correction), deep OpenClaw/Hermes adaptation, and Web productization.
🛠️ How It Works
From a sentence to a shipped result. You stay in charge of the goal; ClawsomeFlow handles the coordination, the parallelism, and the recovery when things go wrong.
- Describe your goal — Tell ClawsomeFlow what you want in plain language, or compose a Flow visually as a graph of tasks and dependencies.
- Agents run in parallel — The scheduler actively dispatches ready tasks to the right agents, each in its own isolated workspace, and drives them to completion.
- Watch, steer, recover — Follow every step live. Retry, skip or abort with clear strategies, and approve results at human checkpoints before anything lands.
- Converge & deliver — A leader merges the parallel work into one reviewed deliverable — and the run history stays fully auditable.
🧪 Developer Mode
Developer mode offers software-development collaboration projects a more flexible way to collaborate.
- Upstream context for every subtask: for each direct dependency, a subtask is injected with the upstream agent id, worktree path, branch and base branch, so it can flexibly build on that work — inspect it, merge that branch, or raise a PR for it — driven entirely by your task description.
- Cross-branch collaboration in plain language: in a downstream task, just write "merge upstream agent X's worktree branch into branch Y" or "open a PR for X".
- Built-in lock = absolute parallel-merge reliability: many branches can develop and merge in parallel without ever racing or corrupting the repo. Whether the scheduler or an agent merges, every merge is serialized on the same lock — you can even direct cross-branch merges or PRs in plain language without risk.
- Per-subtask auto-merge control: each subtask can independently toggle auto-merge into the baseline branch.
- Unique worktree per agent: each agent creates its own worktree and independent branch from the baseline branch.
- PR-friendly flow: for subtasks you want to land via PR or manual review, turn auto-merge OFF.
🤖 Supported Agents
| Agent | Kind | Runtime | Status |
|---|---|---|---|
| OpenClaw | openclaw |
TUI | ⭐ Deeply adapted |
| Hermes | hermes |
TUI | ⭐ Deeply adapted |
| Claude Code | claude |
TUI | ✅ Full support |
| Codex | codex |
TUI | ✅ Full support |
| Cursor | cursor |
TUI | ✅ Full support |
| OpenCode | opencode |
TUI | Testing |
| Gemini CLI | gemini |
TUI | Testing |
| Kimi CLI | kimi |
TUI | Testing |
| Qwen Code | qwen |
TUI | Testing |
| Qoder CLI | qoder |
TUI | Testing |
| CodeBuddy Code | codebuddy |
TUI | Testing |
| Pi | pi |
TUI | Testing |
| nanobot | nanobot |
TUI | Testing |
| External executor | external |
Human / Webhook / Remote ClawsomeFlow | ✅ Full support |
🌐 External Execution Nodes — humans, black-box systems, and remote machines in one DAG
A large project can never be 100% agent-executed — some steps need a human hand (sign a contract, inspect hardware, make a judgment call), and some belong to another system or another machine. External execution nodes open up the definition of "executor": a task in your DAG can be owned by
- 🙋 A human — the task shows up as a todo card on the Run page (optionally pushed to Feishu / Telegram / Slack via the Flow's notify webhooks); the person does the work and submits the result right there.
- 📦 Any system of yours (generic interface) — ClawsomeFlow POSTs the task package (with upstream outputs and a one-time signed callback ticket) to your endpoint; your black box does whatever it does, then calls back with the result. Two JSON messages — that's the whole integration.
- 🖥️ A remote ClawsomeFlow — delegate the task to a Flow on another machine; its leader report comes back as this node's output. Two machines' DAGs stitched together through one node.
External nodes spawn no process and own no worktree or branch — but they sit in the same dependency graph with the same completion semantics: downstream tasks unblock on their completion and automatically receive their result summaries as upstream context. Timeouts are fully configurable (including "no timeout" for human tasks that take days), and failures flow through the same retry/skip/abort policies as any agent.
Set it up in the Flow editor (owner source → "External executor"), and for cross-machine collaboration pair the two instances once:
# On the machine that ACCEPTS delegations:
csflow external pair-token machine-a # generate the inbound credential
csflow external expose on # allow remote callers on /api/external only
# On the machine that DELEGATES:
csflow external add-remote machine-b <secret-from-above>
csflow external callback-url http://this-host:17017
Only the narrow /api/external/* surface is ever exposed — the main API stays loopback-only, and every inbound call carries its own one-time, single-task credential.
🤔 Why ClawsomeFlow?
The common pain point of multi-agent frameworks is not "insufficient model capability", but "unstable collaboration control flow": the process is written in the Prompt, the final behavior depends on the Agent's in-the-moment understanding and model quality, and the system's predictability, cost and recoverability are all too weak.
ClawsomeFlow's approach is direct: migrate coordination from natural language back into code, make concurrency isolation a default capability, and make failure handling a built-in part of the process.
🆚 Comparison with Other Agent Orchestration Platforms
| Dimension | Other Multi-Agent Orchestration Platforms | ✅ ClawsomeFlow |
|---|---|---|
| Reusability | One-off execution: the process is uncontrollable and hard to reuse reliably | Workflows are the deliverable — define once, re-run flexibly via execution parameters for stable, convergent output every time |
| Scope | Mostly coding-only | Every role of a one-person company — market, content, ops, customer service, engineering — as one end-to-end workflow |
| Engineering harness | Generally missing; failures rely on Agent improvisation | Harness engineering: human checkpoints, rollbackable results, complaint-loop mechanism, periodic entropy management |
| Task orchestration fit | Mostly framework-specific, bound to a single ecosystem | Task orchestration is deeply adapted to OpenClaw/Hermes Agents, while also being compatible with any CLI Agent (Claude / Codex / Cursor, etc.) collaborating in the same graph |
| Concurrency & isolation | Easy contention in parallel, workspace conflicts, context cross-talk | Workspace isolation and rollback under multi-task parallelism, and thoroughly resolves session conflicts; built-in cross-process repo lock makes parallel multi-branch development and merging absolutely reliable |
| Observability | Context is mostly a black box | Full-chain RunEvent — traceable, auditable, replayable |
✨ The Result?
You own the goal, and ClawsomeFlow turns multi-agent collaborative execution into a stable, controllable, convergent engineering system.
🧩 Relationship with ClawTeam
ClawsomeFlow is built on top of ClawTeam.
🔍 ClawTeam vs ClawsomeFlow at a Glance
| Dimension | ClawTeam | ClawsomeFlow |
|---|---|---|
| Positioning | Swarm-intelligence protocol foundation (Agent self-organization) | Agent workflow orchestration platform |
| Collaboration driver | Agents self-poll and self-schedule in the Prompt | Server-side scheduler actively dispatches, deterministic execution |
| Collaboration flow | Collaboration flow is uncontrollable; better suited to one-off tasks | Scheduler-driven deterministic workflows, suited to repeatable, convergent engineering collaboration |
| Parallel-merge reliability | No repo-level merge lock — concurrent baseline merges race and can corrupt git metadata; completely uncontrolled | Built-in cross-process repo lock guarantees the absolute reliability of parallel multi-branch development |
| Failure & guardrails | Basic lifecycle protocol | Human checkpoints / rollback / complaint-loop / entropy management |
| Skill configuration | Requires extra skill setup on the Agent platform | No extra skill configuration needed, works out of the box |
| Usage form | CLI + MCP + monitoring dashboard | Web UI + CLI, full-flow governance in natural language |
| OpenClaw/Hermes adaptation | Supported as an optional CLI Agent | Deeply adapted, resolving session and workspace concurrency conflicts |
🚀 Quick Start
Before you start — make sure your agent CLIs work. ClawsomeFlow drives external agent CLIs (
claude,codex,hermes, …) and agents inherit your global CLI authentication. So first install and log in to each CLI you plan to use and confirm it runs on its own (e.g.claude -p hi,hermeschat,codex). If a CLI isn't authenticated, agents using it will stall on a login prompt. For Hermes you can also set the model/provider/key per agent in Settings → Model. If you hit auth errors, verify the CLI's own model/provider config first.Qoder / CodeBuddy need a one-time auth: CodeBuddy via
codebuddy→ interactive login; Qoder viaexport QODER_PERSONAL_ACCESS_TOKEN=…(orqodercli→/login). ClawsomeFlow auto-seeds their folder-trust config (trustAll/trustDirectories) so unattended runs don't stall on the "trust this folder?" prompt — no action needed there.
Install
Linux/macOS
curl -fsSL https://clawsomeflow.com/install.sh | bash
Common Commands
Most of the time you only need these three:
csflow start # start the service, print the console URL
csflow status # is it running? version, mode, paths
csflow upgrade # update to the latest release (flows/runs/settings preserved)
A few more for day-to-day use:
# Lifecycle
csflow stop
csflow doctor # health check (deps + config + gateway)
csflow uninstall --yes # stop service + unregister OpenClaw (keep data)
csflow uninstall --purge-data # full wipe: type PURGE to confirm (irreversible)
# Flow / Run
csflow flows list
csflow runs start <flow-id> --input k=v # trigger a run with parameter fields
csflow runs list
csflow runs abort <run-id>
# Agent governance
csflow agents list
# Creating agents and chatting with them is done in the Web UI ("My Team"),
# not the CLI.
# MCP: let an agent drive Flows remotely (via its own channels, e.g. Telegram)
csflow mcp install --platform hermes --agent <id> # per-agent (Hermes; omit --agent for the default profile)
csflow mcp install --platform codex # global (codex/claude/cursor/gemini/opencode)
csflow mcp print-config --platform openclaw # snippet to paste for unsupported platforms
Every command accepts --help. Full CLI reference: https://clawsomeflow.com/docs/
🔌 MCP: drive Flows from an agent
Run ClawsomeFlow as an MCP server. Point one of your agents at it and — through that agent's own channels (Feishu, Telegram, …) — you can, in plain language, ask which Flows exist, run one, and get the leader's final work report back. A typical loop: you send a file + a request over Telegram → the agent picks the right Flow and runs it → reads the leader report → replies over Telegram.
Talking to your agent (examples)
- "What ClawsomeFlow flows can I run?"
- "Run the XXXX task."
- "Show me the run result."
- "Cancel the XXX run."
The agent organizes the inputs itself from your request, so you rarely name fields explicitly — describe the task and let it map your words onto the Flow's parameters.
Register it with your agent
csflow mcp install --platform hermes # Hermes: default profile
csflow mcp install --platform hermes --agent <id> # Hermes: a specific agent profile
csflow mcp install --platform codex # global platforms (see table)
csflow mcp uninstall --platform codex # remove it again
| Platform | Scope | Config written |
|---|---|---|
hermes |
per-agent (--agent <id>; omit → default profile) |
~/.hermes/…/config.yaml mcp_servers |
claude |
global | ~/.claude.json mcpServers |
cursor |
global | ~/.cursor/mcp.json mcpServers |
gemini |
global | ~/.gemini/settings.json mcpServers |
codex |
global | ~/.codex/config.toml [mcp_servers.*] |
opencode |
global | ~/.config/opencode/opencode.json mcp |
openclaw, kimi, qwen, nanobot |
manual | print-config only (paste into the platform's own MCP config) |
Writes are non-destructive (existing servers and other keys are preserved) and idempotent. install skips a platform whose CLI isn't on PATH unless you pass --force.
Manual configuration
For any platform, print a ready-to-paste snippet instead of writing files:
csflow mcp print-config --platform claude # JSON: { "mcpServers": { "clawsomeflow": … } }
csflow mcp print-config --platform codex # TOML: [mcp_servers.clawsomeflow]
csflow mcp print-config --platform hermes # YAML: mcp_servers: …
The server entry is always the same command — register it manually if your platform isn't listed:
{
"mcpServers": {
"clawsomeflow": { "command": "csflow", "args": ["mcp", "serve"] }
}
}
Note: the ClawsomeFlow service must be running (csflow start) to use MCP.
👩💻 Contributor Local Deploy and Test
For contributors iterating on source code, use the isolated developer entrypoint:
bash scripts/deploy-contributor.sh
Default behavior of deploy-contributor.sh:
- Uses isolated data/runtime under
~/.clawsomeflow-dev(does not reuse~/.clawsomeflow). - Starts backend on
17117and Vite on5174. - Keeps ClawTeam runtime isolated via
~/.clawsomeflow-dev/.clawteam-data.
bash scripts/deploy-contributor.sh is recommended for day-to-day source testing because it keeps regular user service state isolated.
Example with custom profile/ports:
CSFLOW_DEV_HOME=~/.clawsomeflow-dev-alice \
CSFLOW_DEV_BACKEND_PORT=18117 \
CSFLOW_DEV_FRONTEND_PORT=5184 \
bash scripts/deploy-contributor.sh
Running the test suite
Run all tests inside Docker — a separate filesystem and network namespace mean a
test can never touch your real ~/.clawsomeflow / ~/.openclaw or a running
gateway:
scripts/test-in-docker.sh # full backend suite
scripts/test-in-docker.sh -q backend/tests/test_api_guard.py # subset (args → pytest)
Requires Docker and a local ClawTeam checkout (a sibling ../ClawTeam, or set
CLAWTEAM_SRC=/path/to/ClawTeam). Do not run pytest directly on a host
that has a csflow/openclaw service running — it would reach the real gateway on
:18789.
Stop the contributor service
To stop the contributor profile started by deploy-contributor.sh, use the
dedicated stop script:
bash scripts/stop-contributor.sh
Do not use csflow stop for the contributor profile — that targets
the end-user service. If you used a custom profile, pass the same env overrides:
CSFLOW_DEV_BACKEND_PORT=18117 CSFLOW_DEV_FRONTEND_PORT=5184 \
bash scripts/stop-contributor.sh
🗺️ Roadmap
| Phase | Content | Status |
|---|---|---|
| P0 | Agent Store — a shareable marketplace for ready-made Agents, Teams and Flow templates: install, reuse, and contribute domain experts in one click. | 🚧 In progress |
| P1 | Broader Agent platform support — onboard more CLI Agent runtimes and keep pace with emerging ecosystems, so any Agent can join the same graph. | 🚧 In progress |
| P2 | Mobile & server mode — a mobile-friendly console plus multi-user server deployment, to monitor and intervene in Runs anywhere. | 💡 Exploring |
| P3 | Cloud & SSH Agents — drive Agents on remote / cloud hosts over SSH, scaling collaboration beyond a single machine. | 💡 Exploring |
🙏 Acknowledgements
- [ClawTeam] — the spark that inspired this project. Thank you for showing what Agent self-organization can be.
- Our Agent platform teammates — the real "team members" that do the actual work inside every Flow: Claude, OpenClaw, Codex, Gemini, and the growing roster of CLI Agents. ClawsomeFlow is only as clawsome as the Agents it coordinates.
💬 Community
If ClawsomeFlow helps you coordinate your Agent team, please give us a ⭐ Star — it genuinely keeps us going.
Got questions about using ClawsomeFlow, or curious about building an OPC (One-Person Company)? Come hang out with us — join our Discord server or scan the QR code below to join our WeChat discussion group:
📄 License
MIT
1 maintainer
Metadata
1 maintainer
Release files for clawsomeflow 0.1.36b1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| clawsomeflow-0.1.36b1.tar.gz | 1.3 MB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| clawsomeflow-0.1.36b1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 2.4 MB
Release files / clawsomeflow-0.1.36b1.tar.gz
| Download URL | clawsomeflow-0.1.36b1.tar.gz |
|---|---|
| Size | 1.3 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c63c08e8a8fdf21456eba87dba8da2c87c428dcbaa0c1991eb09a71738fd7528
|
|
BLAKE2b-256 checksum How to use checksums |
a5ab6b1ab08c2e849df3c39aef4295d061701229f1b6ddcc0378627e5ca05a25
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.11.0rc1
|
Release files / clawsomeflow-0.1.36b1-py3-none-any.whl
| Download URL | clawsomeflow-0.1.36b1-py3-none-any.whl |
|---|---|
| Size | 1.1 MB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
5fa40e219fef1a83091cc6d4fd129ff9b77386d609f0031253532a34c043723e
|
|
BLAKE2b-256 checksum How to use checksums |
d4d31b509959c43c03247fe2498c57ac10ed8dcaa27f9f126117347f2941b60c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.11.0rc1
|
Security for clawsomeflow 0.1.36b1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
