Most multi-agent demos are impressive for five minutes and useless for five hours. After months of building Task Hounds — an open-source, local multi-agent development workspace — here are the design decisions that actually mattered.
The setup
Task Hounds runs three agents in a loop around one project:
- A Manager that understands context, maintains the plan, and assigns exactly one concrete task per cycle
- A Worker that implements the task and files a structured report: files changed, test results, known issues
- A Reviewer that inspects the result for bugs, UX problems, and risks — before the Manager decides what happens next
A human writes a Directive (the mission), and can inject thoughts or new tasks mid-run. Everything — plans, todos, reports, feedback, live agent streams — persists in local SQLite and renders in a real-time dashboard.
Lesson 1: One task at a time beats parallel everything
My first instinct was parallel workers. It demoed great and shipped nothing: agents stepped on each other’s files and the Manager couldn’t attribute failures. Serializing to one task per loop looks slower and finishes dramatically more work.
Lesson 2: Give the human a write-protected anchor
Goal drift is the silent killer of long loops. Around loop 10, the plan subtly stops resembling what you asked for. Our fix: the Human Directive is copied into every session and the loop is forbidden from editing it. Only a human can change the mission. Drift now shows up as visible divergence from a fixed anchor instead of quiet mutation.
Lesson 3: Structured handoffs, not chat history
Passing conversation history between agents fails in two ways: it blows the context window, and it lets downstream agents anchor on upstream reasoning noise. Every hop in Task Hounds is a fixed document: the Manager’s memory is an explicit JSON handoff read once per loop; the Worker’s output is a fixed report schema. If the machine-readable todo JSON is invalid, the loop repairs it before any work is released.
Lesson 4: The Reviewer must not have power
Early on, the Reviewer could assign fixes directly. Result: infinite review spirals, with two agents negotiating forever. Now the Reviewer only files structured feedback back to the Manager, who decides: fix, continue, or stop. Separating judging from deciding stabilized the whole loop.
Lesson 5: Trust is a UI problem, not a model problem
The single biggest change in how much autonomy I give the system wasn’t a better model — it was being able to watch. When every decision is a row in SQLite and a panel in the dashboard, “should I let it run for an hour?” becomes an evidence question instead of a faith question.
What’s still hard
- Text contracts with LLMs remain fragile; structured outputs / tool-calling will replace parts of our repair layer
- Cost: three roles use more tokens than one-shot prompting. The bet is that plan→implement→review wastes less than re-prompting a confused single agent — true for long tasks, not for small edits
- Cross-platform polish (the managed runtime is Windows-first today; Docker runs everywhere)
Try it
Task Hounds is MIT licensed: https://github.com/catowabisabi/task-hounds
3-minute demo: https://www.youtube.com/watch?v=pu-Rt8Ye4EQ
If you’ve built agent loops — where do yours fail: planning, execution, or review? I’d love to compare notes in the comments.
답글 남기기