Task Monki
Run coding agents through the full development process
193 followers
Run coding agents through the full development process
193 followers
Task Monki is an open-source desktop app for managing coding agents from task to pull request. Run several tasks at once, follow each agent’s progress, preview every result without manually setting up services or containers, send work to another agent for review and fixes, and bring multiple agents into the same discussion, where they can respond to each other, compare approaches, and challenge assumptions.
Task Monki
@rojhattoptamus Congrats on the launch.
the "bring multiple agents into the same discussion so they can challenge assumptions" part is what catches my eye. when two agents actually disagree in there - one says the approach is fine, the other flags a problem with it - what breaks the tie? does it surface as an open disagreement for me to resolve, or does one agent's take win by default (most confident, last word, whichever finished first)? that seems like the moment the whole point of having them argue either pays off or quietly gets lost
Task Monki
@galdayan Nothing wins by default. The Lead gives the initial answer, and the Skeptic and Verifier challenge it. If they still disagree, you decide how to proceed. The Lead can revise or defend the answer, but there is no automatic tie breaker for now. This is still experimental, and major improvements are planned.
The multi-agent discussion where agents can respond to each other and challenge assumptions is what catches my eye, but I would want to know what happens when two agents land on genuinely conflicting approaches — whether the app surfaces that disagreement for me to resolve, or whether one output just wins by default. The container-free preview is also interesting: is that a local port serving a web preview, or something closer to a sandboxed execution environment? That distinction matters a lot for whether it can handle full-stack apps or mainly covers static output.
Task Monki
@noctis06 Both are supported, but they work differently. In a Panel, agents answer independently and you compare the outputs yourself. In Team mode, the Lead proposes an answer, and the Skeptic and Verifier challenge it. If there is a disagreement, the Lead reviews the critiques and either updates the answer or leaves it for you to decide. This is still experimental, there will b a lot of improvements soon.
The preview runs locally through a stable browser URL. It is not an OS-level sandbox, but it is more than a static preview. It can run frontend and backend services, workers, migrations, readiness checks, Postgres, Redis, and existing Docker Compose setups, so full-stack previews are supported. You can check the docs to see how to prepare the preview.yaml for the previews.
That distinction makes the tradeoff clear - Panel gives me raw divergent outputs to synthesize myself, Team bakes in the disagreement-resolution loop but I lose direct visibility into where agents actually split before the Lead revised. For exploration or research tasks I would probably want Panel so I can see the full range of takes, but for tasks where I need a single converged answer Team sounds like the right mode. Does the system show me the Skeptic and Verifier critiques before the Lead revises, or only the final output?
Nobody's asked about cost yet, and Discourse mode is the part that worries me on that front. Lead proposes, Skeptic and Verifier challenge, Lead revises - that's already 3x the token spend of one agent, and if it can loop multiple rounds when they disagree, running several of these panels at once across parallel tasks could get expensive fast without you noticing until the bill shows up. Is there a running cost/token counter per task, or a cap on how many back-and-forth rounds Discourse will do before it just hands you the disagreement instead of continuing to argue it out?
@omri_ben_shoham1 this is the one i'd want answered before running it on anything real too. even without discourse mode, running several agents in parallel across tasks is easy to lose track of, the failure mode isn't one expensive call, it's death by a thousand small ones you don't notice until the bill shows up. seconding the question, is there any per-task or per-panel cost visibility while it's running, or is that something you only find out after the fact from the provider dashboard
You asked what's still missing, so — previews for serverless.
Your answer above covers the case where the app is a set of services you can bring up with Compose. Mine isn't. It's Lambda behind API Gateway with DynamoDB, and there is nothing to compose up. My equivalent of your preview is either deploying a throwaway stack per task or emulating locally, and both are slow and lie to you in different ways.
That matters more with parallel agents than with one, because the whole point of running four tasks at once is seeing four previews. Is a deploy-per-task preview backend something preview.yaml could ever express, or is local-services-only the intended scope?
Task Monki
@etiennegarcia My experience has actually been the opposite: agents often disagree, but usually over minor issues or unnecessary complexity. So that is why I built Discourse in the first place, to let them challenge each other and decide if something is really worth fixing/doing or not. It is still experimental, so your feedback is really helpful. Thanks!
the multi-agent discussion feature is honestly pretty wild, watching two agents go back and forth on approach is way more useful than i expected for catching blind spots in a refactor