OpenMOSS: a FastAPI scheduler that turns OpenClaw agents into a four-role team
A self-organizing multi-agent collaboration platform for OpenClaw. Multiple AI agents work as an autonomous team — planning, executing, reviewing, and patrolling tasks with zero human intervention.
At a glance
- What is it?
- OpenMOSS is an MIT-licensed Python middleware that coordinates planner, executor, reviewer and patrol agents through a REST API and SQLite state, with a Vue admin UI. It is worth reading if you already run OpenClaw agents and want the coordination layer; it is not a standalone agent runtime.
- Who is it for?
- Adopt OpenMOSS if your agents already run on OpenClaw and you want a scheduler, review loop and patrol role rather than building them yourself; skip it if you need a framework that ships its own agent runtime, because OpenMOSS delegates that entirely to OpenClaw and to Skills you supply.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 85 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure mode OpenMOSS is built around
The README frames the problem narrowly. A single agent pushing a task forward tends to die inside its own conversation when it hits an obstacle, and the task fails with it. OpenMOSS answers that with role separation and a patrol loop. Four roles are defined: a planner that decomposes requirements, assigns work and closes out delivery; executors that claim tasks and submit results; a reviewer that scores quality and either approves or sends work back; and a patrol agent that inspects the system and flags blocked tasks. The intended audience is anyone already running OpenClaw agents who wants them to keep working without a human assigning each step. The README's own framing is that OpenMOSS is a general multi-agent collaboration middleware: it does not decide what agents can do, it decides how they coordinate. That distinction matters more than the marketing language around it, because it means the platform ships no domain logic. Whatever the agents accomplish comes from the prompts and Skills you attach to them.
Middleware, not a runtime: how the pieces connect
The architecture is deliberately thin. OpenMOSS sits between OpenClaw and the agents as a scheduling center, and agents never talk to each other directly. They coordinate only through the OpenMOSS API, asynchronously. The backend is FastAPI listening on port 6565 and exposes REST endpoints for task scheduling, agent management, review, scoring and logging. State lives in SQLite through SQLAlchemy, across ten tables covering tasks, agents, reviews and points. The frontend is Vue 3 with shadcn-vue. Each agent is an OpenClaw instance carrying a role prompt and Skills, and it authenticates to the backend with an API key. Wake-up is driven by cron, not by a persistent connection: an agent wakes on schedule, calls the API, claims work, executes, and submits. That design keeps the middleware stateless with respect to agent processes, which is why SQLite is sufficient. It also means the entire liveness of the system depends on cron actually firing and on agents successfully calling back. Nothing in the repository layout suggests a supervisor process that restarts a dead agent; the patrol role is the documented answer to that, and it works by marking and alerting rather than by restarting.
Task hierarchy and the review rework loop
Work is modeled in three levels. A Task is a whole project goal. A Module is a functional split within it. A Sub-Task is the executable unit. The README's example runs from a blog system, through user system and article management, down to implementing a registration endpoint. Sub-tasks move through a state machine: pending, assigned, in_progress, review, done, with a rework state that returns to in_progress when the reviewer rejects, and a blocked state that the patrol agent can apply and that sends the sub-task back to pending. The review step is where the quality claim actually lives. The reviewer scores the submission, and per the README, review results feed directly into agent points and a leaderboard, so performance data is not decorative. This is the most concrete mechanism in the project and the one most likely to be underestimated: rejection is a first-class transition, not an error path. If you configure the reviewer prompt loosely, rework loops can consume budget indefinitely, and the README's own warning about multiplied model consumption applies most sharply here.
Getting it running: ports, database and the WebUI branch caveat
The README points to section five, quick start, and section seven, configuration, for setup, and states Python 3.10 or newer is required. The backend binds to port 6565 and stores data in SQLite via SQLAlchemy, so there is no external database to provision. Agents are configured with an API key and a role prompt, and they run on OpenClaw instances woken by cron. Two operational details are worth flagging before you start. First, the README states that the current branch keeps only the built static output for the WebUI, and that the source is maintained on a separate webui branch. If you plan to modify the interface, you are working from a branch, not the default one. Second, release v1.1.3 is titled Docker deployment fix, which implies container deployment is the supported path and that it had defects as recently as v1.1.2. The release notes give no detail beyond the title, so treat the Docker path as the one to validate first in your own environment. Full configuration keys are in section seven of the README and are not reproduced in the material available here.
Where it breaks down, and the model dependency you cannot design around
The README is unusually direct about the biggest constraint: results depend heavily on the underlying language model, and a larger context window is better, with GPT-5.3-Codex or GPT-5.4 recommended. That is not a tuning note, it is an architectural admission. Because agents coordinate through API calls and role prompts rather than through a structured protocol with schema validation, a model that loses track of its role or its task ID will produce malformed submissions that the reviewer then has to catch. The second constraint is cost. The README warns in a callout that multi-agent operation multiplies model consumption and that you should control API quotas and rate limits to avoid financial loss. Four roles, cron wake-ups and rework loops compound: a rejected sub-task does not cost one extra call, it costs an executor run plus a reviewer run. The third is the recommendation to give OpenMOSS a dedicated desktop-class production environment. That phrasing suggests the project is not aiming at shared or containerized multi-tenant hosting, and it is a signal about resource expectations rather than a hard requirement. None of these are defects in the code; they are consequences of the design, and they should shape whether you adopt it at all.
What it is not: OpenMOSS versus a self-contained agent framework
The clearest comparison is with self-contained agent frameworks that bundle their own runtime, tool execution and memory, so that installing the framework gives you working agents. OpenMOSS does the opposite. It assumes OpenClaw is already running, assumes you will write role prompts, and assumes you will supply Skills for anything the agents actually do, whether that is web search, code execution or API calls. The README states this plainly in a note: OpenMOSS handles scheduling and collaboration, and agent capability is determined by Skills. The trade-off is real in both directions. A self-contained framework gives you a shorter path to a first working agent but tends to be opinionated about tooling. OpenMOSS gives you a scheduling and review layer you can attach to agents you already trust, at the cost of owning the runtime, the prompts and the Skills yourself. If you do not already run OpenClaw, OpenMOSS is the wrong starting point, because you would be adopting a coordination layer for a runtime you have not set up.
Maintenance, release cadence and licence
OpenMOSS is MIT-licensed, which permits commercial use and modification provided the licence notice is retained; this is a general observation about the MIT terms and not legal advice, and you should confirm obligations with your own counsel if you redistribute it. The release history is short and recent. v1.1.3 and v1.1.2 both landed on 2026-04-02, and webui-v0.0.1 on 2026-04-01, with the last push to the repository on 2026-06-22. The two v1.1.x releases are bug fixes, one for Docker deployment and one for WebUI download logic, which tells you the project is in an early stabilization phase rather than a mature maintenance mode. The practical upgrade cost is moderate: SQLite-backed state means a schema change in a future release could require a migration the project has not yet needed to ship, and the split between the default branch and the webui branch adds a step to any interface customization. Pin to a specific release rather than tracking main if you are running this in anything resembling production. The README's roadmap section is referenced in the table of contents but not included in the material available here, so the direction of future work cannot be assessed from what is on hand.
Editorial conclusion
Adopt OpenMOSS if your agents already run on OpenClaw and you want a scheduler, review loop and patrol role rather than building them yourself; skip it if you need a framework that ships its own agent runtime, because OpenMOSS delegates that entirely to OpenClaw and to Skills you supply. Before committing, verify the WebUI source situation on the webui branch, the Docker deployment path that v1.1.3 claims to have fixed, and the rate limits and quotas your model provider enforces, since the README warns that multi-agent operation multiplies consumption.
Community notes