← Hacker News

Understanding how to run a fleet of agents

Hacker News · sermakarevich · May 20, 2026
A developer evolved an agent task management system from simple markdown artifacts to a distributed multi-agent architecture using beads, a dependency-aware queue system. Critical components include proper task queueing with atomic claims to prevent duplicate work, a communication channel to surface questions without halting workflows, and session memory so agents can persist context across restarts. Multiple Claude workers can then pull tasks from the queue, ask clarifying questions, add new tasks, and store progress and artifacts to disk.

Detailed Analysis

A practitioner's account of scaling Claude-based agent workflows describes an iterative architectural evolution, beginning with simple artifact persistence and culminating in a coordinated multi-agent fleet. The author traces a progression from materializing Claude's replies as markdown files in a flat directory, to introducing hierarchical folder structures with nested index files, to migrating task management entirely into markdown-based queues. This shift away from ephemeral terminal interaction toward durable, file-backed state reflects a fundamental insight: agent work cannot be treated as a conversation if it is meant to be reliable and resumable across sessions.

The core operational challenge the author identifies is the statelessness of individual Claude invocations. Each call to `claude -p` begins with a fresh context window, meaning any agent operating within this pattern must externalize its working memory explicitly — writing completed steps, planned actions, and open questions to disk or to a structured task store. This requirement leads directly to the adoption of a tool called "beads," which provides dependency-aware task queuing with atomic claim operations. The `bd ready` and `bd update --claim` primitives prevent race conditions when multiple workers pull from the same task pool, solving the coordination problem that arises the moment a single-worker loop is scaled horizontally.

The communication channel between agents and humans represents another non-trivial design concern addressed in the architecture. Rather than halting the entire fleet when one agent encounters an ambiguity, the pattern parks the blocked task with a structured question via `bd update --status blocked --notes`, allowing other workers to continue making progress. This asynchronous human-in-the-loop mechanism is a meaningful departure from traditional interactive AI usage, treating the human operator less as a conversational partner and more as an escalation endpoint within a larger automated pipeline.

The pattern described aligns with a broader industry movement toward agentic AI infrastructure, where the primary engineering challenge shifts from model capability to orchestration reliability. The reference to an Anthropic Claude Code GitHub issue as the conceptual inspiration suggests that these architectural patterns are being discussed and refined in open developer communities, rather than emerging solely from formal product documentation. The author's note that "it took some time to figure out how this is supposed to work" underscores that multi-agent orchestration with large language models remains an emerging practice without standardized tooling or canonical documentation.

The progression documented — from single markdown files to a distributed, fault-tolerant agent fleet — illustrates how practitioners are constructing production-grade agentic systems by composing relatively simple primitives: file I/O, shell loops, atomic queue operations, and structured status signaling. The absence of complex middleware or proprietary orchestration frameworks in this design is notable; the architecture relies on Unix-style composability and plain-text data formats, suggesting that robust multi-agent Claude deployments are achievable with minimal infrastructure overhead for teams willing to reason carefully about state management and inter-agent coordination.

Read original article →