alt Hacker NewsThe reviewer/worker pattern gets tricky when they share state. The pattern I've found that works: each agent owns a separate state partition, and they communicate through a shared message queue (even a simple append-only JSONL file works). Worker writes output + confidence score. Reviewer reads, adds a decision record, worker reads that before retrying.
The key thing to get right: make the retry idempotent. If worker retries the same task, it should produce the same side effects as a fresh run, not double them. This is harder than it sounds when agents are calling real APIs or writing files.
How does OpenSwarm handle the case where worker keeps failing reviewer? Is there a max retry count, and if so, what happens to the Linear issue?
For the current build, OpenSwarm uses max retry count with an escalation scheme: the first worker starts with Haiku, and if the tester/reviewer blocks enough times, it escalates to Sonnet. Each pipeline step updates Linear's updates tab with iteration count and total cost, so there's a full audit trail per issue. Failed jobs stay as 'in progress' or 'in review' in Linear rather than being auto-closed. I'm currently working on an 'Auditor' layer that analyzes why jobs failed — and longer term, the goal is for OpenSwarm to maintain itself using its own agents. That said, not every failure should be resolved automatically. Some errors genuinely need human judgment, and the dashboard chat interface and Discord are there for exactly that. I think knowing when to hand off to a human is part of what makes an autonomous system actually trustworthy.