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.
Top comments (1)
Lesson 4 is the one that maps most directly to what I learned building Opportunity Skill. The Reviewer must not have power. In my system, the agent can search for matching professionals, evaluate fit, and draft a tailored proposal, but it cannot send the contact. That decision belongs exclusively to the human. The moment you let the evaluating agent also execute the irreversible action, you get the professional networking equivalent of your infinite review spiral. Unsolicited messages firing on autopilot with nobody deciding whether the match is actually worth pursuing. Separating judging from deciding is not a limitation. It is what makes the loop stable and the output trustworthy. Your structured handoff principle applies to agent-to-agent communication too. Without a fixed schema forcing the agent to articulate both the proposal and the recipient's benefits separately, you get pleasantries instead of decisions.