Just recently started playing with the idea of an agent that has multiple agents as subordinates. My main agent has the context of the system, controls api keys, tokens, etc. and has a high level overview of each project. Then I have an agent per project and some general "experts" (such as db expert, devops expert, etc.). My main agent (the captain) takes my inputs and then splits the tasks and reports back when the subagents have done the work. I wonder if this idea of having a queue may or may not benefit someone with my setup (running on openclaw). Have you tried this kind of setup yourself and, if so, what are the benefits of using a queue system?

Some suggestions:

The landing page has an information overload (at least for me). I have a hard time understanding what to look at, because it's both a landing page with very dense writings, and at the same time something that looks like a real app.

Less is more. Look at some of the best landing pages out there. They tell the core story with a few words. A video where you walk through your product is even better.

Honestly, this started as a throwaway script. Im running about 40 small sites and most of my day had turned into being a dispatcher for Claude Code and Cursor, re-typing "ok now do this" over and over. So I built TaskPeace: you rank one global list once, and the agent pulls the top task over MCP (get_next_task), does the work, writes a short result back when it's done, then moves to the next one. It'll run down the list unattended.

The bit I actually needed was task leasing, so I can point two or three agents at one queue without them grabbing the same task. Completing a task requires a written result, which sounds like busywork but it's the only reason I trust leaving it running for an hour.

Free to use, $10/mo if you want unlimited runs. It's MIT and you can self-host it (npm run serve, no database needed). There's a demo on the homepage that runs in your browser, no signup. It's early and definitly still rough in places, fair warning.