Why we killed our 430-line Orchestrator (and why yours might be a "Black Box")
I’ve spent the last few months obsessed with a specific failure in multi-agent systems: The Black Box Dilemma.
Most MAS setups I see (including my own v1) treat orchestration as "glue code." You have a central manager, a few agents, and a lot of hidden logic. When it fails, you’re left guessing. As someone on IndieHackers put it: "You’re just parallelizing chaos."
The Shift: From "Dictator" to "Blackboard"
In our latest iteration, we deleted the 430-line monolithic controller. Instead, we implemented a Blackboard Pattern.
Instead of agents whispering to a manager, they run a Scrum Standup on a shared board. It’s no longer about "AI-vibes"—it’s about intentional architecture:
No Leaked Context: The board is the single source of truth. If a "guy" on the team creates a file, every other "guy" sees it instantly.
Hard Validation Gates: QA isn't an afterthought. It’s a mandatory sandbox gate. If the code doesn't run, it doesn't move forward.
Closing the Loop: When a bug is fixed, the system audits the fix and saves the sequence. The goal isn't just to "fix" but to learn for the next run.
The Question for the Community:
We’re running this 100% locally via Ollama to keep costs at zero and data private. But I’m curious about your architectural choices:
How do you handle state ownership when 5+ agents are working on the same codebase?
Do you believe in a "Manager Agent" (Command-and-Control) or a "Shared Board" (Self-organizing)?
How are you preventing "Entropy" as your workflows get longer?
Replies