I built an AI dev team that reviews its own work — here's what I learned about multi-agent loops

Chris Lui — Sat, 01 Aug 2026 09:12:25 +0000

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.

DEV Community: Chris Lui